Fit-Gap Is a Business Decision Process, Not a Customization List
Fit-gap analysis tests business requirements against the target solution and operating model. Its purpose is to determine the most appropriate response to each need.
A weak fit-gap exercise labels anything unfamiliar as a gap. A strong one compares standard capability, configuration, process change, extension, integration and deferral before committing to custom development.
15.1 Define Fit and Gap Categories
Agree categories before analysis begins: standard fit, configuration fit, process change, extension, integration, reporting solution, workaround, deferred requirement or true gap.
Consistent categories make portfolio-level review possible and reduce subjective decisions.
15.2 Evaluate Standard Capability First
Demonstrate how the platform works against the actual requirement and scenario. Do not assess fit from feature names alone.
A standard fit may still require changed roles or process. Capture that organizational impact rather than calling the requirement unsupported.
15.3 Assess Business Criticality
Understand the consequence if the requirement is not met. Regulatory, financial-control and contractual requirements deserve different treatment from convenience requests.
Priority should influence the depth of solution options considered.
15.4 Estimate Total Impact, Not Build Effort Alone
Customization adds design, development, testing, documentation, deployment, upgrade and support cost.
Consider lifecycle cost, support ownership, performance, security and future product evolution before choosing an extension.
15.5 Challenge Process Change Fairly
Process change can be the right answer when legacy practice adds little value. It can also be inappropriate when the current step exists for compliance or competitive differentiation.
Document the rationale so future teams understand why the project chose standardization or deviation.
15.6 Govern Gaps Through Design Authority
Material gaps should be reviewed by the appropriate business and technical decision-makers. The decision should include requirement, options, impacts and recommendation.
Avoid allowing individual consultants or developers to create architectural commitments through local decisions.
15.7 Maintain a Fit-Gap Register
Track requirement ID, classification, standard capability, proposed response, impact, owner, decision and downstream design reference.
The register becomes a key bridge from discovery to backlog and design.
15.8 Revisit Fit-Gap as Evidence Changes
Some apparent gaps disappear during prototyping; others become more significant after integration or volume testing. Treat fit-gap as controlled analysis, not a one-day workshop artifact.
From the Delivery Floor
A business requested twelve custom fields and a new workflow to reproduce an old order-approval process. Fit-gap review showed that eight fields were duplicates of standard data, two were reporting-only needs and the workflow could be achieved through configuration after simplifying the approval policy.
Only two genuine gaps remained for design. The project reduced both delivery effort and long-term support complexity.
15.9 The Delivery Leader's View
The delivery leader should watch the gap count and, more importantly, the quality of gap decisions. A high number of customizations may indicate either unusual business needs or weak fit-to-standard discipline.
Require total-lifecycle reasoning for important deviations from standard capability.
Chapter 15 Implementation Checklist
- Are fit-gap categories agreed?
- Has standard capability been demonstrated against real scenarios?
- Is business criticality understood?
- Are process-change options considered?
- Are lifecycle costs included in customization decisions?
- Are security, performance and upgrade impacts assessed?
- Are material gaps governed by design authority?
- Is a fit-gap register maintained?
- Do decisions trace back to requirements?
- Are gaps revisited as prototypes and tests provide evidence?
Key Takeaways
Fit-gap is about choosing the right response to a requirement.
Standard fit may still require business change.
A gap should not automatically become custom development.
Evaluate lifecycle impact, not only initial build effort.
Govern important gaps through transparent design decisions.
Closing Thought
The strongest fit-gap decision is the one the organization can still defend years later—after upgrades, support handoffs and new business demands have arrived.