Most IT organizations have change management processes to manage the lifecycle of changes to IT services, both internal and customer-facing. These processes are the primary controls to reduce operational and security risks of change.
Change management processes often include approvals by external reviewers or change approval boards (CABs) to promote changes through the system.
Compliance managers and security managers rely on change management processes to validate compliance requirements, which typically require evidence that all changes are appropriately authorized.
How to implement a change approval process
Effective change management policies recognize that different risks are associated with different types of changes. Information Technology Infrastructure Library (ITIL) breaks changes down into three categories:
- Standard changes (low risk, no review required)
- Normal changes (higher risk, require review)
- Urgent changes (emergency and potentially high risk, require review)
You can reclassify most regular changes to standard changes, that is, changes that are pre-approved by the CAB, by having a reliable deployment pipeline in place. That way, your teams can show that changes are fast and reliable over a period of time (such as months or quarters). Teams can deploy without having to wait for approval, which speeds up delivery and deployment time, and improves stability.
Even when you categorize changes as standard, you must record them in change management systems, such as Remedy or ServiceNow. Ideally, you have your deployments performed by configuration management and deployment pipeline tools, which record the results. That way, everyone in the organization can have visibility into changes as they occur.
Common pitfalls in change approval processes
The following pitfalls are common to change approval processes:
Reliance on a centralized Change Approval Board (CAB) to catch errors and approve changes. This approach can introduce delay and often error. CABs are good at broadcasting change, but people that far removed from the change might not understand the implications of those changes.
Treating all changes equally. When all changes are subject to the same approval process, change review is inefficient, and people are unable to devote time and attention to those that require true concentration because of differences in risk profile or timing.
Ways to improve your change approval process
Research by DevOps Research and Assessment (DORA) shows that it's a best practice to use a lightweight change approval process, instead of using external reviewers and change approval boards (CAB). This leads to both speed of deployment and greater stability, as discussed in the 2014 State of DevOps report (PDF).
To improve your change approval processes, focus on implementing the following:
- Automated application changes can be promoted to production without manual change approvals.
- Production changes do not need to be approved by an external body (that is, change approval board, manager, etc.) before deployment or implementation.
- Include peer review for changes early in your software delivery lifecycle.
- When you discover automated changes that are not being automatically approved, work with stakeholders to find out why these changes cannot be automatically approved yet, and make improvements to the automation or the changes themselves in order to fix that.
Ways to measure change approval in your systems
Now your teams can list possible ways to measure change approval:
|Factor to test||What to measure|
|Can changes be promoted to production without manual change approvals?||The percentage of changes that do (or do not) require a manual change to be
promoted to production.
Tip: You can also measure this factor based on risk profile: what percentage of low-, medium-, and high-risk changes require a manual change to be promoted to production?
|Do production changes need to be approved by an external body before deployment or implementation?||The amount of time changes spend waiting for approval from external
Tip: As you shift approvals closer to the work, measure the amount of time spent waiting for approval from local approval bodies or reviewers).
You can also measure this factor by risk profile. Measure number or proportion of changes that require approval from external bodies, as well as the time spent waiting for those approvals.
|Do you rely on peer review to manage changes?||Percentage of changes that are managed by peer-review.
You can also measure this factor by risk profile.
While you consider your own environment, you will likely develop your own measures to understand and gain insight into your change approval processes. We suggest you use these to not only measure your process but also work to improve it.
- For links to other articles and resources, see the DevOps page.