change management Archives - Deep Creek Center

Certification training vs tools

A number of our customers are struggling with how to implement training programs to support their service management initiative. Many approach the training need from a tools point-of-view. In other words, train them on using the Change management tools, not on the process itself. While understanding how to effectively leverage and use your tools is critical, understanding the context of the work in supporting your services is the critical link. What are the proper triggers, inputs, and outputs of the process? What are the dependency relationships between your process activities and that of other processes? How does what is happening in your functional group impact other groups?

We recommend at a minimum some core understanding of the Service Lifecycle and the role the different processes play in modeling, planning, transitioning, supporting, and improving services BEFORE the tools training. Otherwise, people will “fill in the boxes” to “get the work done” without the right level of quality or value capture in their documentation. Ultimately you are at risk of reduce quality and service availability without this core understanding.

Integrating ITIL with project management

One of the many issues facing organizations trying to get substantial traction with ITIL initiatives is the incorrect perception that ITIL is “for operations.” I can’t begin to count the number of developers and project managers who have openly asked in one of my Foundations classes “this isn’t for projects, right?” Well, yes, of course it’s for projects, since projects are how we perform most activities in IT; design, development, service improvement projects, new service initiatives, and the list goes on.

In many cases, the ITIL community is firmly responsible for this misconception. Asked to describe their ITIL adoption and good practices, they inevitably point to Service Desks, Incident and Problem Management processes, and occasionally Change Management or a CMS tool implementation (often without an underlying CM process to drive its use or efficacy).

With ITIL v3, we have a chance to fundamentally reset everyone’s expectations of ITIL. We now acknowledge the whole Service Lifecycle, beginning with Strategy. It’s reasonably easy to see the parallels of the activities of Service Strategy and Service Portfolio Management with a PMO; look at business cases, assess ROI and VOI, and approve and charter projects. Likewise, Service Design and Transition provide clear processes and guidance for managing the tactical aspects of capturing functional, nonfunctional, and usability requirements (think utility and warranty), performing service and measurement design, developing or acquiring applications, infrastructure, and metrics management tools, coordinating testing and validation, and overseeing transition planning and execution and operations uptake. These are the fundamental parts of planning and executing any good IT project, and would look very familiar to a PMP. By the way, these models work brilliantly in agile development models as well as more traditional waterfall approaches (which don’t work, but that’s a different post).

The biggest risk we have for successful ITIL adoption is that very often senior IT management really has no idea what ITIL really is. They think in terms of the most basic Service Operation processes, the Service Desk function, or maybe Change Management, but generally have absolutely no idea how ITIL helps to bridge the yawning cultural chasm in many organizations between Development and Operations. When we teach that Management Commitment is a mandatory critical success factor for ITIL implementation, it begins with basic understanding and clarity of vision across the Service Lifecycle.

Changing the way we think about change management

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 post, we’ll 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

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 RFCs. Alignment between the Change Management process and what happens in Service Strategy and Design simplifies this workflow a lot. If we consider Change Management to begin in Strategy, RFCs begin with goals and objectives (e.g. removing a Known Error, implementing a CSI recommendation, etc.). By categorizing the Change, Standard Changes are weeded out and pre-approved, Emergency Changes are quickly driven to an ECAB for assessment, decision, and action, and Normal Changes are assessed by the appropriate 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) where 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.

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 status of 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. Once the Service Design Package is complete, Release and Deployment Management can take the change and its associated documentation into the 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’re good to go (with other remediation as necessary), we can close the Change at this point.

By thinking of Change this way, it’s easier to see how to use groups like PMOs 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.