A Change Control process is essential to help track requests for system changes, assess feasibility, make and test the change, put it into production and alert your organization. Here, I talk about implementing and communicating your changes. In previous posts I covered How to Put a Change Control Process in Place (Part 1) and Change Control Decision-Making (Part 2).
Documenting Tests and Results
Always test the change before moving it into your production environment. Your documented outcome should set the stage for how you’ll measure the success of your change after Go-Live.
In developing your testing plan, be sure to assign Subject Matter Experts (SMEs) to document, test and records their results. Keep a record of the testing and present the data to your Change Control Review Board. They can provide additional feedback or may think of scenarios that have not been considered. Test additional scenarios if needed.
This testing template will guide retests of the change after Go-Live. Before moving the change into production, develop a plan to revert the change should it compromise the integrity of the system or impede your operations.
Implementing and Communicating Your Change
Now that you have tested and approvals are in place, schedule a firm Go-Live date.
Determine if your request requires system downtime. I recommend transitioning changes to a production environment off hours, when users are not on the system or at the very least not accessing the system in the area you are making changes. Doing what is least impactful will eliminate unnecessary errors and downtime during the workday – and the headaches that brings.
Most importantly, it gives you the room and space to calmly re-test your changes in production before your user get back in there.
Make sure the Go-Live date selected gives you ample time to communicate those changes. How best to communicate the change depends on the audience it affects and the type of change made.
If emails are commonly used to give your users a heads up of upcoming changes, you may want to create various distribution lists based on job role or function. Inundating your users’ inboxes with emails that do not affect them or their job role will more than likely put you on their disregard list.
Changes to design, workflow or function will require a different approach than simpler changes. Consider these steps in advance so your users are ready for the change:
- Introduce the product or the resulting change in some of your meetings
- Provide a demo or set up a WebEx to demonstrate the new workflow
- Create job aids
- Update your end-user documentation
- Leverage your training resources to set up classes if the change requires hands-on practice
There is no perfect or one-size-fits-all model. Your Change Management System, your controls process and your communication methods will evolve as the nature of your business and technology change. As Heraclitus once said, “The only thing constant is change.” The change management process can help you keep momentum and maintain a stable environment.
How does your organization communicate new changes? Let us know what’s working for you.