Gap Analysis: A Practical Guide for Business Analysts

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Gap analysis is one of the simpler Business Analysis concepts to explain and one of the easier techniques to perform badly.

At its most basic, you are comparing where an organisation is now with where it needs to be, identifying the differences between the two and then working out what needs to change.

That sounds straightforward. The difficulty is that organisations are rarely simple enough for the gap to be described as a neat list of missing features.

A business may want to reduce customer onboarding from ten days to two. The obvious gap appears to be eight days. Once you investigate, however, you may discover manual approvals, duplicated data entry, unclear responsibilities, an ageing system, regulatory checks, poor-quality customer information and three departments working to different rules.

The real gap is therefore not simply:

Current state: 10 days → Future state: 2 days

The useful analysis lies in understanding why the current state performs as it does, what must be different in the future and which changes would actually close the gap.

For a Business Analyst, a practical gap analysis can be approached as:

1. Define the objective → 2. Establish the current state → 3. Define the future state → 4. Identify the gaps → 5. Analyse the causes → 6. Assess impact and priority → 7. Identify possible changes → 8. Turn the analysis into action

That structure matters. If you jump straight from “here is where we are” to a list of solutions, you haven't really performed gap analysis. You have simply generated ideas.

1. Start with the reason for the analysis

Before comparing anything, establish why the organisation wants to change.

Imagine a company tells you:

“We need to improve our customer onboarding process.”

What does improve mean?

Does the organisation want to reduce cost? Complete onboarding faster? Reduce customer abandonment? Improve regulatory compliance? Remove manual work? Increase capacity without recruiting more staff?

Those objectives could lead to very different analysis.

A useful starting statement might be:

The organisation wants to reduce average customer onboarding time from ten working days to three while maintaining existing regulatory controls and reducing manual processing.

That gives you something tangible to investigate.

At this stage, establish the objective, scope, success measures, known constraints and reason the change matters. Where possible, use evidence rather than assumptions.

A useful test is:

If we completed this gap analysis successfully, what decision should the organisation be better able to make?

If nobody can answer that, the purpose probably isn't clear enough yet.

2. Establish the current state

You cannot identify a meaningful gap without understanding where you are starting from.

This is your AS-IS.

Depending on the problem, current-state analysis might involve reviewing processes, systems, roles, data, policies, customer journeys, business rules, performance measures or existing capabilities.

Suppose we are analysing the onboarding example. You might discover that the current process contains 14 steps across four teams and three systems. Customer information is entered twice, applications wait for manual approval, missing documents are identified late, one team works from a spreadsheet and nobody owns the process from beginning to end.

Now you have something useful.

You may use:

• stakeholder interviews;

• workshops;

• observation;

• process mapping;

• system walkthroughs;

• data analysis;

• document review;

• customer feedback;

• complaints;

• service metrics.

Do not assume that the documented process is the real process. Speak to the people doing the work.

A procedure may say:

“Operations verifies the application and sends it to Compliance.”

An Operations employee may tell you:

“Technically, yes. But first we download it into Excel, email Finance and wait for them to send us another spreadsheet.”

That unofficial step may be one of the most important things you discover.

Current-state output

By the end of this stage you should be able to describe:

What happens now → Who is involved → What systems/data are used → What rules apply → Where problems occur → How the current state performs

Without that baseline, your gap analysis is largely guesswork.

3. Define the future state

Next establish what needs to be true in the future.

This is your TO-BE.

Be careful here. The future state should not automatically become a shopping list of features.

For example:

“Implement a new CRM.”

is a solution.

A future-state need might instead be:

“Customer information is captured once and made available to authorised teams throughout the onboarding process.”

That leaves room to determine the most appropriate solution later.

Likewise:

“Build an automated email system”

could be reframed as:

“Customers are automatically informed when further information is required and can see the current status of their application.”

The future state should describe the capabilities, behaviours or outcomes the organisation needs rather than prematurely committing to how they will be delivered.

Useful questions include: What needs to happen differently? What should users be able to do? Which current problems must disappear? What performance level is required? Which controls must remain? What new capability is needed? What should be automated, removed, simplified or standardised?

This is also where you should test ambition against reality. A stakeholder may want a two-minute process that currently takes three weeks. That does not make the ambition wrong, but you need to understand what would have to change to make it possible.

4. Identify the actual gaps

You can now compare the AS-IS and TO-BE.

A simple table is often enough:

Area	Current state	Future state	Gap
Customer data	Entered into two systems manually	Captured once	Duplicate data entry
Application status	Customers telephone for updates	Status available digitally	No self-service status capability
Document checks	Performed late in process	Checked at submission	Validation occurs too late
Approval	Manual queue	Risk-based processing	No automated decision capability
Process ownership	Split between departments	Clear end-to-end ownership	No single accountable owner
Performance	Average 10 working days	Maximum 3 working days	Processing time exceeds target

Notice that the gaps are not all technology gaps.

Some concern process.

Some concern people.

Some concern governance.

Some concern information.

This is important because gap analysis can become distorted when every organisational problem is assumed to require software.

5. Categorise the gaps

For anything beyond a very small piece of work, grouping gaps can make the analysis much easier to understand.

A useful set of categories is:

People — skills, capacity, responsibilities, ownership or training.

Process — inefficient, duplicated, missing or poorly controlled activities.

Technology — missing system capability, integration, automation or tooling.

Data — missing, duplicated, inaccurate, inaccessible or poorly defined information.

Governance — unclear decision-making, ownership, controls or accountability.

Policy and rules — outdated, conflicting or missing business rules.

Customer/user experience — unnecessary effort, delays, confusion or accessibility problems.

Not every project needs all seven. Use categories that make sense for the problem.

The point is to prevent your analysis becoming:

“Gap 1: system needs this. Gap 2: system needs that. Gap 3: system needs something else.”

The organisation may have a technology problem.

It may also have a terrible process that a new system would simply allow it to perform faster.

6. Don't stop at the gap — ask why it exists

Finding a gap is only half the job.

Suppose your analysis identifies:

Gap: Applications regularly exceed the target processing time.

That tells you what is wrong.

It doesn't tell you why.

Perhaps the delay is caused by missing customer information. Perhaps applications sit in an approval queue. Perhaps staff have to switch between three systems. Perhaps the same information is checked twice. Perhaps the team is understaffed on Mondays. Perhaps an unnecessary policy requires a manager to approve every case.

This is where gap analysis often needs to work alongside root-cause analysis.

You might use the Five Whys, cause-and-effect analysis, process investigation, data or further stakeholder discussions.

For example:

Problem: Applications are frequently delayed.

Why? They wait for manual review.

Why? Every application is reviewed by a senior employee.

Why? The existing policy requires senior approval.

Why? The policy was introduced when the organisation had no automated risk controls.

Now the gap looks rather different.

The obvious answer might initially have been “hire more reviewers”.

The analysis suggests that the more valuable question is whether every application still requires the same level of manual approval.

A good BA does not simply record the visible gap.

They investigate what is creating it.

7. Separate symptoms from genuine gaps

This deserves particular attention.

Suppose employees complain:

“The system is too slow.”

It is tempting to record:

Gap: Faster system required.

But what does “slow” mean?

Perhaps the system takes four seconds to load a screen. Perhaps staff actually mean the overall task is slow because they have to enter the same information into five different screens.

One is potentially a performance issue.

The other is a process or usability problem.

Similarly:

“We need more staff.”

might actually mean:

“Thirty per cent of the team's time is spent manually correcting avoidable data errors.”

The requested solution and the underlying gap are not always the same thing.

This is exactly why Business Analysis exists.

8. Assess the impact of each gap

Not every gap deserves fixing.

This can feel counterintuitive. If you have identified something wrong, surely it should be corrected?

Not necessarily.

A gap may affect five customers per year and cost £50,000 to resolve. Another may create a regulatory risk that could prevent the service operating legally.

They should not receive equal attention.

For each significant gap, consider:

• business impact;

• customer/user impact;

• financial impact;

• regulatory or compliance impact;

• operational risk;

• frequency;

• urgency;

• dependency on other changes;

• likely cost or complexity of addressing it.

You can use a simple rating if helpful:

Gap	Impact	Urgency	Complexity	Initial priority
Duplicate data entry	High	Medium	Medium	High
Manual status emails	Medium	Low	Low	Medium
Missing compliance control	Very high	High	Medium	Critical
Cosmetic reporting issue	Low	Low	Medium	Low

Do not mistake the table for the analysis. The discussion behind those ratings is more valuable than whether something receives a three or a four.

The purpose is to help stakeholders make informed trade-offs.

9. Identify what needs to change

Only now should you begin moving seriously towards potential changes.

For each prioritised gap, ask:

What capability, process, behaviour, information or control would need to exist to close this gap?

For example:

Gap: Customer data entered twice.

Needed change: Customer information should be captured once and made available to all authorised parts of the onboarding process.

Gap: Customers telephone for application updates.

Needed change: Customers should be able to view current application status without contacting Customer Service.

Gap: Applications wait for manual review regardless of risk.

Needed change: The organisation needs a method of distinguishing applications requiring manual review from those eligible for streamlined processing.

Notice that these still do not prescribe the exact technical implementation.

That is deliberate.

You are moving from gap → need before jumping to gap → favourite solution.

10. Turn the gaps into requirements and change initiatives

Gap analysis should lead somewhere.

If it finishes as a colourful spreadsheet stored in SharePoint, it has achieved very little.

The significant gaps should begin feeding into whatever mechanism the organisation uses to deliver change. That might include business requirements, epics, capabilities, user stories, process changes, policy updates, training needs, data improvements or technical investigation.

This is where gap analysis connects naturally to requirements analysis.

For example:

Business objective: Reduce onboarding from ten days to three.

Current state: Customer data is manually entered into two systems.

Future state: Customer information is captured once and available throughout onboarding.

Gap: No shared method of capturing and distributing customer information.

Requirement: Authorised onboarding teams must be able to access the same validated customer information without duplicate entry.

Potential delivery: System integration, shared customer record or redesigned onboarding platform.

The chain is visible:

Objective → Current state → Future state → Gap → Requirement → Change

That traceability is enormously useful.

If somebody later asks:

“Why are we spending money on this requirement?”

you have an answer.

11. Validate the analysis

Before treating the gap analysis as complete, take it back to the people who understand the business.

Ask whether the current state is accurate. Check whether the future state reflects what the organisation genuinely needs. Test whether important gaps are missing. Challenge priorities. Confirm major assumptions.

Different stakeholders may interpret the same situation very differently.

Operations may believe the biggest problem is staffing. Technology may blame legacy integration. Customer Service may think the issue is poor customer information. Compliance may believe the existing controls are entirely justified.

Your job is not simply to choose your favourite interpretation.

Bring the evidence together and help the organisation reach a shared understanding.

A useful validation question is:

“If we closed these gaps, would we actually achieve the objective we started with?”

If the answer is no, something is missing.

---

A Structured Gap Analysis Method

For practical BA work, the whole approach can be condensed into this:

Stage	Question	Typical activity	Output
1. Objective	Why are we changing?	Problem/objective analysis	Clear objective
2. Current State	Where are we now?	AS-IS analysis	Current-state baseline
3. Future State	Where do we need to be?	TO-BE analysis	Future-state definition
4. Gaps	What is different?	Compare AS-IS and TO-BE	Gap register
5. Causes	Why do the gaps exist?	Root-cause analysis	Causes/constraints
6. Impact	Which gaps matter?	Impact/risk analysis	Prioritised gaps
7. Change	What needs to be different?	Capability/process analysis	Change needs
8. Action	How do we close them?	Requirements/change planning	Requirements/initiatives

Or, in its simplest form:

WHERE ARE WE? → WHERE DO WE NEED TO BE? → WHAT IS MISSING? → WHY? → WHAT MATTERS MOST? → WHAT NEEDS TO CHANGE?

If you remember nothing else about gap analysis, remember that.

---

A Worked Business Analyst Gap Analysis Example

Imagine an online retailer wants to reduce the number of customers abandoning its returns process.

Objective

Reduce abandoned online return requests and unnecessary Customer Service contacts.

Current state

Customers complete an online returns form. They must manually enter their order number and product information. Eligibility is only checked after submission. Customers receive no immediate indication of whether their return has been accepted and frequently contact Customer Service for updates.

Future state

Authenticated customers can select an eligible order, choose the item they want to return, receive immediate eligibility information and track the progress of the return.

Gaps identified

• Customer account is not connected to the returns journey.

• Customers manually enter information the organisation already holds.

• Eligibility rules are applied too late.

• Customers cannot see return status.

• Customer Service handles avoidable status enquiries.

• Returns data is spread across multiple systems.

Analysis

The visible problem is customer abandonment.

The underlying gaps involve integration, duplicated data entry, poor application of business rules and lack of transparency.

Prioritised change needs

The organisation therefore needs the ability to identify a customer's eligible purchases, apply return rules during the journey, reuse existing order information and expose return status to the customer.

Only after establishing those needs should the team decide exactly how the technology will deliver them.

That is the difference between gap analysis and jumping straight to a feature list.

---

Common Gap Analysis Mistakes

A few mistakes appear repeatedly.

Starting with the desired solution. If the project begins with “we need a new system”, the analysis can become an exercise in justifying something already decided. This one is a real pain in the ass (PITA) to deal with. Senior management/"solution" architects, etc, love to do this. 

Describing the current state from documentation alone. The documented process and the real process may be very different.

Making the future state unrealistically vague. “More efficient”, “better customer experience” and “improved reporting” are aspirations, not useful future-state definitions unless you establish what they actually mean.

Treating every gap as a technology gap. People, processes, policy, data and governance matter too.

Recording symptoms without investigating causes. “Slow processing” tells you what people experience, not necessarily what creates it.

Treating every gap as equally important. Some gaps are commercially trivial. Others can stop the organisation achieving its objective.

Jumping directly from gap to solution. Establish what needs to change before deciding exactly how it should be delivered.

Producing analysis nobody uses. A gap register has little value if the important findings never influence requirements, priorities or investment decisions.

---

Gap Analysis Checklist for Business Analysts

Before finishing, ask yourself:

• Is the objective clear?

• Have I defined the scope?

• Is the current state based on evidence rather than assumption?

• Have I spoken to people who actually perform the work?

• Is the future state specific enough to compare against the current state?

• Have I separated future needs from proposed solutions?

• Have I identified gaps across people, process, technology, data and governance where relevant?

• Have I investigated why the important gaps exist?

• Have I separated symptoms from underlying causes?

• Have I assessed impact and priority?

• Have I considered constraints and dependencies?

• Can each important gap be linked back to the original objective?

• Have the appropriate stakeholders validated the analysis?

• Are the important gaps being converted into requirements or change activity?

If the answer to the final question is no, the analysis probably isn't finished.

---

Gap Analysis Is About Making the Difference Visible

The value of gap analysis is not the gap-analysis template, it's the clarity the technique creates.

Done properly, it allows an organisation to see where it is today, where it genuinely needs to be, what is preventing it from getting there and which changes deserve attention first. It also gives the Business Analyst a structured bridge between understanding a problem and defining meaningful requirements.

That is particularly useful in environments where everybody already has a preferred solution.

The BA can bring the conversation back to something more fundamental: what is actually missing?

Sometimes the answer will be technology. Sometimes it will be a broken process, an outdated policy, poor-quality data, unclear ownership or a capability the organisation simply does not possess.

Finding that difference is the easy part.

Understanding why it exists, whether it matters and what should change because of it is the analysis.

And that is where the Business Analyst earns their keep.

Developing Your Gap Analysis Skills

Gap analysis is a good example of the difference between understanding a Business Analysis technique and being able to use it.

You can learn the basic model in a few minutes:

AS-IS → TO-BE → GAP → CHANGE

The difficult part is being presented with a messy organisation, conflicting stakeholder opinions and incomplete information and working out what belongs in each box.

That is why Elisto's Business Analyst training concentrates on practical application as well as theory. Knowing what a gap analysis is will help you answer a basic interview question. Being able to work through an unfamiliar business problem, establish the current and future states, challenge assumptions and turn the resulting gaps into sensible requirements is considerably more valuable.

The Knowledge Hub can give you the structure.

Learning to apply it when the situation isn't neat and the answer isn't obvious is where the real Business Analysis begins.