Gap Analysis vs Root Cause Analysis: When to Use Each (CBAP)

Gap analysis vs root cause analysis comes down to two different questions. Gap analysis asks "How far are we from where we need to be?" and compares a current state with a future state. Root cause analysis (RCA) asks "Why does the current state look like this?" and traces a known problem back to its origin. In BABOK v3, gap analysis is part of task 6.4; RCA is technique 10.40. Use both, in a fixed order.

Last verified: October 2026 (BABOK Guide v3 on IIBA KnowledgeHub; McKinsey articles dated 2019).

Gap analysis vs root cause analysis at a glance

Gap analysis measures distance to a target; root cause analysis explains a deviation from an expectation. The table shows the difference on the dimensions that matter in practice and on the exam.

What gap analysis is

Gap analysis is the structured comparison of a current state with a desired future state, which produces a list of changes needed to close the difference. Our earlier note on gap analysis covers the basics; this section places it in the BABOK structure.

In BABOK v3 there is no separate "gap analysis" technique in chapter 10. The IIBA task card for Define Change Strategy says the task performs a gap analysis between current and future state and then assesses options for change. In BABOK v2 the same idea lived in a task called Assess Capability Gaps; version 3 folded it into the change strategy, as Adaptive US explains.

That placement tells you three things:

1. Gap analysis comes late in Strategy Analysis. It needs the outputs of 6.1 Analyze Current State and 6.2 Define Future State. If either is vague, the gap is vague. Our Strategy Analysis overview walks through all four tasks.
2. Gap analysis is a means, not an end. Its output becomes the solution scope, transition states and the business case.
3. Gap analysis is comparative. It does not ask why the current state exists. It accepts the current state as a fact and measures it against the target.

Practitioners say the hardest part is not the comparison but an honest current state. Giorgos Sioutzos writes in BA Times that different departments may hold a different image of the current state. A gap list built on one department's view is a political document, not an analysis.

A McKinsey lens for the gap: 7-S

A gap list is only as complete as the dimensions you check. McKinsey's 7-S framework (strategy, structure, systems, shared values, style, staff, skills) is a useful checklist here. In its Enduring Ideas article, McKinsey notes that the lack of hierarchy among these factors means progress in one area is hard without the others.

For a business analyst this has a direct consequence. A gap analysis that lists only system gaps ("we need a new CRM") will miss the skills, structure and incentive gaps that decide whether the new system is used. Running each of the seven dimensions through the current-versus-future comparison is a cheap way to avoid this.

What root cause analysis is

Root cause analysis is a systematic examination of a problem that looks for its origin instead of treating its effects. BABOK v3 technique 10.40 describes the origin as "the proper point of correction" (IIBA, 10.40). Its two named elements are the fishbone diagram and the Five Whys. Our earlier post on root cause analysis and the 5 Whys shows a short worked example.

RCA needs a clearly stated problem, not a target. That is the main structural difference from gap analysis. You can do RCA on a failed release with no future state in sight; you cannot do a gap analysis without a future state.

IIBA task cards list RCA as a frequently used technique in Assess Risks (6.3), Assess Solution Limitations (8.3) and Assess Enterprise Limitations (8.4). It also supports current-state work in 6.1, where the business need is often first stated as a symptom. See the BABOK techniques map for every task that uses it.

The Ishikawa (fishbone) diagram

The Ishikawa diagram, also called the fishbone or cause-and-effect diagram, sorts possible causes of one effect into categories so that a team does not fix on the loudest explanation. It is named after Kaoru Ishikawa and is one of the seven basic quality tools, according to the American Society for Quality (ASQ).

How to build one, following the ASQ procedure:

1. Agree on the effect and write it at the head of the fish, for example "38% of carts abandoned at the delivery step".
2. Draw the main bones as categories. Ishikawa's generic set is the 6 Ms: Materials, Machinery, Methods, Measurement, Manpower and Mother Nature (environment); Money is a common seventh.
3. For each bone, ask "Why does this happen?" and add causes as branches.
4. Keep asking why on each cause to add sub-branches. This is where the Five Whys plugs in.
5. Look at thin bones: few ideas often means a blind spot, not an absence of causes.
6. Select the causes worth testing with data. The diagram is a hypothesis map, not proof.

For software and service work the 6 Ms are often renamed: People, Process, Technology, Data, Policy, Environment. ASQ itself notes that Ishikawa encouraged teams to name categories so that users understand them.

Five Whys: strengths and limits

The Five Whys asks "why?" in a chain until the answer is a cause the organisation can act on. It is fast and needs no tools. Its weakness is structural: as a CASRAI guide on corrective action puts it, the method assumes one cause leads to the next in a straight line. Real problems often have several causes that act only in combination. The same guide warns that "operator error" is a starting point, not a root cause.

That is why the fishbone and the Five Whys work best together: the fishbone widens the search, the Five Whys deepens each branch.

How McKinsey's seven steps connect the two

McKinsey's seven-step problem-solving process gives a frame in which gap analysis and RCA are not rivals but parts of one method. Charles Conn and Hugo Sarrazin describe the steps in the McKinsey Podcast (September 2019):

Three ideas from McKinsey change how a business analyst should run both techniques:

• Problem definition comes first. Sarrazin says it is "surprising how often people jump past this step". In gap analysis this shows up as a future state that nobody agreed on; in RCA, as a problem stated so broadly ("sales are bad") that any cause fits.
• Prioritize levers that are big and movable. Conn's example is Pacific salmon: ocean conditions mattered a lot but could not be changed, so the work focused on habitat and harvesting. A fishbone often contains causes outside your control. Name them, then spend the analysis on the ones you can move.
• Start with a day-one answer and iterate. McKinsey teams form an early hypothesis and then try to disprove it. For RCA, this means writing down your best guess of the cause before collecting data, so that the data can prove you wrong.

In a second McKinsey episode (August 2019), Rob McLean describes "wicked" problems with multiple causes, where one fix creates new problems. These are exactly the cases where a single Five Whys chain fails and a categorical tree, a fishbone or an issue tree, is the safer tool. McLean also mentions McKinsey's "obligation to dissent": someone on the team should argue against the favourite cause.

Using both: a worked example

The two techniques answer different questions, so the right practice is to chain them: gap first to see the size of the problem, RCA second to explain it, gap again to define what must change.

Context. An e-commerce company targets a checkout conversion of 62% by Q2. The current rate is 48%.

Step 1 — Gap analysis (what and how much). The analyst compares current and future state on several dimensions:

This table answers "what is missing". It does not answer "why we lose 14 points". A team that stops here will build two delivery options and two payment methods, and may still miss the target.

Step 2 — Root cause analysis (why). The analyst takes the biggest drop-off, the delivery step, and runs a fishbone workshop:

• Process: delivery cost appears only at the last step.
• Technology: the delivery service calls three provider APIs one after another.
• Data: address validation rejects valid addresses with apartment numbers.
• People: no one owns delivery-step performance.
• Policy: free-delivery threshold is not shown in the cart.
• Environment: a competitor offers free pickup points.

Five Whys on the technology branch: the step is slow → API calls are sequential → the integration was built for one provider → performance was never specified → there is no non-functional requirement for the flow. This mirrors the case in our post on non-functional requirements.

Then the analyst tests the candidates with data: funnel analytics by device and address type, session recordings, and support tickets. Two causes explain most of the loss: late delivery cost and address-validation rejections.

Step 3 — Back to the gap (what must change). The gap list is rewritten around causes, not features: show delivery cost in the cart, fix address validation, set a performance NFR, assign an owner. The extra payment methods move to a later transition state. The business case now links each change to a cause and to part of the 14-point gap.

What practitioners say

Practitioners agree on one point: gap analysis without RCA tends to produce lists of symptoms, and RCA without a target tends to fix the wrong problem.

• The Adaptive US gap analysis guide, written by CBAP trainers, puts root cause analysis as a step between gap identification and prioritization in an eight-step process.
• A performance-consulting column in BusinessDay uses a medical analogy: gap analysis establishes that there is a performance problem; root cause analysis is the doctor's diagnosis. It adds that RCA may reveal a skills gap, which then needs its own training needs analysis. The two techniques can loop.
• Lean Data Point, a vendor blog, lists "overlooking root cause analysis" among the most common gap analysis mistakes, describing it as fixing surface symptoms.
• The CASRAI guide warns against stopping at "operator error" or "retraining" as a cause and action.

Common misconceptions

Most errors come from treating one technique as a replacement for the other.

1. "A gap is a cause." "We lack a mobile app" is a gap, not a cause of low engagement. It is a proposed solution in disguise.
2. "RCA needs exactly five whys." Five is a rule of thumb. Stop when the answer is a cause you can act on and verify.
3. "The fishbone gives the answer." It gives hypotheses. Each cause needs evidence before it shapes requirements.
4. "Gap analysis is a one-time exercise." Targets move. In adaptive work, the gap is re-checked at each transition state; see predictive vs adaptive approaches.
5. "RCA looks forward." It looks backward at a problem that exists. Forward-looking uncertainty is risk analysis territory, which uses different techniques.

How CBAP questions test the difference

CBAP scenario questions usually describe a situation and ask which technique or task fits; the key is to spot whether the stem gives a target or a problem.

Our CBAP study materials and the BABOK technique map help you link these signals to tasks. If you also prepare for data analytics, the CBDA exam tests the same split when it moves from a business problem to research questions.

Practice Questions

Question 1

A retailer has documented its current order fulfilment process and agreed on target cycle times for the next year. The sponsor asks the business analyst what must change to reach these targets. What should the analyst do first?

• A. Run a Five Whys session on late orders
• B. Perform a gap analysis between current and future state
• C. Build a fishbone diagram of fulfilment problems
• D. Estimate the cost of a new warehouse system

Answer: B. Both states are defined and the question is "what must change", which is the purpose of gap analysis in Define Change Strategy (BABOK 6.4). RCA would help if the question were why current cycle times are long.

Question 2

After a new claims system went live, processing errors returned to the old level within three months, even though the team had retrained all users. What is the best next step?

• A. Retrain users again with a longer course
• B. Perform root cause analysis on the errors
• C. Define a new future state
• D. Run a gap analysis against industry benchmarks

Answer: B. A recurring problem after a fix is the classic signal that the fix addressed a symptom. RCA in Assess Solution Limitations (BABOK 8.3) looks for causes inside the solution; if causes sit outside it, Assess Enterprise Limitations (8.4) applies.

Question 3

In a workshop, stakeholders give many possible reasons for low customer satisfaction, and the discussion keeps returning to the same two complaints. Which technique helps the analyst structure the discussion?

• A. Five Whys
• B. Gap analysis
• C. Fishbone diagram
• D. SWOT analysis

Answer: C. The fishbone sorts causes into categories and shows which categories have been ignored. The Five Whys deepens one chain but does not widen the search.

Key takeaways

• Gap analysis needs a target and answers "what is missing"; RCA needs a problem and answers "why".
• In BABOK v3, gap analysis is part of task 6.4; RCA is technique 10.40 with fishbone and Five Whys as elements.
• McKinsey's seven steps place both inside one flow: define, disaggregate, prioritize, analyse, synthesize.
• Use the Ishikawa diagram to widen the search, the Five Whys to deepen it, and data to confirm it.
• Rewrite the gap list around verified causes before it becomes requirements or a business case.

FAQ

What is the main difference between gap analysis and root cause analysis?

Gap analysis compares a current state with a defined future state and lists what must change. Root cause analysis examines an existing problem and finds why it happens. One looks forward to a target, the other looks backward to a cause.

Should root cause analysis come before or after gap analysis?

Usually after the first pass of gap analysis and before the final one. The first gap view shows where the biggest shortfalls are; RCA explains them; the final gap list then describes changes that address causes, not symptoms.

Is gap analysis a BABOK technique?

Not as a numbered technique. In BABOK v3 it is an element of task 6.4 Define Change Strategy. Root cause analysis, by contrast, is technique 10.40 in chapter 10.

Is the fishbone diagram the same as root cause analysis?

No. The Ishikawa (fishbone) diagram is one tool inside root cause analysis. It organizes possible causes by category; other tools, such as the Five Whys, Pareto charts or fault trees, then help narrow and verify them.

How does McKinsey's problem-solving method relate to these techniques?

McKinsey's seven steps define the problem, break it into a logic tree, prioritize branches and test hypotheses with analysis. A gap often forms the problem statement, and a fishbone is a kind of logic tree for causes, so both techniques fit inside the method.

Sources

• IIBA — BABOK Guide v3, 10.40 Root Cause Analysis
• IIBA — Task card: Define Change Strategy (PDF)
• IIBA — Task cards: Strategy Analysis (PDF)
• IIBA — Task card: Assess Solution Limitations (PDF)
• McKinsey — How to master the seven-step problem-solving process (2019)
• McKinsey — Want better strategies? Become a bulletproof problem solver (2019)
• McKinsey Quarterly — Enduring Ideas: The 7-S Framework
• ASQ — Fishbone (Ishikawa) diagram
• Adaptive US — Enterprise Analysis vs Strategy Analysis
• Adaptive US — Gap Analysis for Business Analysts
• BA Times — Needs Assessment: The Start of the BA Journey
• BusinessDay — Uncovering performance gaps
• CASRAI — Root cause analysis technique selection
• Lean Data Point — Gap analysis mistakes