Is there really anything wrong with “un-managed” changes? Or is Change Management a contrived problem trumped up by ITIL zealots to sell training and consulting?

My daughter is playing Marian the Librarian in her high school’s production of The Music IT Change Management: Trouble in River City?Man. “Professor” Harold Hill comes to River City to scam the locals into buying instruments and uniforms. His pitch? You need a marching band to keep your kids out of trouble. His friend, a local, informs him “… but River City don’t have no trouble”. Undaunted, he responds “…then we’ll have to create some.”

Is it possible that ITIL is actually Harold Hill in disguise, proclaiming “oh, we’ve got trouble, right here in EyeTill City. Un-managed Change! With a capital “C”, and that rhymes with P, and that stands for pool! Oh! We’ve got trouble. We’re in terrible, terrible trouble”

ITIL gets a lot of bashing for making a big deal out of things that IT staffers have been handling quite nicely for years, thank you very much. The argument is that smart, dedicated IT people, who are empowered to do the right thing can act quickly to both implement needed changes, and  respond immediately to Incidents when they arise. There’s an implied insult that they require a board of advisers to review their work to avoid catastrophe. Who needs it? Just slows everything down, when our customers deserve better “Customer Service”.

Change Management seeks to minimizing the number and impact of incidents caused by changes. By some accounts, Changes cause as high as 70% to 80% of all Incidents. (Andy Hogg over at Computer Weekly offers his insight in  ITIL to take the pain out of change management).

Formal Change Management is a powerful first step in getting a handle on the IT infrastructure. If you start with a simple review of all changes, and keep records of outcomes, you can  begin to understand the impact of changes in your environment.

One of the classic Change Management objections is that all changes (including very minor ones) are delayed until next formal CAB meeting, and reviewed by the whole CAB team. With a better understanding of the type and nature of change-related incidents, you can implement a change authority aligned with your real risk/benefit profile. Pre approved standard changes, and change authority delegated as low as practical avoids the micromanagement of smaller, less risky changes , and keeps CAB focused on larger, higher-risk ones.

The goal of Change Management is to increase positive business outcomes in the form of favourable results from planned changes. Beyond that, organizations who must demonstrate  compliance must be able to demonstrate that due diligence has been applied to changes.

IT systems have become far too complex for any single technologist, regardless of skill and experience, to anticipate and evaluate all possible outcomes of a change.  Having the right team review changes prior to implementation greatly reduces the number of change-caused Incidents.

Un-managed changes leaves operations staff without critical information that would help more quickly identify and resolve issues when they do arise, increasing the business impact of Incidents.

Far from being a trumped up charge by ITIL consultants, un-managed changes are an avoidable source of Incidents. With the mountain of evidence that Change Management improves business value, IT professionals can no longer afford to be caught flat footed.

My next article will focus on How to Implement Basic ITIL Change Management.