Why a discovery is more important than development itself
Written by Villiers Vision Works.
Tell us what you need
A discovery is the work of understanding a problem before anyone commits to building. The research supports a narrower point than the title. Deciding what to build comes first, and that decision sets the value of everything built after it. A discovery should be sized to the problem, in any custom business software development process.
In short: Getting the what right comes before building, because it sets the value of what follows. The research does not rank discovery above development.
What a discovery is
A discovery is the work of understanding a problem before anyone commits to building. GOV.UK's service manual says to understand the problem before committing to build, and not to start building during discovery. It also says stopping at the end of a discovery is not a failure, because it saves time and money that can be spent elsewhere when the research points that way. That is government guidance, not guidance written for small businesses. The plain idea is still worth borrowing: look first, then decide.
What the research supports
Deciding what to build comes first, and it sets the value of everything built after it. Even a well-built system is worth little if it solves the wrong problem. That is as far as the research goes. The research does not show that discovery matters more than building. A well-chosen system built badly is also a poor result. The service manual sets no fixed length for a discovery. It says the purpose should decide, and that a problem you already know well may need a shorter one. A discovery is sized to the problem.
What late fixes cost
Fixing a problem late costs more, but the popular number misleads. Boehm and Basili wrote in 2001 that fixing a problem after delivery is often 100 times more expensive than fixing it during requirements and design. They wrote often, not always. They also wrote that for small, noncritical systems the factor is more like 5:1 than 100:1. The flat version, always 100 times, drops both points.
A second finding comes from practitioners. In May 2014 the Project Management Institute surveyed 2,066 project and program managers and business analysts. Where projects missed their original goals and business objectives, inaccurate requirements management was the primary cause almost half of the time (47 percent).
Both findings concern fixing defects and managing requirements across whole projects. Neither measures the value of a discovery itself.
What two published case studies describe
VVW's website publishes case studies about its own work. They are the business's own statements, not independent proof. Two of them describe a step of looking first.
The Optivest MedXpert price calculator page lists a requirements discovery step in its published process. That step defined the pricing logic, the API endpoints and the token-based security.
The Datafeedr API customisation page describes a phase of investigation. It says the plugin's source and update logic were inspected to find the hook that cleared the manually set product categories.
What a discovery should leave you with
A discovery should leave you with the problem in plain words and a clear line around what is and is not part of it. It should name the things that limit the job, such as existing systems and the way people work today. It should list the decisions only you can make. And it should end with a choice: go ahead, go ahead smaller, or stop. GOV.UK's guidance says a discovery is finished when you have decided whether to move on.
What to be ready to answer
Be ready to say what is not working, who it affects and what people do today instead. Be ready to say how standard the job is, how much the business must change to fit the software, and who will look after it later. Those answers decide how much discovery the job needs.
A useful discovery leaves you with something you can read, question and take elsewhere. It can end in a no. It does not start building. Before you agree to one, ask what you will have in hand at the end, and whether stopping is a possible outcome.
Tell us what you need.