Implementing a new software system requires careful change management that takes into account organizational culture and leans towards more communication rather than less.
The challenge
How do you manage the change of many people adopting something new that will change how they work? Often change is loss. People know how to do some aspect of their job, perhaps all of their job, and they feel confident and competent in their daily activities. Introducing a change in that will disrupt those feelings of competency and confidence. People need to learn something new to regain those feelings that they’ve lost. During that rocky period of rebuilding it’s important to support them to get everyone to the new future state.
Strategies
Before you even start to talk widely about a change you should design what the new future state is after the change and know how to describe that to many different people in the organization who all may do very different activities. It’s important to have the ‘why’ of the change be very clear and understandable. People need to buy into that future state as they’ll need to walk the rocky road to get there.
Coming from that future state design is a communication plan. Organizations always struggle with adequate communication. This time be the one to have a solid communication plan ahead of, during, and after the change.
You also should plan what will be the support system during the change and after. Is new documentation needed? Who will create it? How will it be made available? Who will answer the questions during the change?
Be cognizant of the ebbs and flows and business activities of your organization when planning the timing for the change. In higher education, changing anything during the start of fall classes is a bad idea. The organization is already taxed due to this major business activity, don’t add to that.
When it comes to executing the change, for me that’s typically a new software system that is either replacing an existing one or adding a new system into existing processes, there are some strategies you can do to reduce problems.
- Have a test group. This may seem obvious but it can be hard to do when timelines are tight. But this will help greatly identify some problems that you can address early.
- Avoid the single cutover for everyone when possible. If you are able to design a process where you allow people to opt-in to the change before a defined deadline, that will help both you and everyone else. The people who are ready for the change will sign up, be more tolerant of issues, and by doing that give you more opportunities to fix problems you did not expect. This will also reduce the burden on the support system you planned for the change by stretching out the calls over a large period of time rather than overwhelming the support system in one day. This also helps the support system refine itself as the load will increase closer to the deadline.
- When the cut over happens, again hopefully with an opt-in ramp up, make sure this change is the focus of your team. Much like being aware of the larger organizational ebbs and flows, within your team make sure this is focus.
Keeping these sorts of strategies in mind has helped me and my team accomplish major changes like switching to Google Apps for Education or rolling out multi-factor authentication. These changes have gone very smoothly and some projects I’m most proud of.
Image by mohamed Hassan from Pixabay