University ITSM

The "change management lifecycle" is the high-level activities followed in the change management process. It seems like, in practice, there are two definitions for a change's lifecycle: either just the hand-off to production, or the entire gamut from idea through implementation or closure. We here at Wake Forest University are transitioning from the former to the latter, as we refine our change management procedure.

At Wake Forest University, our initial change management lifecycle was intentionally limited--rather than defining a "change" as the entire process from the idea for a change until its closing, we defined a "change" as a change to production that has been built and tested already. This approach worked very well for us, because it was easy for people to understand the scope of change management and to understand what was being approved. Essentially, the lifecycle was

• Create RFC (according to a change that has already been built and tested)
• Approve and schedule RFC
• Implement the change
• Conduct post-implementation review
• Close the change

ITIL, however, recommends that the change lifecycle should be very broad--change management should begin when someone has an idea. Also, ITIL recommends that changes be approved before they are built, so it's more reasonable to say "no." No one wants to reject a change that has already been built and tested! Moving the change approval to occur before the change is built helps transition change management from a very technical review to more of a "business impact" preview of potential changes.

The disadvantages to approving changes before they are built are that the change lifecycle is more complex and therefore more prone to error, and testing is even more important, because the tested change needs to match what was already approved. The upside is better visibility into approved work and a more meaningful approval process. That's what we're working on now--restructuring change management to follow a longer lifecycle:

• Create RFC
• Filter/Review RFC
• Classify RFC
• Approve (and prioritize?) RFC
• Build the change
• Test the change
• Schedule/communicate the change
• Implement the change
• Verify the change

At the same time, we are also introducing the concept of "change models." Before, we had five types of changes:

1. Maintenance work
2. Service provisioning work
3. Pre-approved changes (must have an explicit procedure for how to enact the change)
4. Regular changes
5. Emergency changes

This mechanism has been useful, because we have a way to handle all our work, but we are now developing a more nuanced approach that will allow us to handle "defects" differently than larger new projects.