Brian Newcomb

Thursday, May 02, 2013

What is your ROI for RCA? (A Key Problem Management Metric)

The activities of Problem Management are, on the surface, quite similar to those of Incident Management, but the focus of these processes is very different.  Because of this, the type of measurements used to determine the efficiency and effectiveness of these processes are also different.  Most organizations place a significant focus on time-based measures for Incident Management.  This makes sense since the purpose of the process is, by definition, to restore normal service as quickly as possible.

On the other hand, Problem Management doesn’t have a similar speed statement, so what type of measure is a good representation of the health of your Problem Management process?  Ultimately, the prevention or elimination of re-occurring Incidents is a good indicator and represents savings realized by decreased load on support/operational resources.  But consider the investment made in Problem Management.  A root cause analysis (RCA), which incorporates significant effort by subject matter experts within the organization, can easily add up.

What measure can be made to ensure the use of these valuable staff time is not wasted and a positive return on investment (ROI) is realized?  Based on the assumption that a good RCA will result in an accurate root cause and change request to eliminate Incidents, I like to measure the ‘trial and error’ factor.

Scenario:
For each problem that has a RCA activity and resulting request for change (RFC), we are looking to determine if the change request that resulted from the RCA eliminated the error on the first try, thereby demonstrating that the investment in the RCA activity saved future repeated attempts to understand the error and ‘try’ a new potential resolution.


Ingredients:
1 Problem Management process with RCA activity and ability to track RFC’s against the Problem that Initiated the Change Request.
1 Change Management process with feedback to (and ideally, participation of) Problem Management via post implementation review (PIR)
1 Incident Management process capable of detecting Incident Trends and linking Incidents to a Problem


Directions:
Step 1: Upon closure of the Problem Record with a status of being permanently solved, the number of RFC’s linked to the Problem is counted.

Step 2: For a given period of time, look at all Problems that have been closed with a ‘resolved’ status and calculate what percent had a count of related RFC’s equal to 1 as shown below.  Let’s call it ‘Percentage of Problems with successful RCA.’  If we are to move away from ‘trial and error’ we should aim for a high percentage.

Monday, April 15, 2013

Project Management and ITIL:  Why can’t we all just get along?

 

One of the most common questions I get when teaching the ITIL Foundation course is around how Project Management relates to ITIL.  This question either comes from those currently leading project management or by those feeling the rigor around their organization’s project management practice and wondering how they can leverage some of the best practices from ITIL without ‘upsetting the peace’.  In fact, ITIL recognizes project management as a valuable and important part of IT Service Management and the Service Lifecycle.

 

Project management, as defined by the Project Management Body of Knowledge (PMBOK) is a temporary endeavor undertaken to create a product, service, or result.  There is a key idea in this definition that a project is temporary and finite – something used to get from point A to point B and then its done.  In a service based IT organization, the majority of projects (if not all) will do one of 3 things:  produce a new service, retire a service, or improve a current service (including any aspect of the service).  The key is to realize this and look at the ITIL Service Lifecycle to see what is happening.  Through the course of the project, many of the ITIL processes are being executed.  The strongest focus is generally in those processes from the Service Strategy, Service Design, and Service Transition phases.  The challenge now is mindset.

 

In project centric organizations, planning, funding, reporting, and ultimate value to the business is based on the projects being initiated and delivered.  Therefore, project management takes the spotlight and all other activities are subservient.  In many cases, little is considered in terms of long term support of the ongoing ‘service’ that lives on after the project has completed – at least not until closer to launch, if ever.  In a service centric organization, IT provides value by delivering services to the business that facilitates outcomes the business want to achieve.  IT does this by making strategic decisions, based on business input, around what Services need to be offered, how they will create value, what exactly they need to do and how they will be designed.  They manage the build and transition so as to minimize risk and disruption to the business, support it in operation and continually make improvements to ensure it always has high value.

 

Understanding the role of project management within ITIL requires a paradigm shift around the role of project management.  Organizations must think about moving through the Service Lifecycle and understand all of the processes working to take the business need through to a valuable, operational service.  To effectively accomplish this, project management is used manage resources, tasks, risks, milestones, and ensure all the activities defined in the lifecycle processes are completed as defined.  To transition to this level of realization however, the organization must be able to move past the thought that ‘those activities are part of project management’.  This can be difficult because in most cases, project management existed in the organization first.

 

Out of necessity, and for lack of any other guidance, many IT organizations adopted project management before ITIL existed or gained mainstream recognition.  Now that there is best practice more specific to guide IT organizations in managing Services, we must thank project management for its years of contribution and transition it to its new role in the organization.

 

Once we move beyond the ‘we where here first’ mindset, we can leverage project management in ensuring compliance with and moving us through the lifecycle processes.  The project plan can be built to include checkpoints and tasks tied to various processes.  For example, at the onset of the project, the plan may look to ensure a Request For Change (RFC) has been entered in to the Change Management process.  Before build tasks begin, project management can ensure that the RFC has been authorized (by Change Management) for build.  The project plan may also ensure that, in the design and requirements phase, the Service Level Management process is engaged to discuss Service Level Requirements or Event Management is involved to begin identifying and designing the appropriate monitoring.  At this point, the organization is using project management as their greatest partner and driving the full value of their defined IT Service Management processes.  So just like that sign that hung in my room as a kid, “A place for everything and everything in its place.”