The purchase is a constraint; the analysis is not cancelled
The reflex a weak candidate shows here is to explain that requirements should have preceded
selection. It is true, it is useless, and it reads as someone who has not worked on a package
implementation. Money has been committed, a board paper exists, and somebody's judgement is
attached to the choice. You will not unwind that with a process argument, and trying makes you the
obstacle rather than the analyst.
What does change is the purpose of the requirements. They are no longer a specification of what to
build. They are the yardstick that tells the programme where this product fits, where it needs
configuring, where the business will have to work differently, and where there is a shortfall
somebody must knowingly accept. That is fit-gap analysis, and it requires exactly the same
elicitation you would have done anyway.
Ask why the product was chosen before you assume it was chosen badly. Often the answer is a real
constraint you must respect: a group-wide mandate from a parent company, an existing enterprise
licence that makes marginal cost near zero, a regulator's preference, or a two-year support cliff
on the incumbent. A decision that looks arbitrary from the delivery seat is frequently rational
from the seat that made it, and knowing which you have shapes everything you do next.
Elicit the need without describing the product
The trap specific to package work is writing requirements out of the product's own manual. It
happens gradually and it feels efficient: the demo showed a screen, so the requirement describes
that screen. The result is a specification that cannot fail, tells nobody anything, and leaves you
with no way to argue for a change or to measure whether the investment worked.
Guard against it by capturing needs in the business's language and at the level of outcomes and
rules, in the same form you would if no product existed. What decision does this person make, on
what information, how often, within what deadline? What are the statutory obligations and the
audit trail requirements? What volumes at peak? Which rules genuinely vary by region and which are
uniform? Only after that list exists do you place the product against it, because the value of the
list is that it is independent of the product.
The fit-gap, with money attached to each option
Present the result as a table the sponsor can act on, one row per capability, with the closure
option and its cost. The rating is not the point; the option is.
| Need | Fit | Closure option | Cost and risk |
|---|
| Two-stage approval above the delegated limit | Configure | Standard approval matrix, one day of configuration | Low |
| Retain the seven-year audit trail of rule changes | Partial | Product logs changes but purges after 24 months, so add an export to the archive | Small build, plus an ongoing job to monitor |
| Statutory quarterly return in the regulator's format | Gap | No product support. Either an extract into the existing return tool or a bespoke report | Must be resolved before go-live, owner is Compliance |
| Branch staff record a case in under three minutes | Gap | Product needs eleven fields where the current screen needs six | Process change and training, or paid customisation at risk to upgrades |
| Nightly interface to the core ledger | Fit | Standard connector | Low, subject to a proving run on real volumes |
Two habits make this credible. Give process change its proper standing as a closure option rather
than treating customisation as the default — changing how the business works is usually cheaper to
own than modifying a package you then have to re-test at every upgrade, but it is not free, and its
cost is change management and time from people who have day jobs. And write the vendor's roadmap
promises as gaps, not fits, until they are contractual. A capability due next year is a risk with a
mitigation, and recording it as anything else is how programmes discover in month nine that they
have designed around a feature that slipped.
Sort the fatal from the merely awkward
Most gaps are irritations that a competent implementation absorbs. Usually one or two are
different in kind, and finding those early is the whole of your value on this project. They tend
to be statutory or regulatory obligations the product structurally cannot meet, and volume or
integration constraints that only appear when you test the real numbers rather than the demo data.
Raise those two categories while there is still leverage — before the implementation partner's
statement of work is signed, while phase two scope and licence tiers are still being negotiated,
and while the vendor still wants the reference. Six weeks in, a fatal gap is a commercial
conversation with options. Six weeks before go-live, it is a crisis with none.
Frame it as risk with a recommendation and never as vindication. "The product cannot produce the
Q3 regulatory return in the required format. Three options, with costs, are attached; my
recommendation is the second, and I need a decision by the 14th to hold the September date."
Nothing in that sentence relitigates the purchase, and it is far more likely to get the outcome
you want than the version that does.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).