By Doug Tedder

Is your change management process broken? If your answer is “yes”, you’re not alone. In my experience, many organizations are dealing with a broken change management process.

What’s broken?  Typically, it’s one or more of the following:

• Many organizations don’t follow ITIL guidance of obtaining authorization before doing work, which undercuts many of the benefits of the change management process.
• The Change Advisory Board (CAB) is treated as an approval body and not as an advisory body – and even then, becomes involved too late in the change lifecycle.
• Many organizations force every request for change (RfC) through a CAB, slowing down the implementation of change.
• The CAB is made up of people who are not qualified or are disinterested in being change advisors.
• The criteria for evaluating RfCs are not documented, much less defined.

On the other hand, has ITIL’s guidance regarding change management become outdated in this digital age? Perhaps this was one of the drivers in the morphing of ITIL V3’s Change Management process to the ITIL 4’s Change Control practice. But “change control” in ITIL 4 is not the same thing as “change management” in ITIL V3.

It is a natural tendency to equate what ITIL 4 calls “practices” to “processes”, but to do so would be incorrect.  Practices are more than just processes. ITIL 4 defines a practice as sets of organizational resources designed for performing work or accomplishing an objective.

In many cases, there may be (likely are) non-ITIL based processes, techniques, and approaches involved in delivering the outcomes needed or expected to accomplish the objectives of a practice. Change control, for example, may utilize several techniques to accomplish its objective – to make valuable changes to a managed environment, depending on organizational needs.

Practices enable flexibility and consistency

Practices provide the flexibility for organizations to leverage advice from ITIL – as well as other approaches- to accomplish the objectives of an organization.

For example, let’s look at a DevOps approach to change.  Using DevOps, changes are developed in smaller increments, or units of work.  Smaller increments mean less risk, better testing (there’s less to test), and greater capability to respond to changes in demand. In a DevOps approach, code is always kept in a deployable state.  Technology is leveraged to ensure that by automating needed testing – as part of the criteria to check-in any updated code, that updated code must pass testing and is error-free.

Kanban boards are often used by DevOps teams to visualize the work being done, and also represents the change schedule.  The Agile methodology, featuring daily stand-up meetings, helps promote team communications and prevent scope creep regarding changes. Agile also enables teams to be responsive to changes in demand and ensure that the business (in the form of a product owner) is involved in the development of changes.  And all of this will work perfectly fine within the ITIL 4 Change Control practice.

Change Control is a better approach

The ITIL 4 change control practice advises organizations to first consider ‘why’ and ‘what’ needs to be done for introducing changes, before determining the ‘how’. Change control is a better approach for facilitating the introduction of changes, especially in the digital age.