Pricing
Log inBook a demo

Buyer guide

Requirements that survive configuration

Unsettled requirements were the primary cause in 31% of the stalled implementations we have been called into — more than any other factor, and roughly eight times more often than the software being genuinely incapable. This is how to avoid being in that 31%.

Score your project riskGet a free assessment

Want help building these?

Tell us where you are in the process. Our selection advisory derives requirements from your transactions.

1 / 3
31% of stalls start hereDerive from transactionsExclusions are the deliverable
The methodThe checklistWeightingQuestions

Buyer guide

Six rules for building requirements.

The failure is rarely that nobody wrote requirements. It is that they were written from interviews and did not survive contact with the data.

Derive from transactions

What people say they do and what their data shows they do diverge more than anyone expects. Pull a quarter of transactions and check every stated requirement against them.

Separate must from want, honestly

A must-have is something that, if absent, means you would not buy. Most requirements lists have thirty must-haves and about six are real.

Write down the exclusions

What you are explicitly not solving in this project. This is the section that prevents scope creep and the one most requirements documents omit entirely.

Name the decision-maker per area

Not a committee. One person who can decide on approvals, one on the chart of accounts, one on close process, each able to decide within a day.

Timebox the phase

Requirements work expands to fill available time. Two to three weeks, with a hard stop and a written sign-off, produces better results than three months of refinement.

Include the edge cases you know about

The customer who pays eleven invoices with one short wire. The intercompany arrangement nobody documented. These are what break configurations, and they are knowable now.

The checklist

Work through these against your actual data rather than from memory.

Structure

  • How many legal entities, and which consolidate together?
  • How many currencies, and does any entity have a functional currency different from the group?
  • What dimensions do you need to report on — department, location, project, product, customer cohort? Count them, then check whether your current system supports that many.
  • Is there intercompany activity, and can you currently state its volume?

Volume

  • Transactions per month by type: vendor bills, customer invoices, bank lines, journal entries, expense claims.
  • Users who touch the system, split by heavy and occasional. This determines whether per-seat or resource pricing favours you.
  • Peak versus average, and when peaks occur.

Process

  • How long does the close take, and which two or three steps are on the critical path? Time it rather than estimating.
  • What approval thresholds exist, and what proportion of transactions require an approval that has never once been refused?
  • Which processes are currently a spreadsheet, and who maintains each one?

Data condition

  • Duplicate rate in customers and vendors. Measure it — the median we find is 8.4% and almost everyone believes theirs is lower.
  • Proportion of historical transactions carrying dimension data. Median is 78%, concentrated badly in older periods.
  • Balance sheet accounts with no reconciliation in the last twelve months. 64% of companies have at least one.
  • Any closed period that does not balance. 31% of companies have one.

Constraints

  • Regulatory or statutory filing obligations, by jurisdiction.
  • Audit requirements and who your auditors are.
  • Systems that cannot change, and why.
  • Dates that cannot move — a year end, a covenant test, a transaction.

Weight before you score

Agree the weighting of your criteria before any vendor is evaluated, and write it down. Weights set after the demos are weights chosen to justify a preference that has already formed.

Our own published weighting is functional fit 30%, total cost 20%, time to value 15%, implementation risk 15%, extensibility 10%, and support and ecosystem 10%. You should adjust those — they encode our view that implementation risk is underweighted and that total cost is systematically understated in proposals. If you disagree, change them, but change them first.

Weights chosen after the demos are weights chosen to justify a decision somebody already made.

What to do with the finished list

Get to three products, not ten. Three is the number at which scenario demos are affordable and references can actually be called. A shortlist of ten produces a decision made on demo quality rather than fit.

Then write scenarios from your own transactions — including the edge cases — and send them to each candidate in advance. The vendors who prepare properly and the ones who deflect become obvious within twenty minutes, and that is informative about the implementation ahead.

The most common mistake

Building a requirements list from a template found online, then validating it in interviews. That produces a document that describes what a generic company needs and what your team believes it does — and the configuration phase then discovers, one surprise at a time, that neither matches your transactions. By the fourth or fifth surprise the schedule has absorbed all its slack.

Questions

Common follow-ups.

How long should requirements take?
Two to three weeks with a hard stop. The work expands to fill available time, and three months of refinement does not produce better outcomes than three weeks with a sign-off.
Why derive from transactions?
Because what people say they do and what their data shows they do diverge. That divergence surfaces during configuration as surprises that each reopen a settled decision.
How many must-haves should we have?
Fewer than you think. A must-have is something that, if absent, means you would not buy. Most lists have thirty and about six survive that test.
Should we use a template?
As a prompt, not as a document. A template describes what a generic company needs, which is why template-derived requirements fail during configuration.
Who should sign off?
One named person per area who can decide within a day. A committee that escalates is the failure mode behind 19% of stalled projects.

Check every requirement against the data.

Thirty-one percent of stalled projects failed here, and it is the cheapest phase to get right.

Score your project riskRead the failure research