ITSM Implementation Tip Series: #1 : Ok We’re Making Good Progress on Incident Problem and Change, What Next?

For most organizations the first ITSM processes they tackle are the classic Incident, Problem and Change Management (IPC) processes. Before I discuss what to do next let’s make sure we’re all on the same page on progress to date.

Holistic enterprise frameworks such as ITIL which provide guidance on ITSM depend heavily on the concept of process integration to realize the full value and business benefits from a service management approach. Process integration is reached when more than one mature process shares inputs, tasks, outputs and data with another mature process. In the ITSM business there are various maturity rating schemes, typically based on the Software Engineering Institute’s (SEI) original Capability Maturity Model  (CMM) and have been adapted using specific maturity characteristics for each ITIL process.  More recently, SEI ‘s own adaptation CMMI is also being used. 

 The maturity scale uses a five point rating system, with one being the least mature and five being the most. Integration is achieved at level four when multiple mature level three processes are connected.  A mature level three process will be clearly defined and documented so that it is considered to be consistent. It will be repeatable in its delivery by all participants and all departments in scope will participate collaboratively in its end to end delivery.  The key though, is that it is providing data to the benefit of other processes.

If IPC are operating effectively an organization can mine mature Incident Management data to identify trends with CI’s and services that require root cause analysis by Problem Management. Once identified, CI’s with known errors will result in Requests for Change to permanently remove the errors.  When these three processes are integrated and operating effectively they are sharing data for the greater good and creating a foundation for further improvements.

The reason incident, problem and change are frequently done first is that there are considerable historical data and lessons learned on how to get them in quickly.  Many organizations understand that implementing IPC is the classic ITSM foundation but lose track of why and how. This leads to a situation where it is difficult know where to go next.

The common trap in the quest for process integration is when two processes blur the lines between their activities and it is not clear which process is doing what. Historically this has been seen as the blurring of Incident and Problem Management activities.  Assuming IPC are integrated correctly, this brings us to the next phase of our ITSM program focusing on Change and Release Management.

Of all the processes that get in each other’s way, Change and Release seem to be particularly prone to this phenomenon. A common indicator that this is happening is when an organization describes RFC’s as being “implemented” by Change Management. In fact Release Management implements and Change Management co-ordinates, controls, authorizes and rejects. Another characteristic of Change and Release stepping on each other is when Project Management views Change Management as “a plot to make projects late and over budget”.  In order to get the best out of blurred processes such as Change and Release Management, we must surgically separate the activities of each process and reattach them at the correct integration points.  To do this we must be clear on what each process does and why.

Change Management is the key ingredient of Enterprise Risk Management while releases are the single greatest de-stabilizers of the infrastructure. The business requires the agility and speed–to-market of a mature Release process but also the due diligence of Change Management to minimize risk. Project Management needs to understand the interplay between the two processes because it will be the driver.

This “holistic integrated approach” provides considerable value to the business. For Change Management you get reduced errors in new or changed services and faster, more accurate implementation of change. It also allows restricted funds and resources to be focused on those changes to achieve greatest benefit to the business

In the case of Release Management, effective release and deployment brings significant business value by delivering changes at optimized speed, risk and cost, and offering a consistent, appropriate and auditable implementation of usable and useful business services.

Implementing an RFC is actually implementing a “Release Unit” or “Release Package”. Release Management participants are the “Drivers” while Change Management is the “Traffic Cop”.  Prior to implementing Releases via Change Management we want make sure all the due diligence has been completed. This will be a list of the activities in the build/test phase where Release Management was to have done some work to make sure their Release is ready. The list will be documented as a Work Instruction in the process documentation. Change Management will want the implementer (Release Management) to sign off on the checklist that they have done their end of the due diligence to ensure a smooth implementation. Project Management can control how and when this is done by who and when. In this case the paradigm has been flipped on its head and instead of change management seen as something “done to” project management, the PM’s are driving the bus. They can minimize risk and ensure they are on-time and on-budget by using Release and Change Management as an integrated set of tools.

Remember that process integration is the target state and where the majority of the payback and business value of ITSM comes from. In order to integrate tasks and data it is common to surgically separate and reattach processes such as has been described here. When choosing your next phase look for those processes which have become entangled. Typically, getting Change, Release and Project Management working as I’ve described will be the focus of your next phase after Incident Problem and Change. 

Comments

[יד שניה]

Nice post really , Thanks for sharing.