Every IT department has had to deal with changes to applications, networks, and systems. Most mature IT departments have a well oiled change management process. I’m often surprised when I meet people from smaller IT shops to find out they don’t have any semblance of a change process. Nothing. I’m not talking about companies with five people mind you. I am talking about companies with $250M in annual revenue and an IT department with 20 or more people. how do these companies mitigate risk? How do they align with their core business? In this article I am going to cover something every IT department should have. Let’s learn how to write a change management policy.
How to Write a Change Management Policy
Writing a change management policy doesn’t have to be that hard, or even take a lot of time. I will even provide some links to some templates that will make it even easier towards the end of this post. Before we dive into writing one, lets briefly walk through why they are important in the first place!
Why We Need Change Management
Change management isn’t just a fancy IT buzzword that we IT Leaders throw around to stop progress and control our teams (as some in the IT fields seem to think). Change management actually exists to make our IT departments better. To help align them with the business and to help them mitigate risks where appropriate.
1. Ensure Alignment with Business Needs
Although, all of the reasons for change management are important, this reason is in my opinion the most important and should be at the top of your list as you discover how to write a change management policy for the first time. Let’s be honest here. The fundamental reason that a business exists is to generate revenue. This revenue is what keeps the lights on, funds R&D for new products, and finally pays the salary of the employees. Businesses want to optimize this revenue. If the business is a public company they also need to drive shareholder value which means consistent revenue growth year over year.
Change management is an opportunity to make sure that the changes we are making in IT align with the core strategy of the company. It doesn’t make much sense to put in a slow network link between to a branch office building in the name of cost savings if the business has plans three months down the road to double the number of employees in the that branch office.
2. Optimizing Business Risk
The second most important reason for a robust change management policy is to optimize business risk. While this might seem like a “no brainer” at first, its amazing how often this exact situation is overlooked as part of IT change management.
If a storage engineer has been asked a server administrator to add an additional LUN to the ERP system on Thursday night because the /logs folder is full and he would like to keep an additional 30 days of rolling error logs, the change management process should catch that the business has to close the books Friday morning in the same ERP system. The change should be rescheduled to occur after month-end closing to mitigate any risk to that system. An outage after closing would be much less impactful after closing than the day before should something go wrong. As you learn how to write a change management policy, keep business risk in mind!
3. Ensure Timely and Successful Change
Three on our list is less about mitigating risk, but rather making sure we have the right parties, tools, access and other needs in place before the change occurs. In our ERP example, the storage administrator may not have the level of rights he needs to implement this change. In order to ensure a successful change and prevent delays, the security administration representative at the change approval board commits to making certain the storage administrator has elevated privileges during the change window.
The second thing to consider is coordination of changes. Sometimes resources and/or system changes can overlap. A robust change management policy will make certain that the same network administrator isn’t responsible for doing multiple changes at the same time. Or that two changes to the same system happen in tandem rather than simultaneously.
4. Records of Changes for Later Review
If you’ve been in IT for any length of time you’ve probably made or heard this statement numerous times when a system or application starts misbehaving: “What changed recently?”
It’s true, most system instability or outages occur do to changes that were made rather than because of hardware failures. Although the latter does happen. Having a good change management process gives IT leadership and systems engineers a log book to go look at when system outages happen. This log book may well remove the veil of the otherwise unknown reasons for an outage. For example, if your system has lost connectivity to Port 161 for SNMP queries to the network management server and change happened last night called “SNMP firewall rules update for network 10.x.x.x” you can bet that’s the reason!
The 7 “Rs” of Change Management
As we learn how to write a change management policy, one of the most common processes people think about is something called the 7 Rs of change management. These 7 Rs as they are called are the basics that every good change management policy should cover. These should be recorded on your change management forms, and presented to the change management board.
Who raised the change?
What is the reason for the change?
What is the required return?
What are the risks involved?
What resources are required to deliver the change?
Who is responsible for building, testing, and delivering the change?
What is the relationship between this change and other changes?
Measuring The Effectiveness of Your Change Management Policy
An effective change management policy should include KPIs (Key Performance Indicators) that give IT leadership and the IT governance practice something to measure against. These metrics will help you guide your employees and the business to a more effective use of change management and to make sure the change management policy accurately reflects the needs of the business.
Change Management KPIs
As you discover how to write a change management policy, these are the key metrics I recommend you explore for inclusion in your own. Though more advanced or larger organizations may include many more.
Compliance with Change Management
An effective change management policy should see the following key metrics trending in the right direction.
- You should see a relative decrease in unauthorized changes being performed.
- Proper planning and management cycles should see a decrease in emergency changes.
Effectiveness of Change Management
If the change management policy is effective, you should immediately start to see the following trends:
- An increase in the percentage of changes that are successfully implemented (less changes backed out).
- A decrease in defects and rework.
- A decrease in incidents and outages caused by changes
The Six Steps of the Change Management Process
An formal change management process is generally broken down into six steps. These steps follow the life-cycle of the change from inception to its completion. Each step must be included and none should ever be skipped.
Submission – A change is identified as required and a change request is submitted. The change must be evaluated and prioritized. The risk of the requested change is determined.
Planning – Plan the change at the team level, including the design, scheduled time, communication plan, test plan, and the back out plan should something go wrong. The planning step is also referred to as an “impact analysis” in many organizations.
Approval – During this step the proper approvals should be gathered from leadership, key stakeholders, and the change approval board.
Implementation – At the agreed upon time, the change will be implemented.
Review – Communicate and review the change with your team and the change approval board with the outcome (success or failure). If the change resulted in a service or system outage, a mitigation strategy for future occurrences should be completed. Finally, for a successful change, document all aspects of the change for review later as discussed above in the “Why we need change management section?”.
Close – The change is closed out and archived in the change management database.
Final Thoughts on IT Change Management
As you work through how to write a change management policy for your organization, keep in mind that your IT Change Policy should be aligned to your Business Change Policy. If your company doesn’t have an overall change process this might be a great time to engage your business partners outside of IT and try to accomplish a larger goal. However, beware of the “scope creep” as he will try to derail you. It’s better to have an IT change policy with no umbrella at the business, that to be without.
Finally, think of change management as existing to enable your business rather than hinder it. Make sure that each CAB and team looks at change as an opportunity for success and empowerment of your employees rather than a layer of control. While that may sound simple, it will make all of the difference as to whether you’re successful or not in your change management process.
You can also download our free change management policy template.