If there is a "burning question" as an organization drives its ITIL® process implementation through the planning stages, it is "… which comes first – Change or Configuration Management?" And, as if that were not enough of a challenge, it is followed by, "Can you do one without the other?" and, close on its heels, "If you do one without the other will you achieve any meaningful level of success?"
It is enough to boggle the mind of any ITSM practitioner, let alone industry experts and pundits ... literally a "chicken or the egg?" question.
To address these questions, it becomes essential to place both the Change and Configuration Management processes within the overall scheme of a Continuous Service Improvement program. This action establishes the context for why an IT organization would undertake such an effort.
Normally we see IT organizations approach a Continuous Service Improvement program with the desire to, first, stabilize their efforts to support and restore services, usually by deploying a Service Desk and the Incident and Problem Management processes. Once an IT organization has stabilized its services, it then recognizes the need to extend its stabilization efforts by exerting control over the IT infrastructure. This leads to the implementation of the release and control processes (Change, Configuration & Release Management).
Change Management and Configuration Management share close links to each other. They are integral in helping high-performing IT organizations achieve the stability that is necessary before they can go on to reap the benefits of other processes, such as Service Level Management, Availability Management, Capacity Management, IT Service Continuity Management and Financial Management.
Change Management relies heavily on Configuration Management in four primary areas – assessing the scope of a Change, maintaining baseline configurations to support backing out a change if necessary, maintaining information about the Requests for Change (RFCs) in progress, and, of course, logging the actual changes made to the infrastructure.
Having a mature Configuration Management process enables the Change Management process to achieve higher levels of capability. Yet, if disciplined Change Management policies and procedures are not in place, the organization's configuration faces the risks associated with uncontrolled change.
How can you have it both ways? How can you implement Change Management if Configuration Management is not in place? And, how can you implement Configuration Management if Change Management is not in place?
The reality of the situation is that bringing Configuration Management into an organization is a mediumterm project, taking a year or more before an organization can completely implement all of the Configuration Management activities. These include:
Recognizing the challenge of bringing an entire infrastructure under the control of Configuration Management, many companies elect to phase in Configuration Management over time. You can do this through several means:
Change Management, on the other hand, is difficult to implement in a piecemeal basis. Although you can implement Configuration Management in phases, generally the entire organization has to work under the same Change Management processes in order to avoid entropy and chaos.
That said, you can implement Change Management in conjunction with Configuration Management if you consider how you will fill in the voids that would be provided by a mature Configuration Management process. For example:
Obviously, there is a cost to building your Change and Configuration Management processes this way. The costs are primarily in the extra effort that needs to go into each Request for Change to scope its impact, build the back-out plan, manage the RFC queue, and make isolated (dare we say, manual?) changes in the Configuration Management Database (CMDB).
However, if you recognize the parameters within which you are working, you have the opportunity to accelerate the benefits of bringing your infrastructure under the control of a formal Change Management process. You do not need to wait for Configuration Management in order to begin to do Change, and the ability to selectively implement parts of Configuration Management within the context of a Change gives you a leg up your implementation of Configuration Management as well.
Any IT organization implementing either process needs to take a long hard look at what it wants to achieve, where it currently sits in both organizational maturity and process capability, and what it needs to achieve to support the enterprise. Okay, then, what is the right answer? It is probably "yes." But "it depends" is probably closer to the truth. We'll have to ask the chicken; or the egg.