ITIL Implementation Roadmap (Change Management) – Part 4
To Change is Human and Very IT
“He who rejects change is the architect of decay. The only human institution which rejects progress is the cemetery.” ~Harold Wilson
In IT we are in the business of Change Management but many do not appreciate it as a core discipline for running a mature IT shop. Most organizations will refer to this process as Change Control and focus on the policing and audit elements of stopping un-authorized or un-scheduled changes. This focus on the “CONTROL” part of the process is necessary but unfortunately gives the process a bad rap among most IT staff.
Change Control is often seen as a process which inhibits the freedom and efficiencies of a dynamic and creative IT management organization. The change meetings are perceived to be a frustrating waste of valuable time which should be avoided if at all possible, or at the very least a place to send your delegates if you are lucky enough to have them. At best Change Management is seen as a necessary evil.
This is unfortunate perception for what is in essence such a necessary and integral process for IT Management. While controlling change is a basic requirement, what ITIL describes as Change Management is more holistic then what is typically practiced in most organizations.
Cavet: The following definitions are a practical expansion of ITIL theory based on typical implementation practices. They are not to be used as the basis for ITIL examination or certification responses. 
The implementation of Change Management within an IT organization can often be observed as following a typical pattern of maturity represented by the following definitions:
- Change Notification (Before or After The Fact): Key stakeholders of the IT change find out about what is happening at some point after the change has occurred or if they are fortunate at some point before the change is implemented. This process has no element of control, approval or coordination outside of the group making the change. It is simply focused on the curtsey of informing the interested parties either before or after the change has happened. While Change Notification admittedly seems to be a bit light on process, it is certainly better then not knowing anything at all until the calls come into the Service Desk on Monday morning.
- Change Control: As described above, Change Control is focused on the operative word of “Control”. A process at this stage of maturity is all about coordinating and scheduling “all” the changes in IT regardless of their source on one Forward Schedule of Change. At this point you will typically find that the organization has established a meeting of IT professionals to review and approve the current change schedule. What is important to note here is that the changes themselves are not being conceptually approved. It is the Forward Schedule of Change which is being evaluated. At best the Change Advisory Board which meets on a regular basis can require a change to be rescheduled but not cancelled outright.
- Change Management: While not found in ITIL theory, changes can be perceived has having two points of approval. The first approval is the conceptual approval “Can or should I do this change?” whereas the second approval is based on timing and occurs around the Forward Schedule of Change being reviewed on a weekly basis “Can I promote this change to production?” The process which ITIL describes as Change Management covers both the conceptual approval as well as the approval to promote into production. It is important to realize that they both are necessary but occur at different points in the change lifecycle.
Most organizations implement this process at the level described above as Change Control and struggle to understand how to move the process into an earlier stage to also support the conceptual approval of the change required by Change Management. This challenge often comes from the fact that there are many potential sources for change which each have their own pre-existing conceptual approval model. For Example:
- Project Approval – Approved by the Portfolio Management Process
- Application Enhancements – Approved by the App Dev. Methodology
- Infrastructure Changes – Approved by the IT Domain Head
- Service Requests – Approved by the Cost Center Owner
- The Move, Add, Change Process (M.A.C) – Pre-Approved
In principle, it would be good to have a Change Management Board conceptually approve many IT changes as a collective group (for example: We need to re-boot the server). However, this is not necessarily practical for all changes.
Perhaps one way to understand this is that all of the example approval mechanisms listed above are part of a greater Change Management Process. The key factor is that each change is conceptually approved by a formal process and that all changes have to be coordinated and approved together (regardless of source) for promotion into production.
Troy’s thoughts what are yours.
Other Blog Posts on Change Management:
Change Management from Havoc to Control
Change Management and Air Traffic Control
-
Great post indeed. ITIL Change Management is the pivotal force that interlinks other interactive ITIL processes.For a basic overview of ITIL Change Management,one may refer to the blog http://itilchangemanagement.blogspot.com/
Posted by Amit B on 10/07 at 11:15 PM