Retro-fitting change when disaster strikes - Part 1

So you have invested hundreds of thousands of dollars in a new IT system only to find that it 'doesn't work' for the business. The operations teams are beside themselves, having to implement workarounds and fast. The project is now in 'crisis management' mode. Heads are rolling as the Executive team are asking the usual questions and looking for someone to blame amongst an operating crisis. 'Where is the change plan?' 'How did we not know that there was a risk with this system?' 'What are we doing to resolve this?'

Now these are broad questions, however it isn't too unfamiliar. Take it from someone who has walked into scenarios like this with a need to 'revisit' urgently a system rollout. Sometimes it takes the 'guise of a system 'improvement'.  Over time as a change expert, but also a program expert, you become familiar with the common weaknesses and mis-steps of poor rollouts. So it becomes easier to identify areas to be changed or revisited and fast. Needless to say the best people to ask are the end users first, as often times in the project area or with management there is a degree of glossing over some of the necessary detail as a degree of 'covering tracks' with half truths or personal bias tainted with blame. 

Think like Sherlock Holmes...

So where do you start? Like a Sherlock Holmes, it is important to listen, observe and not jump to conclusions fast when investigating what has gone wrong previously. Don't move to action too fast, and slowly but steadily join the dots to be able to come up with an appropriate action plan (whether that be in the form of a change plan or an explicit recovery plan). Of course it is also something that I should mention that for major transformations and even small deployments the principles are the same if you are rectifying a somewhat poor implementation. Based on my experience, the next five questions cover key areas which are typically weak points which have led to near disaster when implementing changes.

The top 5 questions to ask when identifying where the points of program weaknesses are:

1. What was the scope of the program and in the scope of the change? Often the issue with IT programs is that they focus on technology but don't consider the supporting operational (offline) processes that people follow as being 'in scope'. It isn't asked or addressed directly and then when questions get asked by end users or operational people as to how it impacts other processes, the response they get is 'that is out of scope'. If you want your technology program to fail, then continue to not address those and when the system goes live it will definitely cause more pain than achieve positive outcomes.

So be sure to ask how processes or associated policies need to change. Clarify who is doing that work to ensure policies and processes are also updated in line with the technology. In fact, the best way to ask the question about tech is to start with the policies and processes that are changing and THEN engage on the tech conversation. Explore the scope and you may just find some root causes of the program being challenged.

2. How often has a change like this occurred and what was the change plan this time?  Two questions in one but they both interrelate. Sometimes there is an underestimation on the change required as there have been assumptions that people are familiar with the technology and have existing capability in using it. So have a look at the change impact assessment and the resulting change plan. You may find that the impact assessment was too high level, and didn't take into account all impacted groups. Or it may have been based on assumptions rather than fact.

For the change plan make sure that it covered all relevant interventions required - communications, training if needed, and embedding activities. You may find some weaknesses in either the impact assessment which will right away lead to issues with the change plan.

3. Who was involved in the design of the solution? Whether it be an IT system or HR operating model or even a new policy, during the the design phase it is critical to involve the customers or current users of a process to identify pain points or test possible solutions. Often times solutions are put together with only one or two representatives from customer groups. That is not enough. And at times the solutions aren't tested or piloted with user groups before going 'all in'. A sure way to fail. So this question becomes relevant to make sure that enough of the right people were involved. 

4. What Governance forums exist for decision making and to raise issues? This covers a bit of the role of leadership influence the form of decision making and active sponsorship. Explore what Governance forums were in place or are in place to be able to escalate and resolve issues. Often times issues weren't raised and weren't escalated for decision making or were hidden. I have seen this before, and to ensure it doesn't happen the next time have actively reviewed Governance to make it effective and efficient. 

5. How was Change Readiness assessed prior to Go Live? This is always a critical checkpoint and we will do a deep dive on this in another post as this process will assist in risk management and to ensure the Go Live button isn't pushed when there is just too many risks and not enough engagement. If a Change readiness or even Go live readiness assessment wasn't conducted then there was no risk management on the program - a BIG NO NO! 

These are the top 5 areas which I have no doubt will expose areas for improvement when looking to alter the approach - and fast. In regards to changing the approach here are the areas who should be involved in changing the approach the second time around.

To be continued...

In Part 2 of this post, we will explore the responses to these discoveries and the areas that should be accountable for putting these in place.