Implementing IT Change Management doesn’t need to be as overwhelming as it may it seem at first glance. In this article, I’ll show how to begin a basic IT Change Management program, especially for organizations with little or no other formal processes in place
Where to Begin
1. Start small and keep it simple
Identify key technical folks from each of the functional IT group (Network, Development, etc) to serve as a Change Advisory Board (CAB). Meet face to face with these key people weekly to review all planned changes.
Basic game plan:
- Identify a Change Manager to facilitate a weekly CAB meeting.
- All changes will be reviewed at the CAB ( Make CAB the place to be, and over time, the value of the review will attract “all”.
- CAB is comprised of technical folks and decision makers
- The role of CAB is to review proposed changes and determine if they’re likely to cause harm to the business. (Keep CAB focused on protecting the business from adverse impact, and don’t allow CAB to become a bureaucratic roadblock!)
- Maintain some form of Change Log to keep track of proposed and approved changes. (I’d recommend a spreadsheet, so you stay focused on the value of the process, and not the details)
- Track Change and outcomes (Free RFC Tracking Tool on my Resource Page)
- Establish an emergency change process to handle urgent and critical changes via email. (This is important to avoid the “too slow and bureaucratic” criticism)
- Over time, you want to see failed and rolled back changes decrease.
You’ll need to develop your own groove, based on the culture, but that’s the short of it. Keep it simple and focus on protecting the business from harm.
A flowchart for this basic IT Change Management process can be downloaded from the Free Downloads area.
2. Improve the CAB process
Principle: Use failed changes as opportunities to improve! (not finger point)
Use the outcomes data to identify ways to improve the CAB. For instance, for a failed change, are there things CAB could have anticipated and avoided the failure?
- Take time at CAB meetings to review changes from last week. If any rolled back or failed, are there any lessons to be learned that could improve the CAB process?
- If the lessons learned are small and doable, make them part of the CAB culture immediately
- If the lessons learned require more work, keep a prioritized list, and implement the high priority ones as opportunity allows.
- Ensure Service Desk and Operations staff are part of the CAB, and have access to the details of changes.
3. Celebrate Successes
By just bringing the CAB team together, this basic IT Change Management process is sure to uncover some sources of unintended consequences from proposed changes. When the CAB heads these off at the pass before causing customer impact, celebrate! Let senior management and key business stakeholder know that the process discovered and avoided business impact.
Get Started
What I’ve described here is very basic, and completely consistent with IT Change Management. ITSM is all about Value to the business, and getting started is way more valuable than discussing if, how, and how much Change Management to implement.
Be sure to check out Five lessons learned implementing IT Change Management, and How to Measure a Basic IT Change Management Process.
When your organization is ready, take a look at How to Mature a Basic IT Change Management Process to take the next steps.
Questions? Comments?
How do we categorize change type without any tool?
Is a great question. My favorite is to manage basic change managment on a spreadsheet – It’s one of the free resources available under Resources/Free downloads (http://itsmtransition.com/downloads/free-downloads/). Have a look and let me know what you think.
Hi Greg,
It is indeed quite a thought from Anupreet. I am quite interested to have a look at the spreadsheet.
How feasible it is to manage the lifecycle of a change using the spreadsheet?
Thanks!!
Deepak
It’s very possible, i’ve used it before when implementing change management in organizations with neither ITSM tools nor established processes. Obviously it’s very dependent on the organization and its culture. The reason I recommend using simple tools is that it keeps the focus on the process and its outcomes – not on the implementation of a tool. If the organization has good tools (there are many) – i would still suggest working out the process first using simple means.