fit-gap-analysis
Fit-Gap Analysis
Compare a target (spec, vision, competitor, RFP, "to-be") against a system as actually built ("as-is") and turn it into a meeting-ready comparison: a capability matrix (coverage) + a journey comparison (behaviour), verified against the live system, rolled up into a few decisions. Stack-agnostic.
Output quality rests on two things: how completely you enumerated the target, and how honestly you grounded each verdict in the running system. Most fit-gaps fail on the first — a capability that never makes the list can never be verified.
When to invoke
"fit-gap" · "gap analysis" · "capability comparison" · "as-is vs to-be" · "feature parity" · "how far are we from [vision/competitor]?" · "what would it take to support [X]?" · COTS/vendor evaluation · migration/re-platform scoping · "here's the deck/RFP — what changes, what's the impact?". If the user is measuring an existing system against a target, this applies even if they never say "fit-gap".
Principles (the why)
- Ground truth = the live system, not the docs. Docs, wikis, diagrams, exports, READMEs drift. Verify against the running system — its live schema/contract and actual code/config.
- Coverage ≠ behaviour. A checklist says what exists, never how it works. The expensive surprises live in the flow — trace the journey.
- Completeness beats depth — you can only verify what you enumerated. The classic miss isn't shallow checking; it's a capability that never reached the list. Enumerate from several sources and in both directions (target→system = missing; system→target = orphaned), then have a critic hunt for what's left.
- Evidence over opinion. Every verdict cites a concrete artifact — a field, an endpoint, a
file:symbol, a config key, a live count.