Everyone’s heard that IT causes the majority of incidents when changes go wrong, but is it really true? Are 80% of all incidents change-related?
When things go bump in the night
Sometimes the root cause is an unusual combination of naturally occurring variation in the system, so not a ‘change’ in the change management sense. But a change, nonetheless. It’s not like it was before, and for it to be in a different state – something had to have changed.
In that sense, then, it could be said that 100% of incidents are caused by changes. Perhaps that’s the problem with “80% of incidents are caused by changes” statement.
I recently kicked off an unscientific twitter poll to see what you think. Do me a favor and take the poll so I can get some good data. I’d appreciate if you’d share it too, so I’ll have good results to share when the poll closes.
— Greg Sanker (@gtsanker) August 12, 2016
With the survey’s limitations duly noted, it’s immediately obvious there’s no clear consensus on the percent of incidents attributable to IT changes.
“It depends” is perhaps the clearest conclusion we can make for the relationship between changes and incidents.
It depends on the organization itself, things like:
- Size of the company
- Size and makeup of the IT organization
- Complexity of the IT infrastructure
- Nature of the business
- Rate of change the business requires
- Types of technology in use
On closer inspection
Looking at the combined percentage who believed IT changes accounted for 50% or greater of all incidents, the number is close to 40%.
Think about that – 40% think half or more of all incidents are change-related.
A full 75% believe 20% or more of all incidents are change-related.
The survey is simplistic and the sample size was small, but there’s no getting around IT changes being a widely understood cause of incident.
And that’s not just a numbers game, because when changes cause incidents, customers are impacted.
Real customers; real impact.
Which can be really hard to quantify. But consider that even a single PC that can’t connect to the corporate network, when it’s the CEO closing a multimillion dollar deal, can be catastrophic. A financial analyst unable to get critical financial information from the data warehouse can jeopardize the company’s credit rating. A single change-related incident can impact hundreds or thousands of users who cannot do their jobs.
While changes may not cause the majority of incident, in the estimate of IT professionals themselves, they cause more than just a few, and that’s never a good thing.
Change management is all about value realization – the results changes enable the business to accomplish. When business-required changes are timely and effectively implemented. When risk is appropriately managed. When negative impact is minimized. When changes achieve the outcomes the business had in mind.
Anything less won’t due. No matter how you count it, badly managed changes negatively impact customers.
Supporting the business need for change
But you already know that. None of this is really new.
And if the rules were simple, the plan would be clear – no changes go into production until they’ve been thoroughly documented, discussed, tested, reviewed, debated, second guessed, over sighted, approved, released, and otherwise beaten into the ground.
But there’s this little thing about matching the rate of change required by the business.
The question is not ‘how fast can IT review changes with perfect results?’ Rather, the question is ‘what rate of change does the business require?’
The answer to the latter becomes the key requirement of your IT change management capability. How to match that required need for speed while maintaining acceptable levels of risk mitigation and impact reduction is the heart of effective change management. Reframing of the question is important because the key lies not in ‘doing the same thing, only faster’.
DevOps opens the door to meeting this very goal, but requires some radical changes to traditional change management. Has DevOps rendered traditional change management hopelessly outdated?
Of course it has, but what it hasn’t done is eliminate the outcomes Change Management helps achieve. Different, yes, but obsolete, no.