blog single

What a discovery phase should deliver

Published on:

June 13, 2024

TAG:

PROCESS

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

Discovery has a reputation problem. Too often it produces a slide deck that restates the brief, a sitemap nobody uses and a quote that changes the moment work starts. The phase is still valuable, but only when it produces artifacts the delivery team can build from and the client can check.

Discovery is risk reduction

The purpose of discovery is to find the expensive unknowns before they become expensive. Which parts of the process are actually broken. Which integration has no usable API. Which stakeholder has a requirement that conflicts with another. A good phase surfaces those issues while they are still cheap to change.

That framing changes what you keep. A deck is only useful if it records a decision. What matters is the evidence behind the decision, the alternatives that were rejected and the conditions that would change the answer. Everything else is archive material.

The outputs worth paying for

A solid discovery phase produces a small set of documents that stay in use through the build. They are working tools, not presentation material.

A problem statement agreed by the people who own the budget and the process.
A map of the current workflow, including the spreadsheet and inbox where work actually happens.
A prioritized list of user needs with evidence, not assumptions.
A scope with explicit exclusions, so later additions are visible as additions.
A technical assessment of the systems the new work must connect to.
A delivery plan with phases, risks and the decisions each phase depends on.
A measurement plan that names the numbers the project should move.

Workshop notes and process diagrams on a table — The useful outputs are decisions with evidence attached, not a longer brief.

Tell a real discovery from a sales exercise

A sales exercise collects information from you and gives back a proposal. A discovery phase gives back findings you did not have before, including some that make the project smaller. If the output never challenges the original brief, you paid for a proposal with a longer cover.

Ask who does the work. Discovery needs access to the people who run the process, not only the person who hired the agency. It needs time with the support team, the sales team and whoever fixes problems at month end. A phase built only on stakeholder interviews produces a confident document with untested assumptions.

Ask what happens to the artifacts if you stop. Good discovery is valuable on its own. You should be able to take the findings to another team and keep going. If the output only makes sense inside the agency's process, the phase was a lock in device.

Scope the phase to the size of the risk

Not every project needs six weeks. A marketing site refresh may need three days of workshops and a technical review. A replacement for a core operational system needs weeks, because the cost of a wrong assumption is much higher. Scale the phase to the number of unknowns, not to a standard package.

When budget is tight, do a focused version. Pick the riskiest assumption and test it first. If the project depends on an integration, build a small proof against the real API before committing to the roadmap. If the risk is user adoption, run five sessions with the people who will use the system. One tested assumption is worth more than a broad document.

Discovery should make the project smaller or safer. A document that only makes the proposal longer has failed the exercise.
Edgeless Team

Hand off in a form the build team can use

The end of discovery is a handoff, not a presentation. The people who will design and build should have read the findings, met the users and seen the current process. A short working session where the build team challenges the assumptions catches more than a polished readout.

Keep the artifacts in a place everyone can reach and update them when a decision changes. A scope that lives only in a proposal from eight months ago is how projects drift. A living document that records why something changed is how they stay on course.

Who needs to be in the room

Discovery fails when it only hears from the person who signed the contract. That person knows the goal and the budget, but the people who run the process know where it breaks. Include at least one person from each team that touches the workflow, including the team that handles exceptions.

Bring someone from the technical side early. They can tell you which systems have usable interfaces, which data is trustworthy and which assumptions will cost weeks to fix later. A technical assessment done after the scope is agreed becomes a list of change requests.

Decide who can approve a change to the scope. A phase that ends with three possible directions and no decision maker produces a document nobody can build from. Name the approver at the start and make the tradeoffs visible, including the cost of each option.

How long it takes

A focused phase for a marketing site or a workflow tool usually runs two to four weeks. A replacement for a core system with several integrations runs four to eight. The variance comes from access to people and data, not from the size of the final document. If the client cannot free the right people for interviews, the phase stretches regardless of the plan.

Cost scales with the number of unknowns more than with the size of the build. Two days of workshops and a technical review can be enough when the problem is well understood. Spending six weeks to confirm what the team already knows is as wasteful as skipping the phase entirely.

When discovery finds a bigger problem

Sometimes the phase reveals that the proposed build will not solve the real issue. The process may need a policy change, a different team structure or a smaller tool. Say so plainly and show the evidence. A client who learns that before the build starts saves far more than the phase cost.

Sometimes the opposite happens and the first release can be much smaller than planned. That is a good result. A narrow first release that ships and gets used teaches more than a broad one that waits a year. Discovery earns its keep when it makes that narrow scope obvious.

What to bring as the client

The client side of discovery is mostly access. Free the right people for interviews, share the reports that show the problem and give the team a sample of real records rather than a cleaned up export. Real data exposes edge cases that a summary hides, such as empty fields, duplicate entries and notes typed into the wrong column.

Bring the constraints too. Budget, deadlines, procurement rules, existing contracts and any system the business cannot replace this year. Constraints narrow the options to the ones that can actually ship, which makes the phase faster and the plan more honest.

Set aside time for the findings to be reviewed by the people who will live with them. A plan that arrives as a finished document invites objections at the end. A plan shown in draft invites the corrections that make it usable, and those corrections are cheaper to apply before the build starts.

We run discovery phases that end with a scope, a technical assessment and a plan your team can act on, whether or not we build it.

Explore software development

Treat discovery as the first delivery phase rather than a prelude. The team that finds the expensive unknown early is the team that ships on budget. The cost of the phase is small compared with the change order it prevents.

Discovery

Planning

Delivery

What a discovery phase should deliver

Let's Talk About Your Project