Improving Problem Management – Consider Formalizing an RCA Sub-Process

In a previous post we offered some practical solutions for getting started with Problem Management. It was suggested that it was of value to simply organize your Problem candidates in a central location and to keep track of their pursuit and that this didn’t necessarily require any fancy software.

This is certainly true, but as your Problem Management practice gains traction you may want to consider becoming a bit more formal in your approach. One way to do this is to define a ‘Root Cause Analysis’ (RCA) sub-process. This will ensure that all Problems are approached using a similar methodology. This methodology can then, if you choose, be defined as a sub-process workflow in your ITSM tool set.

Way back in the 1950’s Dr. Charles Kepner and Dr. Benjamin Tregoe conducted research on decision making at the Strategic Air Command. They discovered that successful decision making by US Air Force officers had less to do with rank or career path than with the logical processes the officer used to gather, organize, and analyze information before taking action. Their resulting book The Rational Manager (1965) is a business classic well worth reading.

Defining a standard RCA approach leverages this insight and applies it to your Problem Management process.

Step1: Problem Definition
Clearly define the Problem, paying close attention to the ‘boundary.’ Two questions can help –
‘What IS the Problem?’
‘What IS NOT the Problem?’

This may sound simple, but don’t underestimate the value of a disciplined approach to defining the Problem and the boundary of your definition.

It can be quite valuable to clearly understand what is working correctly and what is NOT working correctly as part of your investigations for identifying the root cause.

In framing this step be sure to include relevant stakeholders and ask ‘open’ questions that people cannot answer with a simple ‘yes’ or ‘no’.

For example:
• What do you see happening?
• What are the specific symptoms?

Step2: Collect Data about the Problem
You want to collect as much relevant data about the Problem as you can.

You may also need to obtain evidence that you have an underlying Problem and not just a perception.

Example questions for this stage:
• What proof is there that the Problem actually exists? Reports, Logs, anecdotes (they count), etc.
• How long has the Problem existed? What is the timeline of the Problem and its symptoms?

• What is the impact of the Problem? (e.g., Number of people affected, loss of revenue, effect on brand etc.)
• What’s the urgency to resolve the Problem? (Is it getting worse?)

Be sure to analyze the situation completely before examining the factors that contributed to the Problem.

It will help if you include as many stakeholder representatives as possible. The data collection and analysis will benefit from a variety of points of view, including your clients as well as the ‘experts’ and front line staff. Folks who are most familiar with the Problem can often help lead you to a better understanding of the underlying issues.

Remember, in all these phases, to document your findings. They are inputs to the next Step…

Step3: Identify Possible Causal Factors
Be sure to be exhaustive here. It can be a mistake to identify a few possible causes and then rush off to the next step.

If the issue is urgent, you can certainly work in parallel – pursuing possible solutions while you continue to consider investigating possible causes of the Problem.

The point is that you want to consider all possibilities. Make use of the team you have assembled to look deeply at the issue and identify as many causal factors as possible. Too often, people identify one or two factors and then stop. But that’s not sufficient.

Consider deeper causes and try to be sure that you have arrived at the underlying Root Cause of the Problem rather than just surface symptoms.

Some tools and techniques that help with this step include:

• 5 Whys – Ask “Why?” until you have dug down as far as you can. Use the facts and keep asking “So what?” to determine all the possible consequences of a fact.
• Fault Tree Analysis – Drill Down to break a Problem down into small, detailed parts. Paradoxically this will help to better understand the big picture.
• Ishikawa or Fishbone (Cause and Effect Diagrams) – Create a chart of all of the possible causal factors, to see where the trouble may have begun.

Step4: Identify Root Cause
Use the Information and Analysis to identify underlying Root Cause. As a practical matter this step is closely aligned with the third step. The same tools can be used to try to determine the underlying causes of the Problem.

Again the caution – be sure not to skip too far ahead. Be sure to examine each possible identified factor if you want to be confident in the completeness of your Root Cause analysis.

Look for the root cause of each factor and how it contributes to the Problem.

• Why is the Causal Factor present, why is it happening, when is it happening?
• Ultimately – why is the Problem occurring? Remember, there may be more than one contributing factor.

Step5: Recommend and Design Solutions

Another caution – Since there may be more than one contributing factor, there may need to be more than one solution pursued to completely address the underlying Problem.

For each proposed solution you should be sure to consider the possible effects –
• What can be done to prevent recurrence of the Problem?
• How will the solution be implemented? What are the risks? What other systems or components could be affected by the solution?
Try to anticipate the possible effects of the solution, particularly for complex Problems. Predict the positive and negative effects of the solution.

Step 6: Implement and Review Solutions

It is likely that you will have to engage with Change Management to implement some solutions.

Others may be addressed with workarounds. Some may require ‘acceptance’ meaning that the cost is too great to pursue correction and the Problem will be ‘lived with.’

After each solution has been implemented the Problem team should review the results. Be alert for unanticipated effects on related systems and components.

For some Problems the RCA process itself should be a part of the review. What parts of the process worked well, were the right stakeholders included in the Problem definition phase, was the solution analyzed correctly – these are some of the questions that can inform a review of the process.

This has been a bit longer than our normal post, but Root Cause Analysis is an important topic. If you have taken our advice and begun a simple centralized approach to Problem Management, formalizing the Root Cause sub-process is a great next step to take to increase the effectiveness of your Problem Management process.

If you would like to get started applying these concepts in your organization – you can contact us at or call us at +1.888.718.1708 and let us know you would like to discuss Problem Management or anything about ITSM and ServiceNow implementation services.