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

IT systems are complex, but if you take a step back from the details – when a system suddenly stops functioning properly, something has to have changed, right?Change-Related Incident

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.

Change-related Incidents

Meanwhile, Robert Falkowitz offers a detailed analysis of his admittedly unscientific survey undertaken on this very topic. (See the causes of incidents.)

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.

Myth Busted.

“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.

Customer 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?

I’m speaking about Change Management in a DevOps World at Fusion16 in November. The session will show a practical approach for maturing your traditional change program. I’ll cover the key differences between change enablement and change management, and how you can integrate DevOps into your change management capability. You’ll also see what legacy change management mistakes you can kiss goodbye.

I hope to see you there.

Photo Credit: sidehike via Compfight cc