The purpose of root-cause analysis is to determine the underlying source of a problem under study. Doing this will help ensure the requirements attack the real problem and not just the symptoms.
A critical element is to challenge the current business thinking and processes. You want to overcome the “we’ve always done it that way” answer to the question “Why do you do this?”. I recently managed a project where it took interviews with dozens of people to finally get the answer to the question of why the pay week started on a Saturday instead of Sunday where the sales week started.
The steps to root cause analysis are:
- Define the problem under study and understand the impact
- Analyze the problem to determine the root cause
- Agree on solutions to prevent the problem from occurring
One technique to analyze the root cause is the “five whys” to explore the nature and true cause of a problem. This means repeatedly asking “why” after a question is answered until you uncover the real root cause. It may be more or fewer than five, but five is a good rule of thumb.
You can create a visual of your “five whys” analysis using a “Cause Map”. A Cause Map is simply a block on the left that identifies the problem, an arrow labeled “why” going left to right to another block that answers the question, then an arrow labeled “why” going left to right to the next answer and so on until the root cause is identified.
Root Cause Analysis is a good addition to your requirements analysis repertoire. If your project is not addressing the true root causes of the problem definition then you are unlikely to achieve the defined business objectives.
A reminder that my Kindle book “Project Management For The Real World” is available at