Written by Tony Hopwood and Ben Salder








Have you ever heard people complain that a new IT system is rubbish, not as good as the old system or, even, that they don’t understand why they have had to change at all? Having been involved in a number new systems implementations, both as an end user and as part of the implementation team, I have discovered that

even the best technical solutions, poorly implemented are worse for the business, its customers and its employees, than a poor technical solution well implemented.

Regardless of the potential quality of a technology solution, if it has been poorly implemented, people will still say “This new system is rubbish!”; or words to that effect!

Systems implementations are far too often seen as an IT project, but this misses the point completely of why businesses implement new systems. At the beginning of a programme it is easy to talk about the balance between the system, the business processes and the impact it will have on the people but fundamentally the reason for implementing a new system is to make it easier to deliver exactly what the customer wants, when they want it. In order to do this successfully, everyone in the organisation, no matter how large or small that organisation is, needs to get behind the project.

Let me share some of the lessons I have learnt during the implementation of some significant technology solutions;

1 What is the “Why”?

Is it clear “Why” the solution is being implemented? Does it answer the business “Why”, the customer “Why” and the employee “Why”? Does it answer both the factual and emotional “Why”? Is it something that people can get behind?

During a particularly testing ERP implementation, we started off without a “Why” that the end-users really understood, we had spent all of our time and energy focussing on the business case to justify the project to the corporation and also to the key customer. By the time we went live we had a “Why”….. “All of our systems are becoming obsolete so we need to change to a single system and this ERP system is the industry standard”; not exactly something to get the users inquisitive or enthused!

Looking back now we should have talked about what frustrated them with the current systems & processes, what the new system and processes would mean to them in their daily tasks. Be honest with them that there may be some “hiccups” in the transition, but that this was their opportunity to make their work life more rewarding going forward… and become experts in a state of the art system!

Once the “Why” has been defined, the key thing is to ensure that it is shared with everyone, non-stop for the duration of the project. Keep revisiting it to make sure it still resonates but also keep it constant and consistent throughout, too many changes in message will be seen as ‘Management’ not knowing where the project is heading by the nay-sayers.

2 What are your change challenges?

Is it really clearly understood what challenges face the end-users on a daily basis? This again isn’t just a technical and process driven question, this is about people. The people who will be part of the project team and the people using the system.

David Rock’s SCARF model really landed well with the implementation teams when we used it to start to think about how different people were going to be affected by the changes depending upon how their Status, Certainty, Autonomy, Relatedness and Fairness was going to be impacted.

By using this in conjunction with the Dave Gray’s Empathy Map we got teams at all levels engaged in what the change meant not just to them, but to everyone impacted by the change. The teams really started to understand and appreciate the impact their work had on the people around them in the process and why some of their outputs were needed for the overall effectiveness of the business.

Dave Grey’s Empathy Map from “Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, 2010”

3 Have a clear approach to change

Does everyone, not just the project team, understand how the change is going to managed? This is not about turning everything into a process but instead this is an opportunity to engage people around a standard framework that enables people to remain focussed on doing the right things at the right time and make the right decisions at the right time.

A simple model that I have used is built around 3 stages; Initiate, Implement and Sustain. It has been developed using coaching questions rather than tasks in order to avoid the “box-ticking” that all too often occurs in projects, especially as the pressure increases.

We asked questions like;

  • What’s the single sentence that says “What is the change and why should we be making this change?”
  • Who will be affected by the change and how?
  • What does success look like?
  • What is the current state?
  • What are the levels of maturity in moving from the current state to the compelling vision?

Teams working together to answer these types of questions stopped them from getting drawn into purely focussing on the technical solution as there was a clear approach to change for each stage, which meant that both technical and change activities had to be undertaken before progressing to the next stage of the overall programme.

4 How you lead is key

Have you ever heard of a shockwave traffic jam? Chances are you’ve experienced one; if you reach the end of the traffic jam and find there was no apparent reason for it then you’ve been caught in a shockwave traffic jam. They are caused by fluctuations in speed between drivers, in particular braking, or more accurately, applying the brakes and causing the person following to apply their brakes too. Researchers from the Mathematical Society of Traffic Flow, part of the Department of Complex Systems Science at the University of Nagoya in Japan, challenged 22 drivers to follow a circular track at a speed of 30km per hour. At first the cars maintained their spacing but after a short period, fluctuations started to occur and the cars started to bunch up; a traffic jam was born which spread backwards at a rate of approximately 20 km per hour.

So what has this got to do with leadership in a systems implementation?

We are all influencers, especially during times of significant change, we may not think we are but our actions are picked up on by other people. Do you think the first person to brake on a motorway at the very beginning of a shockwave traffic jam thinks that they are going to cause such a significant effect by such a minor action?

By not challenging the objections: “this will never work”, or “the old system is much better – we don’t need to change” comments, they will propagate through an organisation like a shockwave traffic jam. It is the challenge of everyone, not just those with formal leadership or management roles, to spend time with those who make these comments and help them to understand the “why” for them… and the more influential the person the bigger the impact. Who are your Key Opinion Leaders? They’re not always the management!

5 Go-live is a false summit

If you’ve ever been walking in the hills and, after a long climb, thought you have reached the summit, only to find that the real summit appears in the distance. Not only do you feel tired from the exertion of getting to this point but, because of the amount of work you realise that you have remaining to reach your ultimate goal, you also have feelings of frustration resulting in the “I need a rest” moment.

By treating the “go-live” date as an end point, where all the energy from the team goes to reach this point, a false summit is generated. The very people you need to be putting energy into the business post go-live to embed and sustain the new system are left exhausted and feeling that they need a rest.

Using the “Initiate – Implement – Sustain” model, or something similar, means that this key phase is considered of equal importance to the “go-live” and clear plans can be developed to ensure that there are enough, well trained, people who are fresh for the challenges of supporting people out in the business adopting to the new system.

During the life of the programme, individuals need to be considered rather than just ‘headcount’. While your calculations may show that you have enough people to complete all the tasks, there will inevitably be a few key individuals who will be overloaded. These will be the people who are involved in multiple tasks that occur simultaneously such as User Acceptance Testing, Training delivery and being trained as a Super-User.

“This new system isn’t all that bad”

The best advice I ever received about implementing a new system was to put myself in the place of the end user throughout the programme. It is easy to become absorbed in the programme and its deliverables, but if you can help people to understand the value of what the new system and processes are trying to deliver, then they will naturally start to think about what it means to them and how they can help make the transition easier.