We recently held a webinar about change management, which happened to fall on the first day of autumn. As nature’s most colorful reminder of the old making way for the new, the changing season reflects a shift in how modern organizations are approaching change management.
Software vendors and IT organizations used to make major releases once a year, and minor updates perhaps once a quarter. That world has changed now, with web companies moving to an agile and DevOps model that aggressively updates production applications. Changes that used to happen quarterly are now happening weekly, with companies like Facebook and Amazon known to make thousands of changes on a weekly basis.
While most companies do not require such a high rate of change, the average number of requests for change (RFCs) is on the rise. According to a Pink Elephant survey, the average IT organization closes 1,376 changes per month, with 10 percent of respondents reporting more than 5,000 changes per month!
Addressing the Challenges of Change
The need for business innovation is driving the new rate of change — whether the changes are for a customer-facing application like an eCommerce system, or an internal business processing system like a quote and invoice application. At the same time, IT complexity has increased the risk of changes as well as change process approval time, because multiple systems, teams, and often multiple timezones are involved.
As a result, IT operations and applications developers alike face several challenges in driving change rates higher. The good news is that analyses of historical changes can uncover patterns, clues, and insights that help IT leaders drive change velocity higher and reduce risk of outages or service degradations. IT leaders can also use data analyses to increase change throughput without adding additional staff or steps to the process. Let’s look at a couple of examples of how this can be possible.
Change Risk Evaluation
The biggest change risks are that the change will lead to an outage or service degradation or create a surge of incidents. To balance risk and change velocity, most companies have a change approval board (CAB) that evaluates change history and sets up guidelines to increase velocity while identifying the riskiest changes. Boards need data and insights into past change performance, so that they don’t rely solely on developer-reported information or anecdotal evidence. The good news is that a lot of data is already available to evaluate the risks of RFCs in your IT service management and operations systems.
Analyses like the one below can show which changes have been responsible for service degradations or outages, and how long those outages lasted. Managers can interactively explore which components or applications are most likely to cause service issues, and develop a separate evaluation track for them.
In the above dashboard (based on demo data), the bubble graph shows the number of changes closed on the x-axis, the number of outages on the y-axis, and the mean time to restore service (MTRS) as the size of the bubble. Here, the SAP BW application has the highest number of changes, but very few outages. However, each of the outages lasted for a long time and had a very high MTRS. Perhaps the core reason for this is a lack of bandwidth among key engineers with the necessary skills. If this system is critical to business processes, then changes should be carefully evaluated.
The bottom left diagram further describes the relative risk of this system as compared to other systems. The outer ring breaks down the high/medium/low risk changes introduced for SAP BW, while the interior ring shows the averages for this IT group. Additional information on the dashboard helps change managers understand the likelihood of changes failing and needing to be rolled back.
On the positive side, applications with low risk based on past performance can be given default approvals for a specific set of changes. In the above dashboard, this application is shown lower down on the y-axis and appears as a smaller bubble. In this case, it may be that the application group’s code is cleaner or that their systems are less complex and therefore safer to make changes to. Regardless, this application appears safe to bypass CAB for a certain set of changes.
Change Success/Failure Rate Evaluation
Even if changes do not result in any service issues, it’s possible that some changes tied to specific configurations or services have a low success rate. In that case, an analysis like the one shown below can help evaluate the likelihood that the change will actually go through. The dashboard shows not just the historical success rate, but also the specific configuration items likely to cause failures. In addition, the radar chart shows the relative success rate for the Top 10 configuration items (CIs).
To quote a business cliche, change is the new constant. With modern businesses increasingly relying on technology, rapid innovation can create competitive and operational advantages both internally for the company and externally for their customers. What methods, techniques, and processes have you leveraged to push change velocity higher and reduce risk? Have you used data to figure out how to improve change performance? Let us know.
Find out more about how analytics can help your team drive change management innovation in our exclusive change management webinar.
[Photo courtesy of Flickr user mendhak.]