Why discovery is the most important phase of any project

Most agencies say they carry out discovery. It appears in the proposal, somewhere between the methodology diagram and the timeline. In practice, however, it is often compressed into a few days of workshops, or omitted entirely because the client already has a specification.

We do not omit it. Every brytloop project begins with a full discovery phase, however clear the brief appears. The duration varies, from a couple of weeks to longer, but the phase always takes place. The reasons are set out below.

The brief is never the full picture

Clients typically come to us with a problem they have been considering for months, sometimes years, and usually with a solution in mind: "we need a new portal", or "we need to replace this spreadsheet with a system". They are often right about what is needed. The reasons behind it, however, including the processes, the workarounds and the stakeholder politics, are where the most valuable insight lies.

During discovery, we speak to the people who will use the system day to day. That means not only the project sponsor, but also the case workers, administrators and team leads who have been filling gaps with email and informal workarounds. This is where the requirements that did not make it into the brief come to light.

What discovery involves

It begins with listening: stakeholder interviews, process mapping and a review of the systems already in place. The aim is to understand how work flows through the organisation in practice, not how it is intended to flow according to the policy document.

The next stage is analysis. We map the data, identify integration points and flag technical constraints. Where a legacy system is involved, as is usually the case, this is when we establish what it does in practice as opposed to what people believe it does.

The final stage is synthesis. We consolidate our findings into concrete outputs: a proposed architecture, a prioritised backlog and a realistic estimate. The client receives a document that supports real decisions, rather than a set of general recommendations.

Why the approach works

Projects that go badly are almost always those in which building started too early. The team committed to a database schema before understanding the data, selected a framework before knowing the constraints, and estimated 12 weeks only to take 30.

Discovery requires time at the outset, but it saves considerably more later. A scope problem identified in the first weeks is inexpensive to resolve; the same problem found months into a build is not. Discovery can also reveal an existing system that already provides much of what was about to be built from scratch.

Discovery is not high-profile work, and a well-conducted stakeholder interview will rarely feature in a case study. It is, however, the difference between a project that delivers and one that overruns.

When there is pressure to move faster

Some clients face tight timelines: budget pressure, a fixed deadline, or a minister who wants a service live by April. These pressures are real. The answer is not to skip discovery but to narrow its scope: focus on the riskiest assumptions, map the main user journey, and identify and test early the issues most likely to derail the project.

The greatest risk is to begin building something that no one fully understands. That is how a team arrives six months into a project with a system that functions technically but does not solve the problem.

A short, focused discovery phase is the most valuable investment a project can make. Every subsequent phase moves faster as a result.