This is the third of a series of articles on understanding IT systems change.  In this article I will discuss the importance of continuing the change management effort once the new system has gone live.

Read the first two articles in the series here:

>>> Understanding IT Systems Change Part 1 – Context and Initiation <<<

>>> Understanding IT Systems Change Part 2 – The Importance of Change Management <<<

I have already written about the importance of considering the change process both before and during a systems implementation or upgrade project.  Unfortunately, that was just the easy bit!

Implementing a new piece of technology is relatively easy, yes it can be complicated but it is not usually complex – i.e. the process of implementation is well understood.  If everything is done correctly in the right order success should follow.  What is not so easy is embedding the change and making sure your people adopt the new systems and processes.  This is what I will be focusing on in this article.

The J curve of change

Implementing a systems change in a people based organisation (i.e. most businesses!) creates turbulence. Staff have to move out of their comfort zone and get used to new and unfamiliar ways of working.  This period of turbulence should not be resisted because it provides its own benefits.  

The graph below plots complexity of the work environment against a person’s control over that environment. When complexity is low and staff have a lot of control then they are generally in their comfort zone. When change comes along, complexity increases but control usually decreases. This is particularly so when implementing new enterprise software controlled centrally. The result is turbulence. This turbulence should be encouraged because it allows people to find a ‘new normal’ increasing the arc of the comfort zone. The key is making sure the turbulence is managed because too much will result in chaos, which is definitely to be avoided. An experienced change manager will help you avoid this.

The impact of turbulence will result in a drop in business performance because your staff are less efficient at doing their job and many tasks that were once second nature now have to be thought about.  Many of Solitaire Consulting’s clients are in professional services, where the impact of a drop in productivity manifests itself in a lower utilisation rate (i.e. chargeable time booked to clients),  an increase in write-offs or just more time to carry out simple tasks.

For the period immediately after implementing your new system, expect the bottom line to be affected and prepare for it.  This effect is entirely normal and is known as the ‘J curve of change’ as shown in the diagram below.

The most important step in dealing with this dip in performance is to recognize it is going to happen and to let staff know that it has been allowed for in relevant business plans and forecasts.  A new system can provide a lot of stress to staff at the best of times.  If they know management have allowed for some dip in performance this will allow them to focus properly on adapting to the change and learning the new ways of working.

The role of the ‘change manager’ is to minimise the length and extent of the dip in performance and maximise business benefits following the system implementation.  This is shown by the three arrows in the diagram above.

The period following implementation is critical, but whilst there is very little we can do to prevent a decrease in performance there is a lot we can do to minimise it.  This is where the internal project team, or external change management support, should have the most impact.  However in a lot of organisations there is a celebration when the new system ‘goes live’ and the project team will be disbanded. The main objective of implementing the new system has been achieved so the project is deemed ‘completed’ – however this is where the real hard work starts!

How many times have you experienced a project where the live implementation has been celebrated only to find a few weeks later that staff are struggling to adopt the new system?  I always recommend retaining the project structure until well after ‘go-live’ to ensure that business benefits start to be realised. By all means celebrate the achievement but do it once the new system is stable and benefits have started to be realised

This also helps to avoid remaining in the ‘Valley of Despair’ (also known as VOD) for too long.  A problem I have seen in several organisations is where multiple changes are implemented without taking time to stabilise and support between each phase.  Essentially the organisation takes a dip in performance whilst still in the VOD from the previous change.  Clearly this is unsustainable and will require serious intervention.

There is a lot you can do in advance of going live to ensure the transition is as smooth as possible.  I find that applying a formal change management framework from the outset of the project is vital to its overall success.  As you will have seen from the previous article I favour basing my framework on the 8 Steps to Change model developed by Dr John Kotter.  Whichever model you use though, it is important that this runs in parallel to your project management methodology.

Other specific key interventions will depend largely on the size and complexity of your business but could include:

• Making sure you have booked time from your technology vendor to ensure they are available onsite to provide support to your staff during the first days after implementation.
• Impact of change plan or operational readiness assessment – this will detail the changes from the old system to the new in terms of people and business impact (risk).  It can be used to highlight where the most impact will be and consequently where the most support effort will be required.
• Training –  hands-on training is critical to the success of a technology implementation.  The training needs to be done as close to the live date as possible (it can even be after for certain processes e.g. month end) and must include content tailored for the business.  Standard vendor training will only describe how to use the software not why and how it fits into the overall process.
• Quick guides – can be handed out on Day 1 to provide the basic quick reference information
• Floor walkers – staff from your own organisation or the vendor should be visible and available to business users.  Don’t have them tucked away in the IT department waiting for calls or emails, be proactive and deal with issues face to face!
• User groups – create informal user groups or networks so that users can exchange
• Lunch and learn – plan some lunchtime sessions on a regular basis after go-live.  These can either be drop-in sessions for general support or arranged around specific themes.  Just having the sessions available will provide reassurance to users.

In addition to putting in place some of the support mechanism above it is also important to have dedicated resources available to log and track issues.  No matter how much testing you did prior to go-live there will inevitably be system issues that will need to be prioritised and resolved.  Keeping the project team engaged and available for a period of time post-live will help ensure these issues are dealt with pro-actively.

Hopefully this short article will help you to think about the support that is needed after you have implemented your new system which will help stabilise the business and maximise the benefits of your new system as soon as possible.