When to approve changes for production

IT service change management is the process for managing changes that affect IT services. Many people starting change management do so for audit–to control production–and changes are submitted when they are ready for production.

However, ITIL’s guidance is for change management to start much earlier: for changes to be approved before they are built.

Below I’ll compare and contrast the two approaches, and recommend that you eventually approve changes before they’re built.

Triggering change management right before production

Text "Trigger: Ready to apply to production" with steps Submit RFC, Review/Approve/Schedule/Etc, Apply to Prod
The change management process is triggered when the work has been built and tested and is ready to go into production. Then a request for change (RFC) is submitted, reviewed/approved, scheduled, and then put into production. With this approach, by definition the change management process is holding up the change but it is certain exactly what is changing. (Note: this diagram is not intended to define a complete change management process; for example there is no change verification.)

The change is ready for production, so the developer/administrator/technical person submits a change. The change then goes for review and eventually is approved.

In this approach, by definition the process will be holding up the change.

This often leads to people blaming the change management process: “it would have been done sooner, except that I had to get the change approved.”

This approach is often the initial version of change management. Two strong benefits of this approach are…

  • It is extremely clear exactly what is going to change (because all work has been done)
  • It is easier for people to understand this approach: I must submit a change right before I touch production, and I should only touch production if I have an approved change

Triggering change management before building the change

Text "Trigger: pretty sure we want to work on this" followed by several steps: Submit RFC, Review/Approve, Build & Test Change, Schedule, and Apply to Prod
The change management process is triggered when someone is “pretty sure” they want to do work. The definition of “pretty sure” may vary wildly from organization to organization. A request for change (RFC) is created, reviewed and approved, and then the change can be built and tested. Then when ready the change can be scheduled to ensure there are no conflicts, and then it’s applied to production. With this approach there is less certainty about what exactly is changing at the review/approve step. (Note: this diagram is not intended to define a complete change management process; for example there is no change verification.)

Someone is “pretty sure” they want something changed. A change request is submitted for the change, maybe by an end user or maybe by IT staff. The change is then reviewed and approved for work.

The review is a “business level” review because the technical details are not known. The approval is more about the benefit and general estimated costs, thinking about the Seven R’s of ITIL change management.

Once the change is then built and tested, the change is then scheduled. (This is not an approval; instead, it’s a coordination/release effort working on the Forward Schedule of Change/change calendar.)

There must be a “scope change” process for the change, if the technical work becomes much more involved than expected or if significant risks are uncovered. It is also harder to know exactly what is in scope: if an RFC is approved to “throttle the web site” does that mean put in caching or switching web servers or something else?

Benefits to this approach are…

  • People do not spend time building changes that have not yet been approved, so changes can be cancelled/adjusted more easily
  • Approval to some extent can happen concurrently with work–it may be OK to start building the change, or you may have a backlog of work to tackle while you’re waiting for the next change to be approved

Which one to choose

If you do not have any change management, I’ve found the first approach (“right before production”) is a necessary step as you move towards the second approach (“before building the change.”)

People need to understand that production only changes when a change is approved, and the feedback loop is very tight for the first approach: next time submit the change before touching production. In the second version, people may say “well it was sort of in scope for this other change.”

When you can though, the second version–approving changes before they’re built–is definitely the better state. The process will start to provide visibility to enhancement/corrective work that might not otherwise be tracked, and it prepares you to offload smaller projects as big changes.