My world is about to change, and it got me thinking about the fragmented way in which change needs to be managed for business systems.
Within the next 12 months Linked Training will install a new training management system. This is the core business system for our organisation, and the change will impact every staff member, and provide our clients with some changes as well (such automated diary entry of booked training). In general our staff are enthusiastic about this change.
At the current rate of technology advancement there will be a similar significant system change in most organisations within the next 3 to 5 years. The level of actual change will vary, and the level of apprehension about it will also.
I like to think I have the benefit of being part of similar transformation projects every day; of a bird’s eye view of the change issues I will have to address. I’m also highly aware that current approaches to change management in most organisations are inadequate. As a rule the transformation project manager will not be a change management professional, and even though a change manager may be included in the project team, or a change plan included in the project, the scope of it will be limited to the experience and focus of the project manager.
There are 5 key areas of change to be addressed in a transformation project.
Alignment of expectations with reality from the outset is important. This means understanding how your audience thinks and feels so an appropriate communication plan can be established and implemented. Even when your audience is enthusiastic this is just as crucial. The level of disappointment when the tangible business system does not deliver what the imagination of individuals had assumed can derail a project when you reach implementation.
Take nothing for granted here, and always take action.
Technology change management is far more than ensuring the cut over at Go Live to the new system is super smooth. In reality that is project planning, and managing expectations within the project team so there are no assumptions all will be fine and any risks are addressed.
Comprehensive technology change management ensures users are provided with smart systems that meet your business need, whilst not imposing increased workload on the user. If a user is faced with screens that are difficult navigate, manual transfers of data, more clicks for the same result and unintelligible actions they will struggle to adapt to the change.
Most business systems are databases that can be manipulated, configured and programmed to achieve minimum data entry and streamline existing processes. Whilst that may be phase 2 of a project it’s important a backward step is not taken in phase 1, and there is adequate communication around this.
Take the time to educate yourself on what is possible and best for your end user. Test proof of concepts, and don’t assume you fully understand user requirements without doing so. More time needs to be dedicated in this area, and less discussing the best available match to corporate colours.
New technology will bring changes to business processes. In some systems at the initial Go Live you may only wish to ‘replicate’ current processes, but it is highly unlikely there will be an exact match. Investigate what processes will be impacted. Plan and test the new in a test environment. Communicate how the changeover on the processes will be managed and supported.
Even if the new system will highly automate a process people will still need to understand what is happening behind the scenes to have confidence the new system will provide the right outcomes. Poorly informed people cannot identify errors and exceptions, and unreported issues may continue to the extent they cause major business disruption and loss of system support.
Skill & Knowledge
Do not assume the system is intuitive and therefore no training is required. Conduct a training needs analysis to discover the skill and knowledge gaps that exist, and the appropriate strategy to address them.
In a recent implementation for an IT based organisation there was no capability issue for 90% of the staff and therefore the training time could be minimised. There was however a knowledge void about the purpose of the software and how to make decisions within it and this needed to be addressed separate to the technology training.
The design and delivery of training must provide clarity and ease of understanding of the system. Don’t accept training that confuses the audience and detracts from the benefits the system is designed to provide.
Good training encourages users to try, and they will go on to feel confident it is worthwhile requesting support when they need it.
Change is difficult because it requires people to give up existing habits and practices. We all like our comfort zones, and it’s easy to do what is familiar.
Even when the change is perceived as good, changing behaviour can be difficult. The number of reluctant or slow adopters may be low, but they will still have to be addressed.
This is the most difficult part of change management to perform for the inexperienced. There may be many stakeholders behaviour which requires change, and it will not be only their process behaviour. It may include their behaviour in team meetings and other communications. It is a potentially delicate area with an overlap into performance management.
Bringing the Fragments Together
Each fragment has a relationship to all other fragments and should not be addressed in isolation. The subject matter experts in project management, communication and training within the project team must be educated in change management to the level they are aware of the likely change issues and can work with the lead change manager to support the change strategy.
Comprehensive change awareness, early identification of change issues, and a consistent strategic approach is necessary to deliver a healthy change.