Your team already has the gap-analysis, swot-risk-register, and options-analysis playbooks — the worked recipes for comparing current state to future state, sorting scattered concerns into a SWOT, and scoring a table of candidate solutions. Each is a good move, done once. This module is the layer that turns those separate moves into the analysis a delivery team can actually act on: gaps traced to their real cause instead of their loudest symptom, a risk register that’s still true next month, and an options analysis that ends in a recommendation someone can actually approve.
It’s Module 2 of the certifiable Business Analyst track, and it inherits everything you built in Module 1. Your requirements-doc.md isn’t background reading here — it’s the target every gap in this module is measured against, and the source every option is judged against. M1 mastered what the business actually needs, from whom, and why; M2 builds the analysis that decides what to do about the distance between that and today — and assesses the analysis, not a plausible-sounding first draft.
Analysis is where a BA earns trust or loses it. Anyone can produce a gap list, a SWOT, and a table of options that look rigorous — three columns, some scores, a tidy structure. What separates real analysis from decoration is whether a skeptical stakeholder can poke at it and have it hold: does this gap trace to something you can actually fix, or does it restate the complaint in fancier words? Does this risk register still say something true next month, or was it written once for a meeting and never opened again? Does this options table actually let someone decide, or is it a wall of pros and cons that lets the loudest voice in the room win anyway? The free playbooks teach you the structure. This module is where the structure has to survive contact with someone whose job is to find the hole in it.
Root-causing a gap properly
A gap analysis’s only real job is separating symptoms from causes, and most first drafts don’t do it — they stop at the first plausible-sounding explanation and call it done. “Customers are unhappy with returns” isn’t a root cause, it’s the complaint restated. “Support is overwhelmed” isn’t a root cause either — it’s one level down, and still not actionable. The discipline that gets you somewhere useful is the same one behind the classic five-whys: keep asking why until you hit something you can actually point at and fix, then stop — one level past plausible is where the useful causes live, and going further usually wanders into speculation nobody can verify.
- Ask why at least twice past the first answer. “No self-serve return path” (why #1: nobody built one) is a real finding, but push once more: why wasn’t one built — because nobody owned the decision, because it was deprioritized twice, because the policy underneath it was never finalized? The second and third why is usually where the fixable cause sits, not the first.
- Distinguish a build problem from a policy problem from an ownership problem. “No self-serve tool exists” needs an engineering project. “No backup approver is named for after-hours refunds” needs a policy decision this week. Conflating the two is how a gap analysis turns a same-day fix into an oversized ask — and how a genuine build need gets waved off as “just update the policy.”
- Back every root cause with something real. A root cause backed by a ticket count, a process-map step, or a named stakeholder’s account is a finding. A root cause that’s really just your best guess dressed as analysis is a liability the moment someone asks “how do you know?” — say so explicitly when you’re inferring rather than citing.
- Know when to stop. Five-whys style digging is a discipline, not a mandate to reach existential conclusions. “Why is there no self-serve return path” → “because nobody owned building it” → “because ownership of self-serve tooling was never assigned after the last reorg” is a good stopping point — a real, fixable, sourceable cause. Chasing it further into “why did the reorg happen” is a different project, not this gap.
Keeping a risk register alive, not just written
A SWOT and a risk register are the two artifacts most likely to be produced once, shown in a meeting, and never opened again — which makes them exactly as useful as the scattered concerns they replaced. The discipline that makes a risk register worth the time it took to write is treating it as something with a pulse, not a deliverable you check off.
- A risk register isn’t a brainstorm — don’t pad it. The instinct under pressure is to list every conceivable thing that could go wrong, because a long list feels thorough. It isn’t — it’s noise that buries the two or three risks that actually matter under a pile of theoretical ones. Every entry should trace to something real: a note from an actual stakeholder, a pattern in the ticket data, a comparable initiative that hit this exact problem. If you can’t say where a risk came from, it doesn’t belong on the register yet.
- Every risk needs all four fields, or it isn’t tracked. Likelihood and impact without an owner is an observation. An owner without a mitigation is a name attached to a shrug. The four fields — likelihood, impact, owner, mitigation — are what turn “we’re a little worried about this” into something a person is actually accountable for watching.
- An unowned risk is the most urgent line on the page, not the least. The pull is to fill every blank with a plausible team name so the document looks complete. Resist it — a guessed owner is worse than a visible blank, because a blank gets chased down and a guess quietly gets ignored by whoever it was guessed onto.
- Build in the revisit, don’t bolt it on. A review-by date at the top of the document is what separates a risk register from a slide shown once. When you come back to it, the job is a diff against the last saved version — what’s resolved, what’s changed, what’s newly emerged — not a fresh SWOT from a blank page. A register nobody reopens is exactly as dead as the scattered notes it replaced.
- Likelihood and impact are hypotheses, not measurements. Claude will propose scores that read as confident and precise. Treat them as a first draft to sanity-check against whoever has actually lived through the process — a wrong score that goes unchallenged is how a real risk quietly under-ranks itself into “monitor only.”
Options analysis as a decision instrument, not a pros/cons list
The failure mode of most options analyses isn’t a lack of options — it’s a table that describes each option in its own most flattering language and lets the loudest advocate’s framing win by default. An options analysis is only a decision instrument if every candidate is forced onto identical terms.
- Same criteria, same columns, every option — no exceptions. Cost, effort, risk, time-to-value (plus anything the requirements doc implies matters here) apply to every row the same way. The moment one option gets described in prose while another gets hard numbers, the comparison is already biased toward whichever one sounds more finished.
- Mark every estimate as an estimate. A cost or effort figure inferred from context is a guess until someone verifies it. Presenting an estimate with the same confidence as a sourced number is how a table looks rigorous and turns out to be built on sand — the fix is cheap: just flag which cells are real and which are inferred.
- Name what’s NOT solved by each option — every time. Cost and effort tell you what an option takes; this tells you what it leaves broken. A full-build option that solves everything and a quick patch that solves the loudest 20% of the problem look very different once “doesn’t solve” sits next to each score — and it’s usually the line that actually drives the decision.
- Name who signs off, by role or by name — never just “leadership.” An option with no real approver attached is the one that stalls quietly in committee for a month before anyone notices nobody owns the decision. If you genuinely don’t know, leave it blank and chase the name — the same rule as an unowned gap or risk.
- A recommendation earns its keep by naming what would flip it. “We recommend Option B” is an opinion. “We recommend Option B because it ships this quarter at moderate risk; this flips to Option C if the priority shifts from ‘ship this quarter’ to ‘solve the gap completely,’ or if budget opens up” is a decision instrument — it tells a skeptical stakeholder exactly which assumption to argue with instead of re-litigating the whole table.
- Check whether the criteria were set before or after you saw the scores. If cost, effort, risk, and time-to-value happen to rank in precisely the order that favors the option you walked in wanting, that’s worth a second look before you circulate it — criteria chosen to fit a favorite isn’t a comparison, it’s a justification.
Your assignment
Run the full analysis for your own initiative (recommended — the output becomes a real gap analysis, risk register, and options recommendation your team actually uses) or the sample brand Mizan, the GCC bookkeeping SaaS whose Business Analyst, Noor Al-Suwaidi, runs throughout this track. Everything here inherits requirements-doc.md from Module 1; if you don’t have it yet, do Module 1 first. Open your BA folder in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.
Module 2 deliverable — the analysis
Inherits from M1: requirements-doc.md (+ stakeholder-map.md for owners)
1. gap-analysis.md
- the future state restated as a short numbered list from requirements-doc.md
- current state compared item by item: fully met / partially met / not met
- every gap named, with a root cause dug at least two "whys" past the
first plausible answer — sourced from real notes/tickets, not guessed
- impact/effort table, ranked, dependencies flagged
- an owner per gap — named or explicitly flagged as missing, never guessed
2. risk-register.md (with the SWOT that produced it, for context)
- a SWOT sourced from requirements-doc.md and real notes — no generic,
untraceable entries
- every weakness/threat that could derail the initiative converted to a
risk: likelihood, impact, owner, mitigation — all four, every row
- ranked by likelihood x impact, top risks called out as decide-now vs.
monitor-only
- a review-by date at the top, and standing instructions for how the
next revisit should work (diff against this version, not a rewrite)
3. options-analysis.md
- 2-4 options restated in one sentence each, criteria confirmed
- every option scored on identical criteria (cost, effort, risk,
time-to-value); every estimate clearly flagged as an estimate
- what each option does NOT solve, named explicitly
- who signs off on each option — a role or a real name, blank if unknown
- a recommendation: why it wins on stated priorities, what's given up,
and what would have to change for the recommendation to flip
Every owner and sign-off column is a real name/role or an explicit blank —
never a guessed team name standing in for accountability.The Foundation toolkit you installed in M1 already holds your CLAUDE.md and requirements-doc.md. The toolkit additions at the end of this module give you the gap, risk-register, and options templates, so you’re filling in structure, not starting from a blank page.
How it’s graded — the rubric
This is the part the free playbooks don’t have, and the part that makes the credential mean something. Your three deliverables are scored against five criteria. Each is meets / nearly / not yet, and a “nearly” on any one is a revise, not a pass.
Analysis rubric
1. Root cause, not symptom Every gap traces to a specific, sourced
cause — not a restated complaint. The
"why" chain goes at least two levels past
the first plausible answer, and stops at
something fixable, not speculation.
2. Every risk is fully specified Likelihood, impact, owner, and mitigation
are present for every risk register entry.
No blank field is standing in for "we
haven't decided" — unowned risks are
flagged, not silently dropped.
3. Options scored identically Every option is judged on the same named
criteria in the same table. Estimates are
clearly flagged as estimates. No option is
described in flattering prose while
another gets hard numbers.
4. The recommendation is
defensible and reversible The recommendation states why it wins on
stated priorities, what it gives up, and
exactly what would have to change to flip
it to a different option.
5. Nothing is guessed into an
owner or sign-off column Every gap, risk, and option carries a real
name/role or an explicit, visible blank —
never a plausible-sounding placeholder.The discipline is what a delivery lead or steering committee would demand before committing budget: a gap analysis that stops at the symptom, a risk register nobody will reopen, or an options table secretly built to justify a favorite all fail quietly — the cost shows up months later as a project nobody scoped correctly. That’s exactly why it’s caught here.
The bar, shown — a worked model answer (Mizan)
You don’t have to guess what “meets” looks like. Here are passing excerpts from Business Analyst Noor Al-Suwaidi’s actual files, built after the March 1, 2026 double-billing incident, when co-founder Dana Al-Qassimi asked her to run the formal requirements process for a customer-facing “dispute a charge” feature. Noor’s requirements-doc.md (Module 1) already named the future state and the affected stakeholders — Support, Finance, Data, and Engineering. This module is where she decides what to actually build.
gap-analysis.md — Mizan: self-serve dispute flag (excerpt)
Future state (from requirements-doc.md, restated):
1. Customer can flag a disputed charge without emailing support
2. A dispute is triaged and either resolved or escalated within 48 hours
3. Customer sees the dispute's status without asking again
4. Fraudulent/abusive disputes are distinguishable from genuine billing
errors before a refund is issued
Current state, item by item:
1. NOT MET — every dispute today starts as a support email; no in-app
path exists (support-tickets.csv, Feb-Mar 2026)
2. PARTIALLY MET — Layla's team (Support) triages within a day on
average, but "resolved" means a human manually checks Finance's
ledger; no SLA is written down anywhere
3. NOT MET — customer has to email again to check status; 40% of the
11 double-billing tickets included a "any update?" follow-up
4. NOT MET — no distinction exists today; every dispute gets the same
manual review regardless of pattern
Gaps, root cause (two whys past the first plausible answer):
Gap 1 — No self-serve flag path.
Why: no tool exists for a customer to flag a charge themselves.
Why (deeper): self-serve billing tooling was never prioritized because
disputes were assumed to be rare — true until the March 1 double-charge
bug produced 11 in one week. Root cause: the assumption "disputes are
rare" was never revisited after the incident that disproved it.
Gap 2 — No written SLA for triage.
Why: triage happens informally through Layla's team's judgment.
Why (deeper): nobody owns writing a support SLA for billing disputes
specifically (a general SLA exists for tickets, not this category).
Root cause: billing disputes were never split out as their own ticket
type, so they inherit a generic SLA that doesn't fit a case that
touches Finance's ledger, not just a reply.
Gap 3 — No status visibility.
Root cause: same as Gap 1 — no self-serve surface exists at all, so
there's nowhere to show a status even if triage were instant.
Gap 4 — No fraud/genuine-error distinction.
Why: every dispute is manually reviewed the same way regardless of
pattern.
Why (deeper): nobody has looked at whether disputes cluster in a way
that would let a rule flag likely-fraud automatically — Data (Maya
Haddad) hasn't been asked this question yet. Root cause: fraud
triage logic doesn't exist because nobody has scoped it as a
requirement until now.
Impact / effort / priority:
Gap Impact Effort Priority Dependency
1 High Major (build) 1 Gaps 3 depends on Gap 1 shipping
2 Medium Quick (policy) 2 Independent — can close this week
4 High Moderate 3 Needs Gap 1's data before scoping
3 High (see Gap 1) — Not separately buildable
Owners:
Gap 1 — Engineering lead (Bilal Al-Mansouri), to confirm scope — pending
Gap 2 — Support Lead (Layla Al-Nasser) — confirmed, can write this week
Gap 4 — [blank — needs Data + Finance to jointly scope; not yet named]risk-register.md — Mizan: self-serve dispute flag
(reviewed 2026-07-01, next review 2026-08-01)
SWOT that produced this register (sourced, not generic):
Weakness: no SLA for billing disputes (gap-analysis.md, Gap 2)
Weakness: no fraud/genuine-error distinction (Gap 4)
Threat: a self-serve flag button could itself be abused for fraudulent
disputes — raised by Dana in the Jun 28 scoping call, not yet
quantified
Opportunity: the same flag data could feed Data's churn-risk model
(Maya's dashboard) if structured consistently from day one
Risk register:
Risk: A public self-serve "dispute" button gets used for fraudulent
chargebacks or buyer's-remorse disputes, not genuine billing errors.
Likelihood: medium (no fraud pattern exists to check against yet).
Impact: high (each false dispute costs a manual review + potential
wrongful refund).
Owner: Finance lead — [confirm with Youssef Hamdan].
Mitigation: launch the flag with a manual-review gate before any
refund issues automatically; revisit auto-approval only after a
quarter of pattern data exists.
Risk: Support ticket volume spikes if the flag makes disputing easier
without also making triage faster.
Likelihood: high (making a friction point easier to reach typically
increases volume before process catches up).
Impact: medium (delay, not lost revenue, if triage keeps pace).
Owner: Layla Al-Nasser (Support Lead).
Mitigation: ship Gap 2's written SLA before or alongside the flag,
not after — the two gaps are more coupled than the priority table
ranks them.
Risk: No fraud/genuine-error distinction means the launch has to run
fully manual, undercutting the "reduce support load" goal the
initiative was pitched on.
Likelihood: high (Gap 4's root cause confirms no rule exists today).
Impact: medium (feature still ships, just doesn't hit its full ROI
case in v1).
Owner: [blank — needs Data + Finance jointly; chase before next
review].
Mitigation: scope a v1 with manual review; task Maya (Data) with a
fraud-pattern analysis in parallel so v2 can automate.
Top risk needing a decision now: the fraud-abuse risk — Finance needs to
confirm the manual-review gate before this gets scoped into engineering,
not after. The volume-spike risk is a monitor item once Gap 2's SLA
ships. The unowned Gap 4 risk is the most urgent blank to close before
this register is considered complete.options-analysis.md — Mizan: closing the dispute-flag gap (excerpt)
Options, restated:
A — Full self-serve dispute-and-hold: customer flags a charge in-app,
it auto-holds the disputed amount, routes to Finance for review.
B — Lightweight "flag for review" button: customer flags a charge
in-app, no auto-hold; routes straight to Support's existing queue
with the flag visible on the account.
C — Internal-only triage improvement: no customer-facing UI; Support
gets a structured internal form + Layla's SLA (Gap 2) to triage
faster, customers still email in.
Criteria confirmed: cost, effort, risk, time-to-value, fraud exposure
(added — Dana's Jun 28 concern makes this load-bearing here).
Scoring:
Option Cost Effort Risk Time-to-value Fraud exposure
A ~$95K (est.) Major (1 quarter) Med-high Slow Needs the
(auto- (ships end mitigation
hold of Q3) above before
logic) any auto-hold
B ~$30K (est.) Moderate Medium Faster Lower — no
(6 weeks) (ships mid-Q3) auto-hold,
still manual
review
C ~$4K (est., Quick (2 weeks) Low Immediate Unchanged —
mostly no new
Layla's customer
time) surface to
abuse
What each does NOT solve:
A — doesn't ship this quarter; carries the highest fraud exposure until
the manual-review mitigation is proven out over a full cycle.
B — doesn't auto-hold funds, so a disputed charge can still clear before
review finishes; doesn't reduce support headcount need, just makes
intake easier.
C — doesn't give customers self-serve visibility at all — Gap 1 and
Gap 3 stay open; this only closes Gap 2.
Sign-off needed:
A — Engineering lead (Bilal Al-Mansouri) + Finance (Youssef Hamdan,
budget + the auto-hold mitigation) + Dana (fraud-exposure call).
B — Engineering lead + Support Lead (Layla Al-Nasser).
C — Support Lead only — [confirm Dana doesn't want sign-off given it's
the smallest change].
Recommendation: Option B — the lightweight flag-for-review button.
It closes the two highest-priority, highest-visibility gaps (self-serve
flagging and status visibility) within the quarter, at medium risk, without
taking on Option A's fraud exposure before a mitigation is proven. It gives
up auto-hold — a disputed charge can still clear before Finance reviews it,
which Finance should weigh against the fraud data Maya is producing in
parallel. This flips to Option A if Maya's fraud-pattern analysis (running
alongside this launch) shows disputes cluster predictably enough to justify
auto-hold logic in a v2, or if the volume risk in risk-register.md proves
worse than modeled and manual triage can't keep pace even with Gap 2's SLA.
It flips to Option C only if Engineering capacity disappears entirely this
quarter — in which case the SLA alone is the fallback, not the goal.What you’ve proven — and what’s next
Clear the rubric and you’ve proven something a plausible-looking first draft never can: that your gaps trace to real causes, your risks are actually tracked instead of just written down, and your recommendation is something a skeptical stakeholder can challenge on its own terms instead of picking apart for missing rigor. That’s the Analysis stage of “Certified Business Analyst with Claude.”
From here the track turns a defensible analysis into a funded, sequenced initiative, each module assessed the same way:
- Module 3 — the decision: turning the recommended option into a costed business case with payback math, and a synthesis (SWOT plus the sign-offs you’ve already named) that gets it in front of the right decision-maker.
- Module 4 — from decision to delivery, Module 5 — governance & the exec briefing, then the capstone — a complete requirements-to-recommendation package for one initiative, end to end, graded into the certificate.
First, make the analysis reusable: the gap, risk-register, and options templates below extend the Foundation toolkit you already installed. And when Option B (or whichever option your own initiative lands on) moves to a business case, the sign-off names and the “what would flip it” line in options-analysis.md are exactly what the next module’s costing starts from — don’t let that reasoning get lost between documents.
# gap-analysis.md — [Initiative]
## Future state (restated from requirements-doc.md, numbered)
1. [capability/outcome] 2. [capability/outcome] ...
## Current state, item by item
[#] — fully met / partially met / not met — [what actually exists today]
## Gaps and root causes (2+ whys past the first plausible answer)
Gap [#] — [name it]
Why: [first answer] Why (deeper): [root cause, sourced]
## Impact / effort / priority
Gap | Impact | Effort | Priority | Dependency
## Owners
Gap [#] — [name/role, or "blank — chasing [who]"]# risk-register.md — [Initiative]
Reviewed: [date] Next review: [date]
## SWOT (sourced from requirements-doc.md + real notes only)
Strengths / Weaknesses / Opportunities / Threats
## Register
Risk: [statement]
Likelihood: low/med/high Impact: low/med/high
Owner: [name/role, or blank] Mitigation: [concrete action]
## This review's call
Top risk needing a decision now: [...]
Monitor-only: [...]
Unowned — most urgent to close: [...]# options-analysis.md — [Initiative]
## Options (2-4, one sentence each)
A — [...] B — [...] C — [...]
## Criteria
[cost, effort, risk, time-to-value, + anything requirements.md implies]
## Scoring (same table, same columns, every option)
Option | Cost | Effort | Risk | Time-to-value | [extra criterion]
## What each does NOT solve
A — [...] B — [...] C — [...]
## Sign-off needed
A — [name/role] B — [name/role] C — [name/role, or blank]
## Recommendation
Pick: [option]. Wins because: [...]. Gives up: [...].
Flips to [option] if: [...].The saved-prompt library (Analysis) — add to the Foundation set
Root-cause a gap
"Read requirements-doc.md and [process notes/tickets]. For each future-
state item, tell me if it's fully met, partially met, or not met today.
For every gap, dig into the root cause — ask why at least twice past
the first plausible answer, and stop at something specific and
sourced, not speculation. Flag anywhere you're guessing rather than
citing something real."
Stress-test a SWOT before it becomes a risk register
"Review this SWOT critically. Which strengths are really just
unverified assumptions? Are there threats implied by requirements-doc.md
or gap-analysis.md that nobody's raised yet? Flag anything that
contradicts something else in the notes. Then convert every weakness
and threat that could derail this into a risk register entry with
likelihood, impact, owner, and mitigation — leave the owner blank
rather than guess a name."
Score options honestly
"Score these options on [criteria] in one table, one row per option.
Flag every estimated figure clearly as an estimate. For each option,
name what it explicitly does NOT solve from gap-analysis.md, and who
would need to sign off before it moves to build — a real name or role,
blank if you don't know. Don't flatten the differences to make the
options look more similar than they are."
Get a recommendation that names what would flip it
"Given these scores and our stated priorities [state them], recommend
one option. Explain why it wins, what we give up, and exactly what
would have to change for the recommendation to flip to a different
option."