These are the primary responsibilities of the change manager. Other management steps occur,
but are more technical in nature and classified as project management:
· Monitoring CIs for changes and planning new changes
· Building changes for deployment
· Testing changes and updating contingency plans
· Implementing changes
Although these tasks will often be undertaken by someone other than the change manager,
Figure 7.6 shows that the interaction between change and project management is frequent. The
individuals managing these two activities need to communicate constantly to ensure the proper
flow of the overall change-management process.
Reviewing and Closing Requests for Change
The last step in the change-management process is a post-mortem, or final review of how the
change implementation went and how well the process worked. You should consider a number
of criteria in your post-mortem:
· Are end users satisfied with the results of the change? In the world of network device
management, users being completely unaware of the change constitute satisfaction.
· Were there any unexpected side effects from the change? If so, did they interrupt
operations or require additional changes to correct or mitigate?
· Can the change be left in place? Changes that are rolled back are considered
unsuccessful, because you can assume they will need to be rebuilt, retested, and
redeployed at some future time.
· Were the resources used to implement the change the ones that were planned? Were
additional or fewer resources required? This review point is important for helping the
CAB and EC refine future resource estimates.
· What did you learn from this change that can be applied to future changes, especially
ones that are already in the queue for implementation? This step is the perfect time to
apply "lessons learned" to upcoming scheduled changes and prevent a repeat of any
problems that occurred this time.
A basic report should be made available to the CAB or EC, and in the case of more major
changes, to upper IT management. This report should summarize the original goals of the
change, detail how the implementation occurred, and list any problems along with, if possible,
Listing the reasons for an unsuccessful change shouldn't come down to finger-pointing. Reporting
that "John messed up the BIOS flash" isn't helpful unless you're trying to fire John; reporting that,
"Administrator error caused the wrong BIOS image to be downloaded" is useful information. You
might use that information in future changes to, for example, have a peer verify that the correct BIOS
image has been selected prior to downloading.