Gap Analysis: How BAs Find What the Project Is Actually Missing

The design was approved. Everyone in the room signed up to it. Nobody asked what it would take to get from today’s process to that design.

So the project builds toward the target. Then, somewhere in build or UAT, something obvious turns out to be missing. A business rule nobody accounted for. A data field with nowhere to come from. A step the old process handled quietly that the new one just drops. It is not a defect exactly, because nothing was built wrong. It is a hole where a requirement should have been.

The frustrating part is how avoidable it feels afterwards. The missing piece was not hidden. It sat in the distance between where things are now and where the project wants to be, and nobody measured that distance.

That distance is what gap analysis measures.

5-Minute Learning summary

Technique:
Gap analysis

Helps with:
Finding the capabilities, rules, data, and process steps a project is missing before they surface late in build, UAT, or after go-live.

BA move:
Agree the current state and the target state, compare them element by element, and turn the differences into a named list of work the project must close.

What the technique helps with

Gap analysis answers one question: what has to change to get from the current state to the target state, and what is the project missing to close that gap?

The value is not in the idea. It is in the discipline. Most projects never do the comparison deliberately, so a whole class of missing work stays invisible until it blocks something.

The project problem it addresses

Requirements work describes the target. Design work describes the solution. Both are useful. Neither one forces a structured look at the distance between the target and today.

So the gaps that live in that distance stay hidden. A missing integration to a system the new process depends on. A manual workaround the current process quietly relies on that the new design silently removes. None of these are wrong requirements. They are absent ones, and absence is what a project focused on features and design is worst at noticing.

You cannot elicit a requirement for something nobody realised was missing. You can only find it by comparison.

The technique in plain language

Gap analysis works with two pictures. The current state is what exists and happens today. Not the tidy version in a process document, the real one, including the informal fixes and exceptions people rely on. The target state is what needs to exist when the project is done: the approved design, the intended behaviour, the target process.

The technique is the disciplined comparison between them. For each element of the target, you ask a plain question: does this exist today, does it partly exist, or does it not exist at all? Then you ask it in reverse, for anything the current state does that the target quietly drops.

The output is the gap list. Each gap is one specific thing the project must add, change, or remove to reach the target. That is the whole technique. No matrix maths, no maturity model. The discipline is in going element by element, and in the rule that a gap is only real once both states are actually agreed.

A tangible example

A team is replacing a manual, spreadsheet-based approvals process with a new workflow system. The target design was approved weeks ago. Requests come in, route to an approver, get logged. Everyone signed off. Build is underway.

The BA does not assume the approved design is complete. They pin the target state, then capture the current state at the same level of detail by walking through how approvals actually happen today. Not the official version. The real one.

Comparing the two element by element, one delta stands out. In the current process, when an approver is unavailable, requests get quietly rerouted to a backup by the team admin. It is an informal rule nobody wrote down, and it keeps the business moving when someone is on leave. The approved target design has no concept of a backup approver. It exists nowhere in the new system.

That is a gap, and it surfaces now, as a named item, rather than in UAT when a business user tries to approve for an absent colleague and finds they cannot. Because it is visible early, it becomes a decision the team makes on purpose: build the delegation path, defer it with a documented workaround, or accept the change. Any of those is fine. What matters is that it is a decision instead of a surprise. Only the comparison catches what the old process quietly did that the new one drops.

How a BA can apply it

The steps below are sequential. You cannot compare states you have not pinned, and a gap you never classify never becomes work. Run them in order.

Step 1: Pin the target state. Get an agreed, specific description of what needs to exist when the project is done: the approved design, the intended behavior, the target process. Output: a target-state reference everyone accepts, not one person’s interpretation of it.

Step 2: Capture the current state at the same level of detail. Describe what exists and happens today for the same scope, including the informal workarounds and exception handling people actually rely on. Output: a current-state view that matches the target’s granularity.

Step 3: Compare element by element. For each element of the target, ask whether it exists today, partly exists, or does not exist at all. Then reverse it: check what the current state does that the target silently drops. Output: a marked-up comparison.

Step 4: Classify each gap. For every delta, note what it is (missing capability, rule, data, integration, or process step) and whether it is in scope, needs a decision, or is a known exclusion. Output: a classified gap list.

Step 5: Turn gaps into named work. Convert each in-scope gap into a story, an acceptance criterion, or an explicit scope decision. A gap that is not converted into work or a decision does not exist as far as delivery is concerned. Output: gaps promoted into the backlog or the scope log.

Steps 1 to 3 are where the missing pieces surface. Steps 4 and 5 are where the technique earns its keep. A gap list that never turns into stories, acceptance criteria, or scope decisions is just a document that made everyone feel thorough. This is also the point where writing sharp acceptance criteria stops the gap you just found from turning into a vaguer one downstream.

The IT Project Problem Diagnostic Checklist includes a Requirements Health section. Use it to check whether missing rules, edge cases, and assumptions are already hiding in your requirements before they surface as gaps downstream.

Common mistakes

Comparing against a target nobody agreed. If the target state is really one person’s assumption, your “gaps” are just disagreements about the target wearing a lab coat. Pin the target first, or you are debating it, not finding gaps.

Capturing the two states at different levels of detail. A high-level target compared against a step-by-step current state gives you an apples-to-oranges comparison that misses the real deltas. Match the granularity on both sides.

Leaving the gap list as a document. If a gap does not turn into a story, a criterion, or a logged scope decision, delivery never sees it, and it resurfaces later as a surprise.

Only walking the happy path. Most expensive gaps live in the exceptions: the leave cover, the failure case, the workaround the current process quietly depends on. Compare only the clean path and you miss exactly the gaps this technique is best at catching.

When to use it and when not to use it

Reach for gap analysis when a target already exists and you need to know what stands between it and today. Replacing a system, migrating off a legacy process, rolling out a new operating model. Anywhere “we are replacing X with Y” is in play, the distance between X and Y is where the missing work hides.

Do not reach for it when there is no agreed target yet. If the target is still being argued about, you are not doing gap analysis, you are still defining scope, and that is a different job. This is the clean line between gap analysis and scoping by business event: that technique helps you define the target in the first place, by working out what the operation must respond to. Gap analysis assumes a target already exists and measures the distance to it. Run them in the wrong order and you produce a very confident list of gaps against a target that was never real.

Also skip the formal version when the change is small and the gap is obvious: a structured comparison then is overhead, not insight. And it does nothing on a true greenfield, where there is no current state to measure from. Gap analysis needs two real, agreed states. Without both, it produces confident noise.

FAQ

Isn’t gap analysis just requirements gathering?
No. Elicitation describes the target: what the system or process should do. Gap analysis takes that target, compares it to what exists today, and lists the difference.

What if there is no documented current state?
Then capturing it lightly is step one. You do not need a formal process model, just an honest picture of how things work today, including the informal bits. A vague current state gives you a vague gap list.

How formal does the gap list need to be?
As light as a shared table works fine. The discipline is in the comparison and in converting gaps into work, not in the template. A tidy matrix nobody turns into stories is worth less than a rough list everyone acts on.

Where to go next

If the gaps you find keep arriving as unplanned additions after the boundary was supposedly set, that is often scope quietly expanding rather than genuine discovery. It is worth checking which one you are dealing with before you add it.

Your next step

Take one feature or process on your current project that has an approved target. Pin that target, capture how things work today at the same level of detail, and compare them element by element. Write down every difference. Then count how many are already in your backlog. The ones that are not are what the project is about to find the expensive way.

Before the next build starts, use the IT Project Problem Diagnostic Checklist to check whether scope gaps and unclear requirements are already building up where nobody has looked.