Every gap analysis starts the same way: someone in the organization says "we have a problem" or "we're not where we should be." That statement is the beginning of an analysis, not the conclusion of one. The gap between the current state and the desired state exists in someone's perception before it exists on paper, and perception is a biased instrument. It remembers what was painful, forgets what was painful for someone else, and tends to locate the problem in areas outside the perceiver's own control.
A gap analysis built on interviews and workshops captures perception well. It is the right starting point and a poor ending point. The organizations that act on perception-only analyses find themselves investing in solutions to the problems that were loudest in the room, which is not the same set as the problems that most constrain the business.
The current state problem
The most common failure in gap analysis is not misidentifying the desired state: most organizations can articulate, at least approximately, where they want to be. The failure is mischaracterizing the current state. Descriptions of the current state are almost always interviews, and interviews produce qualitative accounts of subjective experience.
A process owner will tell you the current process takes too long. That statement is more informative when paired with the actual cycle time from the system log. A manager will tell you the team lacks the capability to do X. That statement is more informative when paired with a skills inventory showing what training exists and when it was last updated. A customer service lead will tell you that complaints about Y are increasing. That statement is more informative when paired with the ticket volume trend for the last eighteen months.
The interview is not replaceable: it captures context, priorities, and institutional knowledge that don't exist in any log or report. But it needs to be validated against evidence, and the evidence often revises the picture significantly. The gap that everyone in the room agrees is large sometimes turns out to be measurably smaller than a gap nobody mentioned because it affects people who weren't invited.
Evidence sources for current-state assessment
The choice of evidence source depends on what kind of gap is being assessed. These are the sources I use most often:
Process data and system logs. Cycle times, error rates, rework volumes, throughput: anything the system records about how the process runs. This is the most objective evidence source and the most often overlooked, partly because accessing it requires either system knowledge or a data analyst's help, and partly because what it shows is often uncomfortable.
Benchmark data. Industry benchmarks for process performance, capability maturity, or technology adoption. Useful for calibrating whether the gap is a local problem or a sector-wide condition, and for setting a target state grounded in what comparable organizations achieve rather than in aspiration without precedent.
Audit and compliance reports. Findings from internal audit, external review, or regulatory inspection capture gaps that the organization already has on the record. Starting a gap analysis without reading the last audit report is an opportunity to rediscover something already documented.
Customer and user feedback. Support tickets, complaint logs, survey results, NPS trends. These locate gaps from the outside rather than the inside, and they often point to problems the internal team has normalized: something that "always happens" internally may be something that "never happens elsewhere" from a customer's perspective.
Workforce data. Training records, turnover rates, vacancy tenure, skills inventories. Capability gaps are often visible in the data before they become visible in delivery outcomes.
The framework I use
The gap analysis framework I return to most consistently has five columns. It works for capability gaps, process gaps, technology gaps, and organizational structure gaps. The discipline is in applying it the same way regardless of which kind of gap is under review.
| Dimension | Current state (evidence) | Desired state (objective) | Gap (delta) | Priority |
|---|---|---|---|---|
| Approval cycle time | Median 11 days (system log, Q1 to Q3) | Median 3 days (industry benchmark, top quartile) | 8 days | High |
| Data literacy | 62% of analysts passed SQL proficiency check (HR records) | 90% proficiency across analytics team (capability target) | 28 percentage points | Medium |
| Incident resolution | 34% resolved at first contact (support log, 6 months) | 60% first-contact resolution (customer commitment) | 26 percentage points | High |
The current-state column carries the evidence source in parentheses. This is not optional: it is the mechanism that makes the analysis defensible. When a stakeholder challenges the current-state description, the answer is not "that's what we heard in the workshops." It is "that is the median cycle time from the approval system log for the period January to September." One of those answers ends the challenge. The other opens a negotiation.
The desired-state column carries the business objective it maps to. A desired state that floats free of any objective is a preference, not a target. "We want first-contact resolution at 60%" is a target if it's derived from a customer commitment or a competitive analysis. It's a wish if it's derived from the fact that 60 is a round number higher than 34.
Documenting premises
A gap analysis that doesn't document its premises is a gap analysis that can't be updated. Premises are the assumptions that underlie the analysis: that the evidence sources are representative, that the benchmarks are applicable, that the desired state is achievable within the timeframe, that the priority ranking reflects a specific set of organizational constraints.
I document premises in the gap analysis itself, usually in a footnote or a separate section, with three fields per premise: the assumption, the basis for it, and what would change the analysis if the assumption turned out to be wrong. A benchmark is based on a specific industry and company-size band: if the organization is outside that band, the target is not directly applicable and the analysis should say so. An evidence source covers a specific period: if the period is atypical (a COVID quarter, a system migration, a pricing change), the analysis should say so and note what the typical period looks like.
The gap that looks large but isn't the constraint
Not every gap is a bottleneck, and not every bottleneck is the constraint. The constraint is the gap whose resolution would most improve system performance. Closing every other gap while the constraint remains in place produces local optima that don't move the system. This is the insight Goldratt makes in the Theory of Constraints: improvement that doesn't touch the constraint is not meaningful improvement, however real it may be in isolation.
The prioritization column in the framework above is where this reasoning lives. It should not be determined by which gap is most visible, or which gap belongs to the most vocal stakeholder, or which gap is cheapest to close. It should be determined by which gap, if closed, would most move the metric that reflects the objective the analysis is in service of. That question requires judgment, but judgment against explicit criteria is different from judgment against nothing: it can be examined, challenged, and updated as the analysis develops.
Gap analysis is not a document. It's a hypothesis. The hypothesis is that the identified gaps, closed in the identified order, would move the organization from the current state to the desired state. Like any hypothesis, it should be specific enough to be falsifiable and documented clearly enough that it can be tested against what actually happens when the interventions run. An analysis that can't be falsified isn't analysis; it's a plan to do things and call it success.