If there’s one inevitable thing in IT service management (ITSM), it’s change. Change requests happen whether you want them to or not. And that’s OK, good even. ITSM changes are a necessary and healthy part of any public or private organization’s business.
But if change requests aren’t properly handled, they can cause significant issues for your team and your wider organization. And here’s something we’ve noticed: often, it’s not the ITSM change itself that causes the most disruption. Instead, it’s not having a reliable process for handling change requests that derails your operations the most.
Change is an inherent aspect of every industry, from transportation to commerce, municipal services to education. Every organization must navigate the constant changes of today's world.
You don’t need a 100-page change management policy to do it right. In fact, we find the simpler, the better.
Let’s dive into what goes into a good change request and share our straightforward five-step change request process that any organization can adapt for their needs.
What is a change request?
A change request is a formal proposal for changing some aspect of an agreed-upon project, IT service, or other business operation. Change requests can come from within your organization, from your customers, business partners, or other stakeholders.
A reliable request for change (RFC) process will lead to greater internal efficiency, reduced organizational risks, and better alignment among all your business units. Change requests are an essential part of change management—a core principle of ITSM. The change request is the initial documentation that helps you build a digital paper trail to track changes to complex systems that might have unexpected consequences—small or large—down the road.
What are the different types of change requests?
You may choose to develop your own categories, but generally, under ITSM best practices, change requests are categorized as standard, normal or emergency.
Standard changes
Standard changes have well-understood consequences, typically either because they’re small in scope, so all variables are easily accounted for, or because they’re recurring, low-risk and well-documented. As a result, standard changes typically can be addressed immediately and do not require additional authorization.
For example, requesting additional storage capacity in your company’s cloud environment is often a standard change request. All the systems involved are well-understood, as are the scope and consequences of the change.
Normal changes
Normal changes must be scheduled due to one or more factors and always require authorization. They involve novel or far-reaching changes to your operations or infrastructure. They are “normal” in the sense that they must go through your normal change request management process of review, analysis and authorization.
For example, acquiring new cloud infrastructure to support new business operations would be a normal change request. Adding that new service could have far-reaching consequences and must be reviewed by key organizational stakeholders.
Emergency changes
You must address an emergency change immediately, and the requesting authority within your organization has authorized that it cannot wait for your normal change management process to complete. For example, pushing out unscheduled security patches to production servers due to a just-discovered zero-day exploit is a common emergency change request in IT.
Simple 5-step change request process
Your change request process should be thorough, but it doesn’t need to be complicated. In fact, the less chance for human error, the better. Here is a simple five-step change request process any organization should be able to adapt for their needs.
1. Formalize Request for Change (RFC) intake
As we’ve discussed, changes can have significant, unexpected, long-term impacts if they’re not properly managed. That means users shouldn’t initiate a change on a whim. Instead, have a request for change (RFC) form that requires submitters to document all of the essential information authorizing agents will need to assess the request.
The specific information you’ll want will vary, but for most changes, you can’t go wrong by requiring the requester to document the 7 R’s of change management:
- Who raised the change request?
- What is the reason behind the request?
- What is the return required from the change?
- What risks are involved in the requested change?
- What resources will be required to deliver the change?
- Who is responsible for implementing the change?
- Are there any relationships between the requested change and other changes?
2. Evaluate the necessary effort for each change
This step is critical as it helps your team define requirements and set customer expectations. Responsible teams should evaluate all newly-received changes. Of course, that goes for standard changes, too. Their evaluation just happens in advance.
Evaluate what effort will need to go into each change request according to the information received. Ask follow-up questions as necessary. Then estimate the effort required to implement the change request.
3. Analyze the impacts of the change
Before you implement anything, analyze the potential impact of a change. To do this, we will use the information provided in the original application and identify risks to the following level:
- Customers, infrastructure and customer service capabilities
- Consequences if we do not implement this change
- Resources required for this implementation
- The implementation schedule and the interruption of service
It is often a valuable exercise to categorize the various risks using a simple matrix that considers their probability and impact. That allows you to question the advantage of making the requested change against those risk factors.
4. Implement the RFC in a structured way
Up to this point, you’ve only been collecting and analyzing data about a potential change. Now it’s time to authorize it and implement it. That takes more than just a director making a yes or no decision.
At this point, you should bring the RFC before your organization’s Change Advisory Board (CAB). The CAB is composed of all relevant stakeholders connected to an RFC. For example, an infrastructure change request should have senior members of your infrastructure team on its CAB.
They will decide whether to approve or not to approve the change. If approved, you then follow your established implementation process. C2 recommends you follow a few specific implementation steps.
- Build the change
- Conduct a test change
- Develop a comprehensive plan for the change deployment
- Then implement the change
5. Provide post-implementation monitoring
There is still work to do after implementation. Monitor the system or systems you’ve changed for any unforeseen problems. If any arise, you’ll need to troubleshoot them and determine whether to move forward with a fix or roll back the change. It is also important in the post-implementation stage to identify lessons learned that might inform future implementations.
Easier change requests are just a few clicks away
Establishing a reliable, consistent and easy-to-follow change request process is essential for any organization following IT service management best practices. A reliable change request tool, like C2 ITSM, can help ensure every change request is easily evaluated, scheduled and implemented.
C2 helps you manage every incoming RFC, large or small, standard, normal or emergency. Every action is automatically logged, so you always have complete insight into what is happening.
