Over the past year, I've written about enterprise delivery from several angles. Why projects fail. Why the waterfall-versus-agile debate misses the point. Why risk needs to surface weekly. Why clients need to see working software every two weeks. Each of those posts described a piece. This one describes the whole. We call it Vision, Roadmap, Execution. It's how we deliver at RIVER, and it's the philosophy that's produced a 100% delivery record across more than a hundred projects.
The Problem It Solves
Enterprise delivery fails in predictable ways. We've been writing about them all year. But the root cause underneath every failure pattern is the same: the project lost alignment between where it was going, how it was getting there, and what it was building right now.
The team is building, but nobody remembers why. The roadmap exists, but nobody updates it. The vision was agreed at kickoff, but the project has drifted so far that the original destination is irrelevant. When any one of the three layers - vision, roadmap, execution - disconnects from the other two, the project starts failing. Sometimes slowly. Sometimes all at once.
Vision, Roadmap, Execution is a framework for keeping all three layers aligned, continuously, from kickoff to delivery.
Vision: Know the Destination
Before a line of code is written, the project needs a clear answer to four questions:
What does success look like? Not in technical terms. In business terms. What changes for the organisation when this project is done? What can people do that they couldn't do before?
Who is this for? Not the steering committee. The actual users. Who are they? What does their day look like? What are they trying to accomplish? What frustrates them about the current situation?
What are the boundaries? What's in scope and what's not? Where does this project end and the next one begin? What's a phase-two conversation?
How will we know we've succeeded? Measurable criteria. Not "the system works" but "the processing time drops from eight hours to thirty minutes" or "user adoption reaches 80% within three months of launch."
This isn't a 200-page requirements document. It's a shared understanding. Usually 10-15 pages. Enough to align everyone. Short enough that everyone actually reads it.
If you can't explain the project's purpose in two sentences that a non-technical person understands, you haven't finished the vision phase.
Isaac Rolfe
Managing Director
The vision phase is where we invest the most time relative to other shops. Most agencies rush through discovery because the client is impatient to see progress. We push back on that. The single biggest predictor of project success we've seen is the quality of the vision alignment. Get it right, and the rest flows. Get it wrong, and no amount of agile ceremonies will save you.
Roadmap: Map the Route
With the destination clear, we map the route. The roadmap translates the vision into a phased delivery plan with clear milestones, dependencies, and decision points.
Phases, not sprints. We plan in phases of 4-8 weeks. Each phase has a clear objective, a defined scope, and a demonstrable outcome. This is longer than a sprint but shorter than a traditional project phase. It gives us enough time to build something meaningful and enough checkpoints to course-correct.
Decision points, not gates. At the end of each phase, we review with the client. Not a formal gate review with a 30-page pack. A working session. Here's what we built. Here's what we learned. Here's what we recommend for the next phase. Adjust the roadmap if needed. Move on.
Dependencies mapped early. Integration dependencies, data migration needs, organisational change requirements, third-party timelines. These get identified upfront and tracked as actively as the build itself. More projects fail because of unmanaged dependencies than because of poor code.
Flexibility built in. The roadmap is a plan, not a contract. When new information arrives (and it always does), we assess it against the vision, adjust the roadmap, and keep building. The vision is fixed. The roadmap is adaptive.
Execution: Build in Stages With Constant Feedback
Execution is where the work happens. And it's where most enterprise projects go wrong, because they stop paying attention to the vision and roadmap once the building starts.
Working Software Every Two Weeks
I've written about this before and I'll keep writing about it. The client sees working software every two weeks. Not wireframes. Not decks. Working software they can click on, test, and give feedback on. This is the single most important execution practice we have.
Risk Surfaced Weekly
Risk doesn't wait for steering committees. We surface it weekly, in plain language, with the client. What are we worried about? What changed? What decisions do we need? This keeps surprises to a minimum and trust to a maximum.
Design and Engineering Together
Designers and developers work side by side from day one. The designer understands the architecture. The developer understands the design intent. Decisions are made together. There are no handoffs, no "that's not what I designed" moments, no late-stage discoveries that something is technically infeasible.
Continuous Quality
Quality isn't a phase at the end. Automated testing runs with every build. Code review is mandatory. Accessibility is checked continuously, not audited once. Performance is measured every sprint. By the time we reach the end of a phase, the software is production-ready, not "done but needs testing."
How the Three Layers Stay Connected
The magic (if there is any) is in how the three layers feed each other.
Execution informs the roadmap. What we learn during building - user feedback, technical discoveries, performance data - feeds back into the roadmap. If something takes longer than expected, the roadmap adjusts. If user feedback suggests a different priority, the roadmap adjusts.
The roadmap validates the vision. As we deliver phases, we check whether we're still heading toward the vision. If the vision was "reduce processing time by 90%," and after two phases we've only achieved 30%, we need to either adjust the approach or revise the vision.
The vision filters the noise. When stakeholders request new features, when scope creep threatens, when a shiny new technology tempts the team, the vision is the filter. Does this serve the destination? Yes? It goes on the roadmap. No? It goes on the "later" list.
The Three Disciplines
- Vision requires strategic discipline. The ability to define a destination clearly and resist the urge to start building before you know where you're going.
- Roadmap requires planning discipline. The ability to sequence work logically while remaining flexible enough to absorb change.
- Execution requires delivery discipline. The ability to build quality software iteratively, with constant feedback and continuous improvement.
Most teams are strong in one. Good teams are strong in two. The teams that deliver consistently are strong in all three.
Why This Works
It works because it takes the best of waterfall (strategic clarity, defined destination, upfront planning) and the best of agile (iterative delivery, feedback loops, adaptability) without the baggage of either.
It works because it keeps the client involved throughout, not just at kickoff and UAT. The client isn't a spectator. They're a participant.
It works because it treats risk as a continuous conversation, not a periodic review.
And it works because it's simple. Three words. Three layers. Three disciplines. Easy to explain. Easy to follow. Hard to do well, but clear about what "well" looks like.
This is the last post in our 2018 series on enterprise delivery. Over the past year, we've laid out the philosophy, the practices, and the principles that drive how we work at RIVER. Next year, we'll put them to use. The projects are getting bigger, the stakes are getting higher, and the approach has never been clearer.