Guide

What happens in a discovery workshop, and why it can save you money.

A discovery workshop, sometimes called scoping, is a short, paid phase before the build in which you and the development team agree what to make, in what order and what could go wrong. It is the cheapest point in a project at which to discover that something is a bad idea.

Key takeaways

It is a small, fixed-size step, usually days or a couple of weeks, not a mini-project.
You should leave with written outputs: scope, priorities, risks, an estimate range and a plan.
The right people in the room matter more than the length of the agenda.
You can take the results to any supplier. A good workshop does not lock you in.
It is worth it when the project is uncertain, large or involves several departments. Small, clear projects may not need one.

What it is for

Most expensive surprises in software come from questions nobody asked early: who really uses this, what happens when the old system disagrees with the new one, who signs off, what the data looks like in practice. A workshop forces those questions while changing direction is still cheap. It turns an idea into a scope that a team can estimate with fewer assumptions. See our guide to writing a project brief for what to bring.

A typical shape

Before. You share the brief, any existing systems, sample data and documents. The team reads them and prepares questions.
Understand the work. Walk through how things happen today, step by step, including the awkward exceptions. Real examples beat descriptions.
Define the users and the first release. Who does what, and the two or three things that must work on day one.
Map the systems and data. What must connect, what can be imported and what is missing or messy.
Find the risks. Rules and privacy, integrations that may not work as hoped, people who must agree, and anything that depends on an outside party.
Sketch the experience. Rough screens or a clickable prototype of the main journey, to react to rather than imagine.
Plan. Order of work, an estimate range with its assumptions, and the decisions you still need to make.

Some of this happens in meetings and some in the team's own time between them. Remote sessions work well if the right people attend.

Who should be in the room

The decision-maker, or someone who can speak for them.
The people who do the work today, not only managers. They know the exceptions.
Someone who knows your existing systems, whether staff or an outside provider.
A voice for customers, even if only as stories from the front line.

Fewer than six people usually works best. Larger groups can contribute asynchronously.

What you should have at the end

A written scope for the first release, and a list of what is deliberately left for later.
The main user journeys, in plain language and in rough pictures.
A list of risks and open questions, with an owner for each.
An estimate range, with the assumptions behind it, for the build and for running costs afterwards.
A proposed plan with milestones, and what you will need to supply and when.

These belong to you. If a supplier will not let you take them to someone else, ask why before paying for them.

Is it worth paying for?

Usually yes if the project is large, touches several teams or systems, or depends on assumptions you have not tested. A day or two spent finding that a key integration is impossible is far cheaper than finding it in month three. If the project is small and clear, a good proposal and a short call may be enough, and a good supplier will say so. Judge a workshop by whether it changed what you planned to build, by how specific its outputs are and by how much more confident you are in the estimate afterwards.

Frequently asked questions

How long does a discovery workshop take?

From a single day to a few weeks, depending on size. The point is to stay short and focused. If it grows into the project itself, it has stopped being discovery.

Is it free?

Free sessions are really sales conversations. A paid workshop commits the supplier to produce real outputs. Either can be useful, but know which one you are getting.

Can I use the results with another supplier?

You should be able to. Agree this before you start, so the outputs are documents you own, not a hook into a longer contract.

Not sure what a first phase should cover?

Tell us what you are considering. We will say whether a workshop would help or whether you can go straight to a proposal.

Request a project quote