We manage these complex projects through 7 focused processes that give you control; increasing your chances of success and getting you back to focussing on running your business.

And it turns out that this works delivering an ERP remotely on the other side of the world!!

Sounds obvious but it is rarely done. Choose Champions and train them. Get them skilled in Resilience, Facilitation, Decision Making and Teaming (here’s a great video from Amy Edmondson on Teaming)

When you tell the story, make the people the hero of the story, not your change programme. Pitch it as though this will help them achieve their goals and ambitions, the programme is purely a guide to help them along the way.

Watch this webinar, which was streamed to hundreds of people from Birmingham Tech Week on putting your people at the heart of transformation.

This will change everything for you. Establish responsibilities so that the key user communities take on the dual role of Customer of the change and Supplier. This means that they understand from day 1 that as a supplier they need the programme with all of the input, key decisions and business knowledge. On the flip side as a customer, they can then reap the rewards of the effort put in.

This is definitely a mindset shift and will require the team to take decisions (which is not always easy) and sometimes this can feel risky.  

This is a brilliant and simple technique to support risk identification and management strategies.

To quote Gary Kline writing in Harvard Business Review “A premortem is the hypothetical opposite of a postmortem. A postmortem in a medical setting allows health professionals and the family to learn what caused a patient’s death. Everyone benefits except, of course, the patient. A premortem in a business setting comes at the beginning of a project rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure.”

Read Gary’s full article.

Talking hard truths to stakeholders is paramount. If you can establish psychological safety in the team, where no-one fears speaking up, you can certainly create an environment where stakeholders not only accept, but fully expect to have the tough conversations.

Think of the Team CODE as an identity, the rules of engagement for shaping the project team and how you are going to act.

Connect: Do you understand your people? Understand the environment so your people feel connected in order to bring them on the change journey with you.

Organise: How are you as a team going to be organised, what mechanisms and processes do you need? Meeting cadence? Feedback mechanisms? Comms channels? Etc.

Drive: Define clearly what you are there to deliver and what difference it will make when done. What is the big goal that lets everyone know where you are going and why you are going there.

Explore: Possibility thinking. What can you do to disrupt your own thinking, dispel fixed beliefs and try new things. Define ways to test and learn as a team, not to innovate along the way.  If you make it an expectation to come up with ideas, you will be amazed at how much innovation will come through the team to help in small and large ways.

Delivering an ERP is perhaps the hardest and riskiest project organisations face into. It is imperative to get everyone on the same page at the very beginning.

We introduced our 7 step process for ERP deployment that drives business engagement alongside technical delivery throughout the project.  Take a look at the outline 7 processes here: 

The benefit of codifying your approach is massive, ranging from being able to prep way in advance for future steps through everyone on the team and in the business using the same language and having a single place to find out what different activity means.