Why approve a change that was already made

By ITIL® from Experience©

In some organizations changes are made without authorization to quickly resolve a Major incident or under pressure from management. 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. Even though, ITIL® states that Change Advisory Board (CAB) members are also responsible for reviewing unauthorized changes 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) The appropriate solution or that it should be replaced to adequately fix the problem.

In fairness, most undocumented changes are made with good intentions. For example, as mentioned in the absence of an emergency change process, a change can be made quickly to resolve a Major Incident (see Is a server reboot a change) or in response to management's request to address a pressing customer need. Moreover, the IT Specialist can simply forget 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 logging a change 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 is another battle many may not want 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 door after the horse has bolted.2

A 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 the Change Management 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. Either you get approval before making a change -or- you will have more work after since you will need to justify it.”

Of course, management support helps to ensure that this message is taken seriously (see What does it mean to have CIO and management support).'

That being said the question that comes next is: Should unauthorized changes have their own process

Last updated on: 2017-10-03
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

Related: