Most software budgets do not blow up because a developer wrote bad code. They blow up because nobody agreed, in writing, what the software was meant to do before anyone started building it. By the time that gap surfaces, usually somewhere around the third sprint, it is expensive to close.

Key Takeaways

  • A discovery workshop is a structured session held before development starts, where stakeholders, users and the delivery team agree scope, priorities and constraints in writing.
  • Inaccurate or incomplete requirements are the most commonly cited reason software projects overrun, ahead of budget and scheduling errors.
  • Scope creep affects a majority of IT projects, and its cost rises the later in a project it is discovered.
  • UK government digital teams treat discovery as a mandatory phase before any public service is built, precisely because it catches wrong assumptions early.
  • A good discovery workshop produces a written brief, not just a meeting summary, so decisions survive staff turnover and changing priorities.

This matters more for business software than almost any other category of spend, because the people commissioning it are rarely the people who will use it every day. A discovery workshop exists to close that distance before it becomes a change request.

What actually happens in a discovery workshop

A discovery workshop is not a kickoff call. It is a working session, typically half a day to a few days depending on complexity, where the delivery team sits down with the people who will use the software and the people paying for it, and forces answers to questions that are usually assumed rather than asked. Who actually uses this daily. What do they currently do instead. What happens if the software is wrong. Which constraints are fixed, such as a regulatory deadline or an existing system it must integrate with, and which are negotiable.

The output is not a slide deck. It should be a written brief covering scope, priority order, technical constraints and open risks, something the whole team can point back to when a stakeholder asks for “just one more thing” three months in. The UK government’s own service standard, first published in 2016, treats this as a mandatory phase before any public digital service is built, not an optional nicety, and describes it as the stage where teams work out whether they even understand the problem correctly before committing to build anything.

A man in a suit pointing at a whiteboard while a colleague looks on with notes in hand

The cost of skipping it

The reason this stage gets skipped is that it feels like delay. A client wants to see progress, and a workshop produces documents rather than a working screen. But the alternative cost is well documented. In a 2007 piece, the British Computer Society pointed to poor requirements management as one of the recurring reasons software projects fail, a finding that has aged remarkably well given how often the same root cause still turns up in post-mortems today.

A discovery workshop is cheaper than the change request it prevents, because the change request always arrives after work has already been built around the wrong assumption.

Scope creep is the practical symptom of skipped discovery. The National Audit Office’s 2017 report on digital transformation in government found that a majority of the programmes it reviewed experienced exactly this pattern, and the mechanism is consistent: requirements that were never pinned down at the start keep expanding as stakeholders notice gaps once they see something real. Each addition after development starts costs more than the same decision made on a whiteboard, because code, tests and documentation already assume the earlier answer.

Close-up of a hand writing notes into a ruled notebook at a desk

Running one well

A discovery workshop only works if it includes people who actually use the software, not only the executives who commissioned it. Their day-to-day workarounds tell you more about real requirements than a stated business objective does. It also needs someone willing to say no to a feature that sounds useful but does not serve the core problem, since discovery is as much about deciding what not to build as what to build.

Facilitation matters as much as attendance. A workshop that lets the loudest stakeholder set the agenda produces a brief that reflects office politics rather than user need. Agile Alliance’s own glossary frames discovery as the stage where a team builds a shared understanding of the problem before committing to a solution, which only happens if every voice in the room, including the quietest one, gets asked directly rather than assumed to agree. That means the facilitator’s job is partly technical and partly social: keeping the session anchored to evidence about how the software will actually be used, rather than letting it drift into a debate about internal politics that has little bearing on the product itself.

Four colleagues around a boardroom table taking notes during a client meeting

Development partners who run discovery properly treat it as diagnostic, not a sales step before the “real” work begins. Arch runs discovery workshops as the first stage of every build it takes on, precisely because a project scoped against a written brief has something concrete to be held against later, rather than a shifting memory of a kickoff call. That habit shows up in delivery work such as its NHS-facing Radarr Medical platform, where the requirements had to be right before a single screen was built, since a radiology communications tool has no room for a rework cycle once clinicians are relying on it.

None of this requires an enterprise budget to justify. A discovery workshop scales to the size of the project: a small internal tool might need half a day with three people in a room, while a platform spanning several departments justifies a longer, staged process. What stays constant is the discipline of writing the answers down before anyone opens an IDE.

Frequently Asked Questions

How long should a discovery workshop take?

It depends on the size of the project, but most run from half a day to a few days. A small internal tool might need a single focused session, while a multi-system platform with several stakeholder groups can justify a few days spread over a week so nobody is rushed into agreeing something they have not thought through.

Who needs to be in the room?

Anyone who will actually use the software daily, whoever holds budget authority, and at least one person who understands existing technical constraints such as legacy systems or compliance requirements. Leaving out day-to-day users is the most common mistake, because their workarounds reveal requirements nobody thought to state.

Does a discovery workshop replace a formal specification?

No, it feeds one. The workshop surfaces the decisions; a written brief then documents them so the team has something durable to refer back to once development starts and memories of the original conversation start to blur.

What should come out of the workshop besides notes?

A written brief covering agreed scope, priority order, known constraints and open risks. If the only output is a meeting summary emailed round afterwards, the workshop has not done its job, because nothing in it can be pointed to later when scope starts to drift.

What happens if stakeholders disagree during the workshop?

Disagreement surfacing in the room is the workshop working as intended, not a sign it has failed. It is far cheaper to resolve a conflict over priorities on a whiteboard, with a facilitator forcing a decision, than to discover mid-build that two stakeholders assumed opposite answers to the same question.

Sources