Fit-gap analysis: the most valuable phase of any software project

Every enterprise software project reaches a point where the organisation’s way of working meets the software’s way of working. Somewhere, they will not match. Fit-gap analysis is the structured process of finding those mismatches and deciding, one by one, what to do about them: adapt the software, adapt the process, build something new or accept the gap.

It is not the most glamorous phase. It involves long workshops, detailed scenarios and difficult conversations about how much a particular way of working is really worth. But it is where most of the cost, risk and long-term maintainability of the project is decided. Projects that skip it or rush it usually discover their gaps later, during testing or after go-live, when they are far more expensive to resolve.

Why fit-gap matters so much

A gap found in a workshop costs a conversation. The same gap found in user acceptance testing costs rework, retesting and often a delayed go-live. Found after launch, it costs workarounds, frustrated users and an unplanned change request. The cost of a gap rises sharply the later it is discovered.

Fit-gap also shapes the long-term character of the system. Every customisation becomes something that must be maintained, tested and carried through future upgrades. A project that customises freely during implementation may find, a few years later, that upgrades have become slow and expensive. Fit-gap is where that trade-off is made deliberately rather than by accident.

Step one: list processes by importance

Start with the processes that earn or protect the most money, and test the software against them first. For a distributor, that might be order to cash and procure to pay. For a manufacturer, planning, production and costing. For a services business, project accounting and billing. These are the processes where a poor fit hurts most.

• Build a process list at two or three levels of detail, from end-to-end flows down to individual activities.
• Rank each process by value and risk: revenue at stake, cost, compliance exposure and customer impact.
• Identify what genuinely differentiates you from competitors. These processes may justify some tailoring; most others should not.
• Assign a business owner to each major process who can make decisions about it.

Ranking matters because workshop time is finite. It is better to examine the critical processes in depth than to cover every process superficially.

Lower-priority processes still need attention, but a lighter touch is usually enough: a short walkthrough of the standard flow, a check for obvious blockers and agreement to adopt the standard unless a strong reason emerges. This keeps the workshop programme focused where the stakes are highest.

Step two: test with real scenarios

Fit-gap works best when it uses concrete scenarios rather than abstract requirements. Instead of asking whether the system supports partial deliveries, walk through a real example: a customer orders five products, two are out of stock, the customer wants the rest shipped now and the remainder later, with one invoice. Then watch what the software does.

Preparing scenarios

1. Collect real examples from each process owner, including awkward cases that cause problems today.
2. Write each scenario as a short story with specific inputs and the expected outcome.
3. Prepare sample data in a demonstration environment so the walkthrough is realistic.
4. Invite the people who do the work, not only managers, so practical details surface.

Seeing the software handle a familiar case is far more revealing than reading a feature list. It also helps the business understand the standard process, which often turns out to be more capable than expected.

Step three: classify every gap

For every point where the software and the process differ, mark the gap as one of five types. Using a consistent classification makes decisions comparable and keeps the conversation honest about cost.

• Fit: the standard software supports the process as it is. No action needed.
• Configure: the software supports it through settings, workflows or parameters, without code.
• Adapt the process: the business changes its way of working to match the standard software.
• Customise: new code, extensions or integrations are built to close the gap.
• Leave out: the requirement is dropped, deferred or handled outside the system.

Adapting the process deserves serious consideration. Many requirements reflect habits built around an old system rather than genuine business needs. Standard software usually encodes sound practice, and adopting it can simplify work as well as reduce cost. A useful test is to ask what would happen if the requirement were not met. If the honest answer is that people would need to learn a different way, adapting the process may be the right call.

A worked example

Consider a typical wholesaler moving to a new ERP. In workshops, the sales team asks for a custom pricing screen that replicates their old system, with a special discount field for each customer. The scenario walkthrough shows that the standard price list and discount rules can produce the same prices, though the screen looks different. That gap is reclassified from customise to configure, with a short training note for the sales team.

The same workshops reveal that the wholesaler offers a consignment stock arrangement to its largest customers, which accounts for a significant share of revenue. The standard software handles consignment differently from the way the contracts are written. Here the business decides that a modest extension is justified, because the process protects important revenue and changing the contracts would take longer than the project. The decision, the reasoning and the estimated cost go into the log, approved by the commercial director.

Two gaps, two different outcomes, and both decisions are now visible and defensible. That is what good fit-gap looks like in practice.

Step four: agree the decisions in writing

Record who accepted each gap and why, so later debates start from facts. Months into a project, people forget why a decision was made, and the same arguments resurface. A clear decision log ends those debates quickly and protects the project from scope creep.

• Gap reference, process and short description.
• Classification and the chosen resolution.
• Estimated effort and cost, where relevant.
• The business owner who approved the decision, and the date.
• The reasoning, in a sentence or two, including any alternatives considered.

Review the log with the steering group, especially the customisations and the items left out. Senior sponsors should see the total customisation effort and confirm they are comfortable with it, because it shapes both budget and long-term cost.

Common mistakes

• Treating fit-gap as a requirements wish list rather than a decision process.
• Running workshops with managers only, so practical details are missed until testing.
• Accepting customisation requests without estimating their lifetime cost.
• Covering every process lightly instead of the critical ones in depth.
• Failing to record decisions, so they are reopened again and again.

Plan fit-gap as a distinct phase with protected time from process owners and the people who do the work. Rank your processes, prepare real scenarios, classify every gap consistently and keep a signed decision log. It is the phase most likely to keep the rest of the project on time and on budget.

Source: Intelliversal analysis.

Frequently asked questions

How long should fit-gap analysis take?

It depends on scope, but for a mid-sized ERP project covering finance, supply chain and sales, several weeks of structured workshops is typical. Rushing it to save time usually costs more time later.

Can fit-gap be done before selecting software?

A lighter version, using scripted demonstrations against your key scenarios, is a good way to compare vendors. The detailed fit-gap then happens with the chosen product during design.

Who should attend fit-gap workshops?

Process owners who can make decisions, experienced staff who do the work and solution consultants who know the software. A facilitator who keeps the session focused on decisions is also valuable.

Explore Enterprise software implementation