Last year I wrote about Vision, Roadmap, Execution. It's how we deliver at RIVER. But plenty of people asked a fair question: how does the vision actually get built? What happens in the first two weeks? This is the answer. Discovery is the single most important phase of any enterprise project, and most teams either skip it or overdo it. We've found the middle ground.
What You Need to Know
- Discovery at RIVER is a focused 2-4 week sprint, not a three-month requirements gathering exercise
- It covers four areas: stakeholder alignment, user research, technical feasibility, and prioritised scope
- The output is a shared understanding and a scoped plan, not a 200-page specification
- Discovery done properly is the single biggest predictor of project success
The Problem with Skipping Discovery
We've been brought in to rescue projects that skipped discovery. The pattern is always the same. Someone had a clear picture in their head, assumed everyone else had the same picture, and started building. Three months in, the steering committee sees the first demo and says "that's not what we asked for."
It was what they asked for. It just wasn't what they meant. The gap between those two things is exactly what discovery closes.
39%
of enterprise projects cite poor requirements as a primary failure factor
Source: PMI Pulse of the Profession, 2018
That stat doesn't surprise anyone who's worked in enterprise delivery. But here's the thing: the answer isn't more requirements. It's better understanding. There's a difference.
The Four Pillars
Stakeholder Alignment
Every project has multiple stakeholders with different priorities. The CFO cares about cost. The operations manager cares about workflow efficiency. The IT director cares about integration and maintainability. End users care about whether the thing makes their day easier or harder.
Discovery puts all these perspectives in the same room. Not to reach consensus on everything. That's unrealistic and unnecessary. But to surface the tensions early, make explicit trade-offs, and agree on what success looks like.
We run facilitated workshops. Usually two or three sessions over the first week. We ask direct questions. What's the problem? Who feels it most? What happens if we don't solve it? What does success look like in twelve months? The answers are often surprising, even to people who've worked together for years.
User Research
You can't build for users you haven't spoken to. This sounds obvious. In practice, most enterprise projects rely entirely on requirements written by someone three levels above the actual users.
During discovery, we talk to the people who'll use the system every day. We watch them work. We ask what frustrates them about the current process. We ask what they'd change. We look for the workarounds, because workarounds tell you where the real problems are.
This doesn't need to be a six-week ethnographic study. Four or five conversations with real users, combined with observation of the current workflow, gives us enough to design with confidence.
The most valuable thing we learn in discovery is almost never in the original brief. It's in the workaround someone built in a spreadsheet because the system couldn't do what they needed.
Isaac Rolfe
Managing Director
Technical Feasibility
Plenty of discovery processes focus entirely on business requirements and leave the technical assessment for later. We don't. Technical feasibility is assessed during discovery, not after.
Can the existing systems support the integration requirements? What are the data quality issues? Are there performance constraints? Security requirements? Infrastructure limitations?
John Li leads our technical assessments. He looks at the systems that already exist, evaluates what can be reused, and identifies the technical risks before the first line of code is written. This saves weeks of rework later.
Prioritised Scope
Discovery ends with a prioritised scope. Not "everything the client wants." Everything the client wants, ranked by impact and sequenced into phases.
This is where Vision, Roadmap, Execution comes to life. The vision is clear. The roadmap has phases. Each phase has a defined scope and a measurable outcome. The client knows what they're getting first, what comes next, and why.
What Discovery Isn't
It isn't a sales exercise. We've seen agencies use "discovery" as an excuse to bill for pre-sales work. If the primary output is a proposal rather than a shared understanding, that's not discovery. That's scoping dressed up.
It isn't analysis paralysis. Two to four weeks. That's the window. If discovery takes three months, you've turned it into waterfall requirements gathering. The point is to learn enough to start building with confidence, not to document every edge case before writing a line of code.
It isn't optional for complex projects. Some teams think they can skip discovery because the brief is clear. The brief is never as clear as it seems. Every project we've started without proper discovery has cost more and taken longer than it should have.
The Output
A discovery sprint at RIVER produces three things:
A vision document. Ten to fifteen pages. The problem, the users, the success criteria, the constraints. Short enough that everyone reads it. Clear enough that a new team member could understand the project in thirty minutes.
A phased roadmap. What gets built first and why. Dependencies mapped. Risks identified. Decision points flagged. Usually three to four phases covering six to twelve months.
An honest estimate. Not a fixed-price quote. A realistic assessment of what each phase will cost, what the risks are, and where the unknowns live. We'd rather be honest upfront than optimistic now and apologetic later.
Why We Invest So Heavily
Discovery represents roughly 10-15% of a typical project budget at RIVER. Some clients balk at that. They want to start building. We understand the impatience. But the numbers back us up.
Projects that start with proper discovery at RIVER have a 100% delivery record. That's not a marketing line. It's the actual data from over a hundred projects. The ones we've seen fail, including projects we didn't run, almost always trace the failure back to the first few weeks: misaligned expectations, unidentified technical constraints, or scope that wasn't prioritised.
Discovery done right doesn't slow the project down. It removes the obstacles that would have slowed it down later.