Techniques BABOK Guide v3, 10.40
Root Cause Analysis
In short A structured search for the causes underneath a problem, so you fix what produces it rather than what you can see. You end with a short list of verified root causes and a reasoned choice of which ones to tackle.
Based on: IIBA, BABOK® Guide v3, technique 10.40 “Root Cause Analysis”; B. Andersen, Business Process Improvement Toolbox, ch. 8; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 5; D. Leffingwell, D. Widrig, Managing Software Requirements.
On this page
What it is#
A symptom is what people notice (“repairs are late”). A root cause is the condition that, once removed, stops the symptom from coming back. Root cause analysis is one of the techniques in the BABOK® Guide catalog. Bjørn Andersen’s process-improvement toolbox gives a practical treatment built on two tools.
Cause-and-effect diagram (Ishikawa or fishbone diagram). The problem sits at the “head” on the right, cause categories form the “bones”, and specific causes hang off each bone. Andersen describes two ways to build it: dispersion analysis (categories first, then causes in each) and cause enumeration (brainstorm all causes, then group them). Both end in the same picture. For processes, draw a fishbone for each problem step on a process map and analyze them together.
Five Whys (a why-why chain). Ask “Why does this happen?” about a cause, then about each answer, until no new answer comes. Around five rounds is typical, hence the name. Andersen uses it to test whether a cause is truly a root or just another symptom. Swap “Why?” for “How?” and the same chain helps you find solutions.
When a problem has several independent root causes, the result is a network of causes rather than a single chain.
Bone categories. Andersen suggests people, machines, materials, methods, measurement, and environment for physical processes; for service processes, people, processes, surroundings, and work environment. The BCS book offers alternatives: the 4Ms (manpower, machines, measures, methods, with materials sometimes replacing measures) and the 6Ps (people, place, processes, physical evidence, product or service, performance measures). Both sources treat categories as a starting point. Mix them or create project-specific ones.
Choosing what to fix. The BCS authors note that a cause appearing under several categories usually has the widest effect and is a good candidate for early action. Leffingwell and Widrig add an economic filter: estimate how much each cause contributes (a Pareto chart helps) and fix only the causes where removal costs less than the damage they do.
When to use it#
- A problem keeps coming back after quick fixes.
- Stakeholders disagree about why something goes wrong.
- Before you define a solution: you need to know which problem it must remove (see Problem Analysis and Project Scope).
- The BABOK Guide lists it for tasks such as Identify Business Analysis Performance Improvements (3.5), Assess Risks (6.3), Analyze Performance Measures (8.2), and Assess Enterprise Limitations (8.4).
Use something else, or add to it, when:
- the cause is already known and confirmed by data; move on to options;
- many causes influence each other in loops. A linear Five Whys chain then distorts the picture; use a relations diagram (see A Toolkit for Process Improvement) or systems-thinking tools;
- nobody in the room knows the work; observe it or collect data first.
How to do it#
- Form a small group with real knowledge of the work, including people who do it every day.
- State the problem precisely: what happens, where, since when, how often, and how you measure it. Agree on the wording first.
- Draw the head and spine. Write the problem on the right and leave space on the left.
- Choose categories from the sets above or your own.
- Brainstorm causes for each category. Capture now, debate later.
- Ask “Why?” for the most plausible causes until the answers stop or move outside the organization’s control.
- Mark candidate root causes, especially those that appear in several categories.
- Verify with evidence: records, observation, a quick data extract. A root cause you cannot support with facts is still a hypothesis.
- Decide what to fix by weighing each cause’s impact against the cost of removing it.
- Turn chosen causes into objectives or requirements, and agree how you will know the fix worked.
Example#
The Workshop, a fictional chain of bike-repair workshops, hears that repairs often miss the promised completion date. The business analyst runs a one-hour session with two managers, two mechanics, and a front-desk employee.
Fishbone for “Repair not ready on the promised date”:
- People: front desk promises dates without checking the mechanics’ queue.
- Process: parts are ordered only after inspection; ordering is a weekly phone call.
- Materials (parts): common parts are often out of stock.
- Equipment: one truing stand is shared by two mechanics.
- Measurement: nobody tracks promised against actual dates.
- Environment: the spring peak sharply increases bookings.
Parts appear under both Process and Materials, so the group starts there:
| Why? | Answer |
|---|---|
| Why is the bike not ready? | The mechanic waited for a part. |
| Why wait? | The part was not in stock. |
| Why not in stock? | Stock is reordered only in a weekly phone call. |
| Why only weekly? | Nobody sees stock levels until someone counts the shelves. |
| Why no visibility? | Parts used are not recorded against each repair. |
Candidate root cause: parts usage is not recorded, so stock cannot be replenished in time. The analyst checks a month of job cards to confirm it before writing parts-ordering requirements. Dates promised without checking capacity become a second root cause, handled by the booking feature.
Common mistakes#
- Stopping at a symptom (“the part was missing”) → keep asking until the answer is something the organization can change.
- Blaming individuals → ask why the process allows the error to happen.
- A vague problem statement → make it specific and measurable before brainstorming.
- Forcing one chain → allow several branches when causes are independent.
- Skipping verification → test each root cause against data or observation.
- Trying to fix every cause → prioritize by impact and cost.
- Letting the most senior voice decide → a neutral facilitator and silent brainstorming reduce bias.
Template#
Problem statement: <what, where, since when, how often, how measured>
Fishbone
- <Category 1>: <cause>; <cause>
- <Category 2>: <cause>
- <Category 3>: <cause>
Five Whys for: <selected cause>
1. Why? -> <answer>
2. Why? -> <answer>
3. Why? -> <answer>
4. Why? -> <answer>
5. Why? -> <answer>
| Root cause | Evidence | Impact (H/M/L) | Cost to fix (H/M/L) | Decision |
|---|---|---|---|---|
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.40 “Root Cause Analysis”.
- B. Andersen. Business Process Improvement Toolbox. ASQ Quality Press, 1999, ch. 8, sections 8.1–8.2 (cause-and-effect diagram, Five Whys).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010, ch. 5 (fishbone categories).
- D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000 (problem analysis: root causes and Pareto).