Why approve a change that was already made

By ITIL® from Experience©

In some organizations it is common for changes to be made without authorization to quickly resolve a high priority incident. This is especially prevalent when the Change Management process is in its infancy (see What are the stages of maturity for the ITIL Change Management Process). Our view is that every change must be approved even if it is approved after it was made (see Are changes approved or authorized).

ITIL®, aside from mentioning that Change Management applies to all changes, does not specifically mention that unauthorized changes should be approved once they have been discovered. However, ITIL® states that Change Advisory Board (CAB) members are also responsible to review unauthorized changes yet, it comes short of saying that this review includes an approval1 (See Should RFCs be logged when an undocumented or unauthorized change is discovered).

Authorizing a change after it was made has value since it allows the Change Management process to confirm that the change was:
a) Technically sound and that,
b) It is the appropriate solution or that it should be replaced with another solution to adequately fix the problem.

In fairness, most undocumented changes are made with good intentions. For example, in the absence of an emergency change process, a change can be made quickly to resolve a Major Incident (see Is a reboot a change) or in response to management's request to address a pressing customer need. Moreover, the IT Specialist can simply forgets to log the RFC to replace the temporary fix they made as they were distracted by another emergency. Of course, some people may not bother with the bureaucracy of change management since the incident has been resolved (see Who should log the RFC).

Lets not forget that getting people to log tickets is frequently a challenge (see How to get people to log tickets). Thus, getting them to log an RFC after the change was made would be another battle to fight especially if they are subject to approval. It is easy for people to argue that it is a waste of time and effort. As the saying goes: it is too late to close the barn doors once the cows left. After all, what is the point since it is a “fait accomplit" especially if the change did not cause any incidents?”

The benefit of logging all RFCs is fewer incidents and potentially avoid being called in the middle of the night or while on vacation to address an issue that previously resolved. Another benefit of logging changes is to communicate that a change was made (e.g. via the change process, CAB minutes/record of decisions). Thus, it enables Configuration Item (CI) owners to adjust their CIs to avoid incidents (e.g. restart dependent services, update mirrored/redundant systems).

More importantly, approving every change even after it was made enables the organization to realize the majority of the benefits of that process. It is also one of the best way to mature the Change Management process since the message is that: “you cannot bypass the process; Whether you get approval before or after making a change.” Of course, management support helps to ensure that this message is taken seriously (see What does it mean to have CIO and management support).

Last updated on: 2017-09-18
Published on: 2017-05-06

"Implementing Change Management is like driving from New Hampshire where you "Live Free or Die" to Missouri, "The Show Me State."

More Quotes


More on Change Management

ITIL Process > Change Management

1. ITIL® Service Transition (2011 Edition), Section CAB Member (p. 229).


Copyright 2017 - ITIL® from Experience© - D.Matte