T: +44 (0) 203 287 4191

Embedding change following a systems implementation project

If you have been following my blog series on managing technology and systems change you will have read 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 systems change in a people-based organisation (i.e. most businesses!), initially creates chaos as people get used to new and unfamiliar ways of working.  This is highly likely to cause a drop in business performance because your staff are less efficient and less effective doing their job.  In services-based business that I mostly work with (offshore finance and legal services), this will be manifested in a lower utilisation rate (chargeable time booked to clients), an increase in write-offs or just more time to carry out simple tasks.

This effect is entirely normal and is known as the ‘J curve of change’ as shown in the diagram below.

J-curve of change

The J-Curve of Change, by David Viney, licensed under CC BY 4.0

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 the team will be disbanded at this point because the project will have been deemed as ‘completed’ – when in actual fact this is where the real hard work starts!

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.  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.

Kotter 8 Step Change Model

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.

One Response

Leave a Reply

Your email address will not be published. Required fields are marked *