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
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
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.