From Data Strategy to Roadmap: Sequencing Initiatives That Deliver
A roadmap is the strategy with an order, a cost and a calendar attached. Its job is to survive the first budget round, and it does that by showing what depends on what.
A data strategy says what the organisation has chosen. A roadmap says in what order the work will be done, who will do it, with what money, and when anyone will check. The step from one to the other is where a strategy can lose its shape: the agreed priorities become a list of projects, each sponsored by whoever cares most, and the list is cut in the budget round by people who cannot see which items hold up the rest.
This article sets out how to build a roadmap that can be defended and re-planned. It covers the baseline, the ordering of work by dependency, the balance between foundations and visible results, planning in horizons, matching the plan to capacity and money, and the governance needed to change the plan without starting again. It takes as given the choices described in what a data strategy is and the decisions it has to make.
What makes a roadmap more than a list
Three things distinguish a roadmap from a list of initiatives with dates.
It shows order, and the reason for it. If one item can only start when another has finished, the roadmap says so. Without that, removing a foundation looks like a saving.
It is sized to capacity. The work fits the people and money available in each period, with running costs counted alongside the cost of building.
It has review points. A roadmap states when it will be revisited and who has the authority to change it.
The UK government’s roadmap for digital and data, published in 2022, opens with an unusually frank account of what happens otherwise: “Previous strategies have lacked specificity, cross-government endorsement, clear lines of accountability and business ownership”1. Each of the four failings it names is a property of a plan, and each can be designed in.
Establish the baseline before sequencing
A sequence needs a starting point. Work cannot be ordered sensibly until it is known what already exists, what condition it is in and what is under way.
The US Federal Data Strategy’s first action plan made this an explicit instruction. Recognising that agencies “have different levels of maturity in their current management and use of data”, it told each one to “first establish a baseline for each action by assessing the agency’s current status”2. The UK roadmap took the same course on a larger scale. The National Audit Office noted that four of its six missions began with detailed data-gathering from departments, “to provide an in-depth analysis of the scale of the task and the resources required before implementation activities begin”3.
The baseline does not have to be exhaustive. It has to answer three questions for each area the strategy touches: what is in place, what is already funded and in progress, and what is known to be broken. A maturity assessment is one structured way of taking that reading, provided its result is treated as a description of the present and not as a plan.
One caution applies. Baselining can become a way of deferring commitment. Set a date for it at the outset, and plan the first period of delivery in parallel so that the two finish together.
Order the work by dependency
Enthusiasm is a poor basis for sequence. The initiative with the keenest sponsor is not necessarily the one that should go first, and the one nobody champions may be the one everything else waits on.
Dependencies come in four kinds, and it helps to mark each item on the draft roadmap with the ones that apply.
Four kinds of dependency between data initiatives
| Dependency | What it means | Illustration |
|---|---|---|
| Data | One piece of work needs data that another will produce or repair | A retention model needs a single customer identifier across two systems |
| Capability | Work needs a platform, tool or service that does not yet exist | Self-service reporting needs a governed set of shared measures |
| Decision | Work cannot proceed until someone with authority has settled a question | A shared customer record needs an owner before its rules can be agreed |
| People | Two pieces of work need the same scarce skills in the same period | One data engineering team is committed to both a migration and a new feed |
The illustrations are hypothetical. The decision and people dependencies deserve particular care, because neither shows on a technical architecture diagram. A roadmap that sequences only by data and capability will schedule work that then waits months for a ruling or a team.
Where a dependency is on a platform change, the sequencing questions become more specific: what is moved first, how old and new run together, and how results are checked. Planning a data platform migration deals with those.
Once dependencies are marked, the ordering largely follows. Items with nothing upstream can start. Items that many others rely on are foundations and should be protected. Items at the end of long chains should be scheduled honestly, in the period when what they need will be ready.
Balance foundations with visible results
Every roadmap has to hold two things at once. Foundations, such as identifiers, definitions, ownership and core platforms, make later work possible and produce little that an executive will notice. Visible results build the confidence that keeps funding in place and can rest on foundations that are not yet sound.
The US action plan put its first year almost entirely into foundations. It describes itself as establishing “a solid foundation that will support implementation of the strategy over the next decade”, with six agency actions that it calls “foundational steps”2. That was a defensible choice for a ten-year, government-wide programme backed by statute. An organisation whose data budget is reviewed each year has less room.
DII’s working rule is to tie each foundation to a result. A foundation is scheduled in the same period as the first use that depends on it, and is scoped to what that use needs. The identifier is built for the two systems the retention work requires, not for every system in the estate. This gives the foundation a sponsor, a deadline and a test of whether it worked. It also means the foundation grows by use. That can be less efficient than building the whole foundation once, but it gives each increment a funded use, a sponsor and a reason to exist.
The opposite failure deserves equal attention. A roadmap made only of quick results accumulates work that has to be redone. The test for an early result is whether it leaves something reusable behind: a cleaned dataset, an agreed definition, a named owner.
The method for deciding which results matter enough to lead with is set out in how to align a data strategy to business outcomes.
Plan in horizons
A roadmap that claims the same certainty about year three as about next quarter will not be believed. Planning in horizons makes the difference explicit.
The US Federal Data Strategy is a clear public example. The strategy describes “a ten-year vision”; implementation is by annual action plans that “identify priority actions for a given year and incrementally build on progress from year to year”2. The plan for a given year carries milestones, target dates and named reporting mechanisms. The years beyond it carry direction.
DII suggests three horizons.
- Committed. The next two to four quarters. Funded, resourced, owned, with dates and measures. Changes need a formal decision.
- Planned. The following year or so. Sequenced and estimated, with dependencies understood, and not yet funded in detail.
- Intended. Beyond that. The direction of travel and the major capabilities expected, without dates.
The Federal Chief Data Officers Council’s playbook suggests a span of three to five years for the whole4. The span matters less than the discipline of moving work from the third horizon to the first only when its dependencies are met and its funding is real.
Match the plan to capacity and money
The surest way for a roadmap to fail is to assume people and funds that are not there.
Count the people. List the scarce roles, such as data engineers, architects and analysts with domain knowledge, and the number available in each period. Then load the committed horizon against them. If the plan needs twice the engineering capacity that exists, the choice is between hiring, buying or cutting, and it should be made on paper before it is made by default.
Fund the running, not only the building. The National Audit Office recorded what departments told it in 2023: that “it is easier to bid for capital funding for new developments than resource funding to maintain existing services and keep them up to date”3. The same pressure is easy to recognise outside government. A roadmap should show, for each capability, who pays to operate it once the project closes. A platform run as a continuing service needs a continuing team and budget, which is the argument made in running a data platform as a product.
Work with the budget cycle. The playbook advises data leaders to understand the organisation’s budget process, “to ensure that appropriate resources are planned for in future budgets”4. A roadmap whose committed horizon does not line up with the financial year will be funded in fragments.
Expect competition. Even where money has been allocated, it is not safe. The National Audit Office observed of the UK roadmap that there was no additional funding for inflation, so that funding for its missions “will therefore have to compete against other departmental priorities”3. A roadmap should identify in advance which items are protected and which would be deferred if funds fell short. Making that choice calmly beforehand is better than making it in the week the cut arrives.
Write commitments that can be checked
Each item in the committed horizon should be stated so that an outsider could tell, on the due date, whether it happened.
The UK roadmap describes its own commitments as “concrete, measurable and ambitious, but also achievable”, and explains how they are made so: each one “is being translated into quantifiable, department-level targets against which progress will be measured”1. One of its data commitments shows the form, promising that half of the high-priority data quality issues will be resolved within a period defined by a cross-government framework1.
A checkable commitment has four parts: a named owner who is accountable for the result, a deliverable described as an outcome and not an activity, a measure with a baseline, and a date. The playbook’s instruction is the same in fewer words: review goals and objectives “to ensure they have clear timelines and metrics”4.
A commitment to improve data quality in finance cannot be checked. A commitment that the finance director will have the five month-end reconciliation breaks with the longest history closed at source by the end of the second quarter can. The second version is harder to agree, which is the reason to insist on it.
Govern the re-plan
No roadmap survives unchanged. What matters is whether it can be changed in an orderly way.
The UK arrangements, as the roadmap describes them and as the National Audit Office examined them, have three features worth adopting at any scale. Progress is reviewed on a fixed rhythm: quarterly business reviews “to understand progress and blockers against targets”1. A senior forum owns the plan and receives regular reports. And spending approval is tied to the plan, so that new requests are assessed against it1. The National Audit Office added a realistic note, that the reporting arrangements were expected “to evolve as the scale of the task becomes clearer”3.
For an organisation’s own roadmap, this suggests a simple regime.
- A quarterly review that moves items between horizons, records what was delivered against its measure and logs what was deferred and why.
- A named forum with authority to change the committed horizon, and a rule that nobody else can.
- A test for new proposals: which outcome they serve, what they depend on, and what they would displace.
- An annual reset aligned with the budget, when the planned horizon is firmed up and the next one sketched.
The purpose of the regime is to make changing the plan cheaper than abandoning it. A roadmap that can only be replaced risks being replaced by a new strategy, with the organisation starting again. The patterns behind that are examined in why data strategies stall after approval.
The Data Strategy Roadmap provides the working structure: initiatives by horizon, dependency marking, owners, measures and a review log. The Data Strategy Alignment Guide supplies the outcome each initiative should trace to.
Sources
- Central Digital and Data Office (UK Government). Transforming for a digital future: 2022 to 2025 roadmap for digital and data (updated September 2023). 9 June 2022.
- Federal Data Strategy (United States Government). Federal Data Strategy 2020 Action Plan. 14 May 2020.
- National Audit Office (UK). Digital transformation in government: addressing the barriers to efficiency (HC 1171). 10 March 2023.
- Federal Chief Data Officers Council (United States Government). CDO Playbook: Advancing the Federal Data Strategy. 2021.
This article is general professional information. It is not legal or regulatory advice.