Loading...
 

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 quickly to resolve a high priority incident especially when the Change Management process is in its infancy. Our view is that every change must be approved even if it is approved after it was made.

ITIL® 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 and 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, b) the appropriate permanent solution or that this solution should be replaced to resolve 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). A lot of times, the IT Specialist simply forgets to log the RFC to replace the temporary fix 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).

Often it is already a challenge to get people to log tickets without waging an additional battle to get them to log RFCs after the change was done, let alone to subject it to an approval(see How to get people to log tickets). It is recognized that some people are more difficult to convince than others. It is easy for them to see this as 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?”

A key benefit of the Change Management process is to communicate the existence of the change (e.g. via CAB minutes/record of decisions). Thus, it enables Configuration Item (CI) owners to adjust their CIs accordingly to avoid incidents (e.g. restart their dependent services). The benefit to IT specialists 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.

Following the Change Management process even after a change was made enables the organization to realize the majority of the benefits of that process. But more importantly, it is 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)


Published on: 2017-05-06

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

More Quotes



Related:

More on Change Management


Category:
ITIL Process > Change Management


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



Disclaimer


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