One of the more challenging problems with deploying ITIL processes is our desire to make workflows linear. We teach the lifecycle one domain at a time, and teach processes in association with the book in which they are described. Reality is seldom so tidy, however.
Processes like Change Management, Service Asset and Configuration Management, and Knowledge Management have a much broader scope; they span the entire service lifecycle and can become confusing if we try to limit them to a particular lifecycle domain.
In this DITY, we will discuss the reasons why Change Management needs to be "liberated" from Transition, and how this simple idea will improve your organization's ability to manage change.
Considering Change begins with Service Strategy
Service Strategy describes the notion of managing a Service Portfolio. Our Resources and Capabilities define a set of Service Assets to be invested, with the goal of maximizing returns for our customer (Value Creation) and for the Service Provider (Value Capture).
While many of these resources are invested in ongoing Operations activities (somewhere between 60-70%, depending on whose data you see), much of the remainder is invested in new or changed services in our Service Pipeline.
The job of Service Portfolio Management is to define the Portfolio, analyze Business Cases for new or changed services, approve a new future state (in other words, choose the business cases we're going to commit to doing), and charter the new portfolio (which has the effect of establishing projects to proceed to design and build the new or changed service in the business case).
While some Business Cases are requests for entirely new services, most come from different Requests for Change (RFC). Alignment between the Change Management process and what happens in Service Strategy and Service Design simplifies this workflow a lot.
If we consider Change Management to begin in Strategy, Requests for Change (RFC) begin with goals and objectives; e.g. removing a Known Error, implementing a Continual Service Improvement (CSI) recommendation, etc.
By categorizing the Change, Standard Changes are weeded out and pre-approved, Emergency Changes are quickly driven to an Emergency Change Advisory Board (ECAB) for assessment, decision, and action, and Normal Changes are assessed by the appropriate Change Advisory Board (CAB) for cost, risk, impact, and business value.
Given the scope of the Change request, some change requests can be handled at lower levels of the organization (though still through formal Change Management), and larger scope and resource-impacting changes should have Business Cases developed and these considered together as part of the overall Service Portfolio Management process.
As a result, we have consistency in our Change Decision Authority, resource alignment and allocation across projects, and a consistent means of prioritizing the work to be done.
Designing the Change comes from Service Design
Once an RFC is approved, Service Design describes how we build the change, with the Change Management process continuing to coordinate multiple changes and working with other processes to prepare for effective Transition. This could include planning testing and validation windows, scheduling access to build and test environments, planning how changes will be packaged for release and deployment, and verifying business fit.
"Coordinating Change" then largely is described by monitoring the status of the change build, ensuring proper Service Transition and Operational Readiness Plans are in place, and ensuring that communications is maintained among the various technical, process, and business stakeholders.
Executing the Service Design Package Lies with Service Transition
Once the Service Design Package is complete, Release and Deployment Management can take the change and its associated documentation into the Definitive Media Library (DML) and coordinate appropriate packaging, build, test, and deployment/installation of the change according to our transition plan.
Once deployed, Change Management finishes its workflow as always with a Post-Implementation Review confirming technical success and business outcome (based on the Evaluation Report's assessment of Change Acceptance, Predicted, vs. Actual Performance, and "unexpected side effects"). Assuming we are good to go (with other remediation as necessary), we can close the Change at this point.
By thinking of Change this way, it is easier to see how to use groups like Project Management Offices (PMO) to help adjudicate how projects align to new and changed services, portfolio management goals, and how to align Change authorities more sensibly. Most importantly, it improves our likelihood of delivering well designed, planned, and effective changes more quickly, improving our ability to adapt IT services to meet our customers' changing needs.