How is a gap analysis different from the process map?

The process map (process-map.md) documents how the current process actually works, step by step. The gap analysis takes that current state and compares it against the future state in requirements.md, naming what's missing and why. You typically map the process first, then run the gap analysis against it — the map is an input, the gap analysis is the comparison.

What if I don't have a formal process map yet?

Describe the current process in your own words, paste a few representative support tickets, or walk Claude through what happens today step by step in the chat. It's enough to compare against the requirements doc, though a real process map produces sharper, more specific gaps — worth doing first if the process is complex.

Should every gap turn into a project?

No — that's what the impact/effort ranking is for. Some gaps close with a policy change this afternoon (naming a backup approver); others need a real build. Rank first, then decide which gaps justify a full options analysis and business case, and which just need someone to fix them.

Who should be the \"owner\" of a gap?

Whoever can confirm the gap is real and would be accountable for closing it — often the same stakeholder named in the related requirement. If you don't know, leave it blank rather than let Claude guess a plausible-sounding team name; an unowned gap is a flag to chase down, not a detail to paper over.

Find the gaps between today and the target state

when to reach for this

The requirements doc says what the business needs; the current process rarely delivers it cleanly. A gap analysis is the bridge — it lines up the current state against the desired future state and names, gap by gap, what's missing, what breaks, and why. Skip the "why" and you get a list of symptoms that reads like a complaint; find the root cause and you get something a delivery team can actually plan against. This runs as a conversation in Claude Desktop — open the requirements doc and whatever describes today's process, no terminal needed.

gather this first

Your signed-off requirements.md (or the in-progress draft) — the future state you're comparing against. A gap analysis without it is just an opinion about what's wrong today.
Whatever describes the current state — a process-map.md if one exists, support tickets, a walkthrough of the tool, or your own notes from watching someone do the work.
Who owns each part of the current process, if you know it — gaps need an owner to close them, not just a description.

the workflow

Confirm the future state before comparing anything

Open requirements.md alongside whatever describes today's process in Claude Desktop, and ask Claude to restate the target first. Comparing against a fuzzy target produces a fuzzy gap list.

you ask

Read requirements.md. Before comparing it to anything, restate in your own words what the future state actually requires — as a short numbered list of concrete capabilities or outcomes, not the original prose. Flag anything in the requirements doc that's too vague to compare against.

what you get back A clean numbered restatement — "1) customer can request a return without emailing support, 2) refund decision made within 24 hours, 3) status visible to the customer at every stage" — plus a flag on anything too vague, like "reduce friction" with no measurable target.

If Claude can't restate a requirement concretely, it can't be gap-tested. Send it back to the requirements doc first.
Map the current state against each future-state item

Now bring in whatever describes today — the process map, tickets, your notes — and have Claude check each future-state item against what actually happens now.

you ask

Now read process-map.md (or my notes below) describing how this works today. For each numbered future-state item, tell me: does the current process fully meet it, partially meet it, or not meet it at all? Be specific about what exists today for each one, not just yes/no.

what you get back An item-by-item readout — "1) Not met: no self-serve request path exists, everything routes through email. 2) Partially met: refunds are decided same-day but only during business hours. 3) Not met: no status visibility, customer has to email to check."
Name each gap and dig into its root cause

A gap list without root causes just restates the problem. Push Claude past the symptom to what's actually causing it — a missing tool, an unclear owner, a policy nobody revisited.

you ask

For each item that's partially or not met, name it as a clear gap, then dig into the root cause: is it a missing tool, an unclear process step, an unowned handoff, a policy constraint, or something else? Use the ticket data and process notes to back up each root cause, not just a guess.

what you get back "Gap 1 — No self-serve request path. Root cause: no tool exists for customers to initiate a return; every request currently requires a support agent. Gap 2 — Refunds slow after hours. Root cause: refund approval requires a specific manager's sign-off, and there's no backup approver defined."

"No self-serve tool" is fixable with a build. "No backup approver" is fixable with a policy change this afternoon. Conflating the two is how gap analyses turn into oversized project asks.
Size and prioritize the gaps

Not every gap is equally urgent or equally hard to close. Rank them so the next step — options analysis or a business case — starts from the gaps that matter most.

you ask

Now rank the gaps by impact (how much it affects the outcome stakeholders care about) and rough effort to close (quick fix, moderate, major build). Give me a table: gap, root cause, impact, effort, and a priority ranking. Flag which gaps are dependent on closing another gap first.

what you get back A ranked table — "Gap 1 (self-serve path): high impact, major effort, priority 1. Gap 2 (after-hours refunds): medium impact, quick fix (name a backup approver), priority 2, independent." The dependency flag stops you from sequencing the work wrong.
Write the gap analysis and route it back to an owner

Assemble the findings into one document, and make sure every gap has a name attached before it's considered real — an unowned gap just sits on a list.

you ask

Assemble this into a gap-analysis.md: the future state list, the current-state comparison, each gap with its root cause, and the impact/effort/priority table. For each gap, add a column for who should own confirming or closing it — leave it blank if you don't know, don't guess a name. Show me the diff before saving.

what you get back Claude shows the new file as a diff — you review it, click accept, and gap-analysis.md is saved with every gap traced to a root cause, ranked, and either owned or explicitly flagged as needing an owner.

A blank owner column is honest; a guessed name is a liability. Chase the real name before this document moves anywhere.

make it your own

No process map yet: if process-map.md doesn't exist, describe the current process in your own words or paste a few representative support tickets — Claude can reconstruct enough of the current state to compare, though a real process map makes the gaps sharper.
Multiple stakeholders, different views of "current state": if Ops and Support describe today's process differently, have Claude hold both versions side by side and flag the disagreement as a gap in itself — a process nobody agrees on the shape of is its own root cause.
Feed straight into options analysis: the ranked gap table is the direct input to Compare solution options and land on one — bring gap-analysis.md into that playbook so the options are scored against the gaps that actually matter, not a general wish list.
Recurring gap reviews: for a gap analysis that gets revisited quarterly, keep the same gap-analysis.md and ask Claude to diff this run against the last saved version — "which gaps closed, which are new, which are still open" — so the document tracks progress instead of restarting from zero each time.

watch out for

A gap without a root cause is just a complaint. "Customers are unhappy with returns" doesn't tell anyone what to build. Push every gap to a specific, checkable cause before it goes in the document.
Don't let a guessed owner stand in for a real one. Claude will happily suggest "Ops" or "Engineering" as an owner from context — that's a hypothesis, not a sign-off. Leave the column blank and chase the actual name; a gap analysis with fabricated owners is worse than one with visible blanks.
The future state has to trace back to `requirements.md`. If a gap doesn't map to something a stakeholder actually asked for, it's scope creep dressed up as analysis — check every future-state item against its source requirement before comparing anything against it.
Impact and effort are judgment calls, not facts. Claude's ranking is a starting draft based on what you told it — sanity-check the impact score against the stakeholder who'll feel the gap, not just the ticket volume, before it drives prioritization.

you'll end up with A `gap-analysis.md` — the future state from `requirements.md`, the current state compared item by item, every gap traced to a root cause, and each one ranked by impact and effort with an owner named or explicitly flagged as missing — so the next decision starts from what's actually broken and why, not a vague sense that something's off.

Questions people ask

How is a gap analysis different from the process map?: The process map (`process-map.md`) documents how the current process actually works, step by step. The gap analysis takes that current state and compares it against the future state in `requirements.md`, naming what's missing and why. You typically map the process first, then run the gap analysis against it — the map is an input, the gap analysis is the comparison.
What if I don't have a formal process map yet?: Describe the current process in your own words, paste a few representative support tickets, or walk Claude through what happens today step by step in the chat. It's enough to compare against the requirements doc, though a real process map produces sharper, more specific gaps — worth doing first if the process is complex.
Should every gap turn into a project?: No — that's what the impact/effort ranking is for. Some gaps close with a policy change this afternoon (naming a backup approver); others need a real build. Rank first, then decide which gaps justify a full options analysis and business case, and which just need someone to fix them.
Who should be the \"owner\" of a gap?: Whoever can confirm the gap is real and would be accountable for closing it — often the same stakeholder named in the related requirement. If you don't know, leave it blank rather than let Claude guess a plausible-sounding team name; an unowned gap is a flag to chase down, not a detail to paper over.