Root Cause - What is it?

In spring 2010, a team was created within the Division of IT and given the following charge:

Meet regularly to review key defects IT has dealt with during the previous weeks, identify the root cause of the top key defects and determine what actions should be taken to prevent future occurrences.

What was the overall goal? Become PROACTIVE in addressing the top defects in an effort to reduce the overall number of incidents.

So what is root cause analysis? It is the fundamental breakdown or failure of a process which, when identified, resolved and corrected via a tested work-around or overall solution, prevents the recurrence of the problem. In some cases this can be quite a challenge as all problems can tell a story. You just have to be patient and keep asking the following questions until you find the “rest of the story”:

  1. What is the problem?
  2. Why did it happen? (Keep asking this question until you find the failure in the process.)
  3. What will be done to resolve the main cause?

Whether we realize it or not, we use root cause analysis in our daily lives. For example, you leave for work and notice an oil stain underneath your vehicle. The oil was changed yesterday so you figure it is the little bit of oil spilled on the engine when the filter was changed. You back up the vehicle clean up the oil stain and proceed to work. The next day you notice the stain again, but now it is bigger … time to take a closer look into the problem. Upon further investigation you determine the technician did not tighten down the oil filter. Now you have identified the root cause and proceed to take appropriate steps by addressing the cause instead of “applying a band-aid” (cleaning up the stain). If you had continued to ignore the problem the outcome would have been catastrophic.

The IT Root Cause Team has been in existence for almost a year. Have they been successful in their attempt to identify key defects? Yes, but it was a challenge.  Why?  Well, to identify key defects every unit logging incidents within the service desk software should follow the same process.  This was not taking place as…..there wasn’t an official ITSM process for Incidents!  The first key defect found and addressed by the Root Cause committee.

The Root Cause team continued to meet on a monthly basis by bringing information to the group the best way possible while the ITSM Process – Incident Project team was created.  This project team met on a weekly basis and developed the approved Incident Process implemented on January 1, 2011.

The process has increased accountability, productivity, communication and effectiveness within IT.  The process also included metrics to gauge service productivity, effectiveness, timeliness and customer service.  So how are we doing?  All in all the goals set for most of the metrics have been at the level set or below.  However, there are a few metric findings that are exceeding the allowable percentage set in the process.  Funny thing about metrics…you have to find out the root cause of issues that cause you not to meet your goals!

Another result is not all root cause findings and resolutions are high profile changes or technical in nature. Findings and resolution can be in the form of new or additional staff training, increase or modification in communication within IT and with clients, or in the creation of new or modified processes and policies.

In conclusion, root cause analysis is performed after the defect is discovered and is reactive in nature. However, root cause analysis produces information that can lead to anticipating future needs and events, which results in being PROACTIVE!


Experience level: 
Leadership and Management

Schedule info

Time slot: 
2 November 08:30 - 09:15
Breakout Room - D