The false comfort of the detailed plan
Digital projects invite premature certainty. Before research begins, a plan may already name every page, feature, integration, and delivery date. The document looks controlled because it is detailed, but detail is not the same as knowledge. Early in a project, the team knows least about user behaviour, technical constraints, content readiness, and organisational dependencies. Treating assumptions as commitments merely delays the moment they become visible.
Planning still matters—arguably more in uncertain work. The useful shift is to plan around decisions and evidence rather than a fixed inventory of outputs. What must be true for the investment to succeed? Which assumptions carry the most risk? What needs to be learned before the team commits to architecture, scope, or launch? This creates a plan that reduces uncertainty instead of disguising it.
Give discovery a job
Discovery should not be a ritualised period of workshops. Its purpose is to determine whether there is a worthwhile problem and a viable direction. GOV.UK’s service guidance recommends understanding users, constraints, the wider journey, opportunities, and measures of success before committing to build. It also makes a liberating point: stopping after discovery can be a successful outcome when evidence shows the work is not worth pursuing.
A useful discovery therefore begins with explicit questions. Which audience has the greatest unmet need? Where does the current journey break? Which policy, process, or technology constraints are genuinely fixed? What would the organisation stop doing if the new service worked? Questions create a boundary. Without one, discovery expands into general learning and produces insight without decision.
Sequence risk before volume
Teams often prioritise work that is easy to see: homepage design, polished interface components, or high-volume content production. The risk may sit elsewhere—in an integration, a permission model, a pricing assumption, an inaccessible interaction, or a proposition customers do not value. Project sequencing should bring the riskiest assumptions forward while change is still inexpensive.
Prototypes are useful precisely because they can answer questions without carrying the cost of production. Different fidelities answer different questions: a conversation and sketch may test comprehension; an interactive prototype may test a journey; a technical spike may test feasibility; a limited release may test real behaviour. The artefact is not progress by itself. Progress is the decision the artefact makes possible.
Make dependencies visible and owned
Most delays are not caused by the work shown on the design or development board. They come from content approvals, data access, procurement, legal review, subject-matter availability, legacy systems, and decisions that lack an owner. A credible plan includes these conditions alongside delivery tasks. Each dependency needs a named owner, a required date, and a visible consequence if it moves.
Decision rights deserve the same attention. Teams lose weeks when feedback arrives from many people but authority belongs to nobody. Agree who recommends, who contributes evidence, and who makes the final call. Then set a review rhythm close enough to the work that decisions can be made while context is fresh. Governance should increase the speed and quality of decisions, not simply increase the number of meetings.
Use the roadmap as a living argument
The GOV.UK guidance on roadmaps describes them as statements of intent that allow for change, with confidence increasing as work moves closer. That is a more honest and useful model than a distant feature calendar. Near-term work can be specific. Later work should express outcomes, questions, or missions until evidence justifies a solution.
A strong project plan tells a coherent story: this is the problem, this is the value of solving it, these are the uncertainties, this is how we will reduce them, and these are the measures that will tell us whether to continue. It creates confidence without claiming omniscience. The plan will change, because learning is the point. What should remain stable is the quality of the decisions used to change it.
Plan the content and data work
Content and data are frequently shown as inputs that will arrive just before launch. In practice, they shape scope and interaction from the beginning. Real content exposes hierarchy, exceptions, regulatory language, translation needs, and gaps in ownership. Realistic data reveals empty states, extreme values, permissions, and quality problems that idealised prototypes hide. Both deserve named workstreams, owners, and acceptance criteria.
Begin a content inventory and data assessment while journeys are still being defined. Decide who can approve changes, migrate records, resolve conflicting sources, and maintain accuracy after release. Use representative material in prototypes early enough to affect the design. This avoids the expensive late discovery that a clean component cannot contain the required explanation or that a critical field is not reliably available. Planning becomes more credible when it accounts for the substance of the experience, not only the containers built to display it.