The sponsor has already bought the software and wants you to write the requirements for it. How do you approach that?

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.