All ITIL processes are interrelated, requiring input from and providing output to other processes. Many processes are dependent on each other, but the two processes that are the mostly highly intertwined are change and release management; the main responsibilities of change management are ensuring that changes are approved and that releases are overseen by the change process. I’ve managed many ITIL implementations over the years, and the same questions always come up with regard to these processes:
- Where does release management take over from change management?
- Should they be combined into one process or remain separate processes?
- How should we handle standard changes?
- Who should approve a change or release?
- What type of change classifications do we need?
Many organizations struggle with these questions. ITIL clearly states that these two processes are separate—but does this have to be the case?
I’ve sketched out two sample change and release management workflows below. When you compare the two workflows, you can see that a number of terms are similar (build, test, deploy). If we were to combine these two workflows into a single workflow, it might look something like the combined workflow at the bottom.
The checkmarks represent approval points in the process. Before any work can be completed, the change request must be approved. The request will then be handed off to release management as a work-inprogress (WIP), and release will build, test, and receive approval from the UAT testers. Then the business group and the change manager (or change approval board) have to give their approval for go-live. Once the release has been implemented, change management will ensure completion of the post-implementation review.
But if we’re just combining two workflows, have we actually combined the two processes? In the combined workflow illustrated at left, one could easily argue that it represents one combined process—even an ITIL auditor would agree!
Whenever there’s a one-to-one relationship between release and change management (i.e., one release for each change), it makes sense to combine the change and release workflows. As a combined process, change and release are easier to manage, and there’s less chance of slippage between the two processes. It also reduces the number of tickets that get created in the system, streamlines the end-to-end process of change and release management, and provides a more effective, efficient process.
The Importance of the Gatekeeper
One of the most important steps in the process, but one that many organizations often skip, is the change approval board (CAB) review that provides the initial approval for a change. This approval is quite important; in many organizations, the change process is itself often only an approval to release a change into production. The key reason to have this early approval is that it helps organizations manage their resources (a task that’s made more difficult when people are coming to the change process just to seek the approval to go live). If a change is ultimately rejected, then all the work that went into preparing the release is therefore rejected. In order to properly manage the process, the first change gate must be early in the process, before any work has started.
If your organization’s change process is merely a gatekeeper for releases, then who sets the priorities for the organization? This is especially important when working through more complex changes and releases. The combined workflow scenario works for one change and one release, but there are actually three scenarios to consider: one change, one release; one change, many releases; and one release, many changes. We saw that it makes sense to combine workflows for a one-to-one relationship. But does a combined release and change workflow work if there are many releases associated with one change, and vice versa?
One to Many
Let’s start by looking at the first scenario: many releases, one change. It would probably be too difficult to keep track of many releases using a single, combined workflow, so the diagram below illustrates the scenario as separate change and release processes. In the change workflow, Release WIP is where the related release request(s) would be created (e.g., many releases to one change). By combining the processes but keeping the workflow separate, the process can accommodate the creation of many releases related to a single change, and the overall process is easier to manage.
I’ve seen even more complicated versions of this scenario, where customers use a circular process to run different releases through a single, combined workflow. Typically, this circular process is used to look after a change that involves releases into different environments, such as test, training, UAT, and production. Each business unit must give its approval, cycling the release back to the CAB for review before the change can move on to the next environment. Final approval moves the releases into production, and they progress through the workflow to implementation and closure. However, it’s important to note that this process doesn’t work well for releases that aren’t related.
The final scenario involves many changes associated with one release. This case is similar to the first scenario, and as with that scenario, it makes sense to keep the two processes separate to ensure that the processes are well managed. Again, one could argue that if there are two separate workflows, there should be two separate processes. However, the true value lies in having a single authority that oversees both processes and ensures smooth handoffs, which might not be the case if you have two process owners (let alone two process owners who don’t work well together).
To further complicate matters, tasks could be used to track the progress of a release, instead of the full release workflow; these tasks would be subrequests under the change. For multiple releases, this could get messy, but it’s certainly a viable option for one change that has one release. It also works with standard changes, as request templates can be created to help track all the tasks that need to be completed, such as onboarding a new employee.
Change Types and Models
In change management, changes fall under different change types: standard, normal, major, minor, significant, emergency, and special request. Some are categories are defined by ITIL, while others will be based on the organization’s needs. Likewise, some workflows work better for certain change types than others. For more complex change types (normal, significant, major), it makes sense to separate them because more complex changes may have multiple releases for a given change, and vice versa. For more simple change types (standard, minor, emergency and the specific change types), combined workflows make more sense because the overall process is simplified and streamlined.
Standard changes are typically handled by the request fulfillment process, even if they require simple approvals for the acquisition of preapproved items, such as certain types of software. Standard changes are usually preapproved by the CAB, and they’re often low risk (i.e., little to no impact on the organization if the change fails). While there could be an approval step in the process for financial matters (i.e., the budget), these approvals come from the business side, not IT.
Minor changes might only require the approval of the change manager, not the CAB, whereas major or significant changes may come out of the project management office and require executive approval. While ITIL defines change types narrowly, you’re not restricted to just these terms; create as many change types as you need to make it easier to process changes. For instance, if your organization has a specific change process for software bug fixes, then consider defining a change type called “Software Bug Fixes” and use it to identify the information you need to collect and drive the workflow for that change type.
Also, in terms of workflow, consider what makes good sense for your business. Many of my customers take a blended approach, combining and separating workflows as needed. This flexibility makes sense from a management point of view, but in order to have this flexibility, an organization’s processes must work well together. Consider, for example, the approval issue. When I work with organizations, they sometimes think change management has to approve all changes. Regardless of how many approval points you have in a process, any individual or group should be allowed approve changes, releases, requests, etc., as long as they have the authority.
Conclusion
Is it really this simple? Not really—but remember, this is just a guide. Change and release management can be accommodated by the same process/workflow, but look at your organization’s change and release processes and do what makes sense for your organization. Think through the complexity of your changes and releases; generally speaking, the more complex the change or release, the higher the likelihood they should be separated. Divide the processes when it makes sense to do so, but don’t be afraid to use a blended approach. Bottom line? Use ITIL as a framework and do what is best for your business.
Mark Sherry is the responsible for Stroma’s ITSM division, which operates as Marval North America. An experienced ITIL/ISO practitioner, Mark has worked in all aspects of the field, delivering both consulting and training to customers globally and managing best practice implementation projects for more than twenty-five customers. He focuses on delivering strategic and tactical services that enable his private- and public-sector clients to see real improvements in service and gain efficiencies in delivery. Mark’s passion is making organizations better service providers through continuous improvement.