When I speak to executives who are about to start a new system implementation project, their attitude toward change management is typically quite casual. They approach it as an afterthought, not something that is key to the success of the system.
Frequently they make comments like, “yeah, we need some change management, give me some of that” – as casually and as off-handed as if I’d asked them “do you want fries with that?”
One size fits all change management programs don’t work
Perhaps part of the problem is that people don’t fully understand change management nor do they recognize how they need to employ different change methods based on their specific needs.
Instead, I often encounter a perception that change management is basically just some communications and training. Experience has taught many people that you initiate the change management program after the system development effort has begun and you stop it after the system is live.
Unfortunately, this approach doesn’t work. In fact, it may actually be killing your change management program. It is time to rethink how we structure and deliver our change management programs.
Match your change adoption approach to your situation
Today, there are lots of different options for how organizations implement technology. Some systems take years of planning and development, where others are live in just a couple of weeks. Some systems are highly customized and others are deployed right out of the box. Some systems are stable and rarely updated and others have new releases every few weeks.
Each scenario has different change management requirements and challenges. You need to match your change approach to your specific situation.
3 scenarios that require different approaches
Here are three scenarios to consider. There are many more out there and we recommend checking to make sure you have the right change approach for your situation before you even start your project.
1. Long-term, slow-moving projects (major transformation efforts)
With long-term slow-moving, projects – like those that require many months (or years) of up-front planning and development – you can accelerate ROI by de-coupling the change and user adoption effort from the system go-live. This allows you to start the user adoption and organizational change program first, enabling increased organizational performance (ROI) even before the system is live.
Because so many of the reasons for poor user adoption are organization-based and lie outside the technology just switching systems doesn’t resolve these issues. By addressing these systems up front you can get more ROI out of your existing system. You also help separate any issues / resistance people have with the organizational change itself from their perception of the new system, thus people are less likely to blame the new system for organizational problems.
2. Short-term, fast implementations (cloud systems)
With short-term fast-moving, projects (think cloud systems) the technology can go live before the organization is ready for it. There is not enough time to setup the change management program itself, let alone conduct change activities to fully prepare users for the upcoming system.
In this situation, you need to cut the time it takes to establish your change program, deliver whatever change activities you can before go-live, and the retro-fit your change effort after go-live.
3. Ongoing, constant system evolution (agile development)
When your system is undergoing constant development, such as with agile development, your users face a situation of continuous change and instability. While this is a great development approach it is not great from a user adoption perspective. In other words, for the technology it works, for the humans beings, not so much.
Continuous development and release cycles have in effect transformed users’ learning curve into a learning treadmill. Users tell us that they never know what has changed and that they are constantly having to spend time searching for information or learn the latest changes to fields, layouts and functionality.
In these situations you need to make sure users have easy, reliable access to the latest information. They also need to access to support that can resolve both their technical and business process questions. Further, with each release of new functionality you need a communication effort. You also need to constantly review and update your policies, procedures, responsibilities, user adoption goals and metrics.
In short, if you have ongoing, constant development you need an ongoing, constant change management effort.
