Skip to content
Product2 min read

Discovery That Survives Contact With Production

Most enterprise software development overruns are scoping failures wearing an engineering costume. The five artefacts we insist on before a delivery team commits to a date.

Sarah Whitfield

VP, Delivery

Stakeholders reviewing delivery plans during discovery for an enterprise software development programme

When a programme is six months late, the retrospective usually blames engineering estimates. In our experience the estimates were reasonable for the system that was described. The problem is that the described system and the real one diverged in five specific, predictable places.

The five artefacts

1. A written list of the integrations that are not optional

Not "integrates with the ERP" but the named endpoints, their owners, their rate limits, their authentication model, and whether a sandbox exists. An integration with no sandbox is a four-week risk pretending to be a two-day task.

2. Real data, not a schema

An export of a thousand real records - sanitised if necessary - reveals in an afternoon what six weeks of workshops will not: the free-text field that encodes three different business rules, the nullable column that is null forty percent of the time, the dates stored in two formats.

3. Named decision-makers per domain

Every ambiguous requirement eventually needs one person to say which way it goes. If that person is unnamed at the start, the question sits in a backlog for a fortnight. We ask for names, and we ask what happens when they are on holiday.

4. The non-functional requirements, written as numbers

Concurrent users at peak, acceptable p95 latency, data residency constraints, retention periods, recovery time objective. "It should be fast and secure" is not a requirement, it is an aspiration. Numbers change architecture; adjectives do not.

5. A walking skeleton in week two

One thin slice through every layer - authentication, a real integration call, a database write, a deployment to a real environment - shipped in the first fortnight. It converts the riskiest assumptions from discussion into evidence while there is still time to act on them.

  • Discovery output is a plan with named risks, not a specification document.

  • Anything that cannot be evidenced in two weeks gets an explicit assumption and a cost if it is wrong.

  • The estimate has a range, and the range narrows on a published schedule.

  • Scope is traded, never silently absorbed.

A fixed scope, a fixed date and a fixed budget is three constraints for two degrees of freedom. Somebody is going to be disappointed; better to choose who, in advance, in writing.

Why this is cheaper than it looks

A three-week discovery on a nine-month programme is four percent of the budget. The overruns it prevents routinely run to thirty percent. We have not regretted a discovery yet. The one we agreed to shorten, because a stakeholder wanted to see code sooner, is the one we would take back.

Share

Working on something like this?

We embed dedicated dev teams and senior architects into enterprise programmes: AI & cloud solutions, legacy modernization and full-stack web engineering.