Change management has continued to be a hot topic on social media and customer inquiry. As a process symbolizing traditional IT service management and the ITIL framework, it’s under increasing pressure to modernize in response to agile and DevOps trends. However, change management emerged for a reason, and I think it’s prudent to look at what, at its best, the practice actually does and why so many companies have used it for so long.

This is the topic of my recently updated research, “Overcome Change Management Paralysis.” In this report, I cover the reasons for the change process. It has legitimate objectives — coordination, risk reduction, audit trail — that do not go away because of agile or DevOps. The question is rather, how does the modern, customer-led digital organization achieve them? The classic “issue a request and appear before a biweekly change advisory board” is one way to achieve the desired outcomes — and likely not the most effective means, as I discuss.

I don’t believe change management will ever go away. My recent state of modern technology operations research indicates that effective change management is strongly correlated with superior availability outcomes — some of the strongest statistical correlations in the report.

But the practice does need to be revamped. Organizations still misapply heavy change management practices to low-risk changes. A significant percentage in our research were still referring all changes to a change advisory board (CAB), regardless of risk. In our findings, referring all changes to the CAB is not correlated in any way with better availability, business results, or change failure rate. (The Accelerate research found that referring all changes to the CAB is correlated with worse software delivery performance.)

Manual documentation of changes; lengthy change-approval delays; large, biweekly face-to-face CABs; and reviewing all changes, regardless of risk, are no longer essential or suitable to a modern change practice. Organizations pursuing agile and DevOps agendas are already changing their approach. The change process is increasingly automated; in some cases, release automation tools autocreate and update change tickets via APIs. Certainly the robust audit trails inherent in modern continuous delivery toolchains enable the original intent of change management with far greater rigor than any manual process ever could. Organizations adopting product team models (correlated with agile transformations) are less likely to see a CAB as essential. Furthermore, we found that organizations who have taken action to streamline their change process were much more likely to report superior business performance.

And yet, the change process itself retains support. Organizations undergoing an agile transformation were more likely to view their change process as effective at identifying risk. They were strongly likely (p ~= 0) to view their change process as essential to coordination.

So what are we to make of these somewhat contradictory findings? Ultimately, change management is transforming and becoming more transparent and integrated into the overall software delivery pipeline, but its concerns never vanish. A few of our recommendations:

    • Question your CAB. Forrester is increasingly hearing accounts of organizations reducing or eliminating the change advisory board but still maintaining a change process.
    • Track the right change metrics. Change failure rate has long been a popular metric, with some organizations seeking zero failures. In isolation, seeking this can be destructive (we go further into the reasons in the report).
    • Turn to modern analytics. Automated technology pipelines have rich data begging for analysis. Continuous delivery and release automation (CDRA) vendors such as CloudBees, Digital.ai, and IBM Urbancode are innovating here under the label of “release readiness.” Enterprise service management (ESM) vendors such as Micro Focus and ServiceNow are increasingly applying advanced machine learning to change risk assessment. Evolven is a noted specialist vendor in the field of change analytics. Ultimately, Forrester predicts the convergence of CDRA release readiness with ESM change management (see graphic below).

Note: People may point to the Accelerate/State of DevOps research as “disproving” change management as a process, but this is inaccurate. That research focuses on whether approvals are centralized or decentralized — not whether a change process should exist at all. In fact, the Accelerate work implicitly supports a change process, as one of their fundamental performance criteria is “failed changes.” If you are tracking that metric, in my view, you have a change process. (See pages 78-81 in the book Accelerate: Building and Scaling High Performing Technology Organizations by Dr. Nicole Forsgren et al., which goes into depth beyond the State of DevOps reports.)

The scope of this research is the operational change management practices associated with IT and digital organizations, especially in terms of controlling technical resources. Organizational change management is a different topic not addressed here.