From Strategy to Roadmap

Executive summary

Data strategies often fail in the gap between ambition and budget. Capabilities are listed without the use cases that justify them, platforms are selected before anyone has agreed what they must deliver, and progress is reported as activity because value was never defined. The result is a program that is busy, expensive and hard to defend when budgets tighten. The remedy is not a longer document but a set of explicit choices: a portfolio of use cases with sponsors and value hypotheses, a target per capability, and a sequence across three horizons that produces evidence early enough to earn the next funding decision.

This paper follows that path from strategy to roadmap and then to a running program.

• A data strategy has five layers, from vision and use cases through principles, capabilities, operating model and architecture to a roadmap with value tracking, and every roadmap item should trace upward to a use case or a capability target.
• The use-case portfolio sits at the center: capabilities needed by many use cases become shared foundations funded centrally, and those needed by one are funded with it.
• The starting point is assessed before targets are set, and targets differ by capability; deciding what stays at its current level frees capacity for the priorities.
• Value against feasibility sorts the portfolio into flagships, foundations to build first, quick wins and items to park, and three horizons sequence the work with a funding gate at each boundary.
• Five workstreams, four governance bodies, OKRs with leading indicators and a monthly, quarterly and annual refresh cycle keep the strategy alive as a set of choices rather than a filed document.

The paper closes with the failure modes that most often derail data programs, a readiness checklist to apply before the roadmap is published, and five first steps that can be started within a quarter.

Why data strategies stall before the budget

Data strategies often fail between the strategy document and the funding decision: the ambition is clear, the sequence is not.

The gap opens in three predictable places. Capabilities are listed without the use cases that justify them, so no business executive feels the need for them. Platforms are selected before anyone has agreed what they must deliver, so the roadmap becomes a procurement plan. And progress is reported as activity because value was never defined, so the program cannot show what the money achieved when the next budget round arrives.

None of these is solved by more detail. A strategy becomes fundable when it makes choices: which use cases come first and who sponsors them, which capabilities must reach which level and why, how the work is sequenced so that each stage earns the next, and how value is measured along the way. The rest of this paper sets out those choices in the order in which they are made.

What a data strategy is

A data strategy is a small number of connected components rather than a long document. The layers below show how they depend on one another, and the comparison that follows shows what a strategy is and what it is not.

What a data strategy contains

The vision and ambition state where data must make a difference to the business strategy and by when, in the language of business outcomes. Business alignment is expressed as a prioritized use-case portfolio with value hypotheses and named sponsors. Principles guide decisions when the strategy is silent, and the target capability model states which capabilities must reach which level. The operating model defines roles, decision rights and the funding model, and the architecture direction sets the main design choices without specifying products. The roadmap sequences funded initiatives, and value tracking closes the loop with OKRs and leading indicators.

The upper layers set direction and the lower layers make it executable. Every roadmap item should trace upward to a use case or a capability target, and value tracking closes the loop back to the ambition. An item that cannot be traced is a preference, not a strategic choice.

A strategy is a set of choices

The word strategy is used loosely, so it helps to say what a data strategy is not. It is not a technology shopping list, however well the products are described in business language. It is not a governance policy manual or an inventory of data assets, although both may be outputs of the program. It is not a list of every data problem anyone has raised, because a strategy that includes everything prioritizes nothing. It is not finished once and filed, and it should not promise the highest maturity level in every capability. Choices that exclude things are the test of a real strategy.

Linking data strategy to business strategy

Business strategy and data capability meet in the use-case portfolio. This section shows how use cases pull capability investment, what each portfolio entry should contain, and how the portfolio is built.

Capabilities pulled by the use-case portfolio

Each use case states a value hypothesis: the business outcome it will change, the metric and baseline, the timing, and the sponsor who owns the result. Each also lists the capabilities it depends on and the level each must reach, for example trusted customer master data, quality rules on specific critical data elements, or lineage for a regulatory report.

When dependencies are aggregated across the portfolio, a pattern appears. A few capabilities are needed by many use cases, and those become the shared foundations, funded centrally and justified by several outcomes at once. Capabilities needed by a single use case are funded with it. Literacy and change management belong on the map as dependencies rather than afterthoughts, because adoption is usually the main delivery risk. The hub keeps capability investment tethered to demand rather than to the preferences of the data team.

From use case to value hypothesis to capability dependencies

A value hypothesis is a testable statement linking a data-enabled change to a business outcome: earlier intervention lowers churn in target segments, or fewer manual adjustments shorten regulatory attestation. It is a hypothesis because the program will measure whether it holds, and the measure should be agreed with the sponsor before work starts. The dependencies column is where the strategy becomes concrete: it names the data domains, quality controls, metadata, integration and privacy capabilities the use case cannot succeed without.

Reading down that column across the portfolio reveals the foundations. In the example, customer master data and quality rules appear repeatedly, which is the evidence needed to fund them as shared capabilities. Each organization's use cases, metrics and dependencies will differ, but a portfolio of twenty entries structured this way is more useful than a strategy of twenty pages of aspiration.

Building the use-case portfolio

Building the portfolio is a repeatable process. Collect candidates widely, from business unit plans, operational pain points, regulatory obligations and existing analytics backlogs, and keep the long list visible so that nobody feels excluded by the prioritization that follows. Frame a value hypothesis for each candidate; candidates that cannot be framed this way are usually ideas rather than use cases. Map dependencies on data, capabilities and platform services, and the level each must reach. Cluster use cases that share dependencies, so that foundations are built once and justified by several outcomes.

Finally, confirm pull: keep only use cases with a named business sponsor willing to co-fund and to be measured on the outcome. This last filter is the hardest and the most important, because a use case without pull consumes capacity and then fails at adoption.

Starting point and target state

Target setting without a baseline produces ambition without a plan, so the starting point is assessed first. Targets are then set per capability, each justified by the use cases that need it.

Assess the starting point, then set targets per capability

A maturity assessment against a recognized reference model, such as a rubric built on DAMA-DMBOK or the EDM Association's DCAM, gives a calibrated score per capability with evidence behind it. Alongside it, the use-case portfolio shows which capabilities are needed and how soon; the platform and architecture inventory shows what exists, what is paid for and what is duplicated; and a view of skills, roles and culture shows who can do the work. Open risks and regulatory findings set deadlines that override preference.

The target state is then defined per capability rather than as one level for all. Each target is justified by the use cases that need it, is time-bound across the three horizons, and has a named owner. Equally important are the explicit decisions about what stays at its current level, because those decisions free the capacity that the priorities need.

An illustrative target state

The levels above are illustrative, and targets differ by organization and portfolio. Governance and quality are asked to reach the defined level because every priority use case depends on consistent standards and on rules and scorecards for critical data elements. Metadata moves from tribal knowledge to a catalog of record because lineage and self-service depend on it. Master data is deliberately held at its current level: domain hubs already serve the priority use cases, and raising the target would consume capacity without a sponsor asking for it.

The platform target is higher because the platform is a shared foundation across all horizons and its service levels must be measured. Literacy and change get a defined, role-based program because adoption is the main delivery risk. Each row states a driver; a target that cannot name one should be challenged before it reaches the roadmap.

Prioritization and sequencing

With the portfolio and targets in place, the roadmap is a matter of order: which use cases go first, which foundations must precede them, and how the work is divided into horizons that each earn the next.

Prioritizing the portfolio: value versus feasibility

Value against feasibility is the simplest prioritization frame, and it works when both axes are assessed honestly. Value comes from the hypothesis: the size of the outcome, its strategic fit and the risk it reduces. Feasibility covers data readiness, available skills, dependencies on capabilities not yet built, and the capacity of the sponsor's organization to absorb change.

High-value, high-feasibility use cases are the flagships for horizon one; they prove the strategy and earn the next funding decision. High-value, low-feasibility use cases are the reason to fund foundations now and schedule the use case for horizon two, with the dependency made explicit. Low-value, high-feasibility items are quick wins that build skills and credibility, provided they leave reusable assets behind and do not crowd out foundations. Low-value, low-feasibility items are parked and revisited at the annual refresh. Because feasibility changes as foundations land, the matrix should be re-scored every quarter.

Foundations, quick wins and the dependencies between them

Foundations are justified by the use cases that need them; quick wins by the reusable assets they leave behind. The two compete for the same capacity, and dependency management connects them.

Foundations are the shared capabilities that many use cases depend on: customer master data, quality rules on critical data elements, the glossary and catalog, and platform services. They are funded centrally and justified by several outcomes at once, but they should still arrive in thin slices tied to the first use cases and be measured by what they unblock rather than by completion. Quick wins produce visible results in weeks; they build skills, credibility and sponsor confidence, and they earn their place only if they leave reusable assets behind.

Dependency management connects the two. Map dependencies per use case, aggregate them across the portfolio, and put a foundation on the critical path only when a use case needs it. Where a dependency blocks a flagship, decouple it with an interim data feed or a time-boxed manual control, record it in the dependency register, and re-score feasibility each quarter.

Three horizons: an illustrative sequence

The horizons are illustrative; their lengths depend on the organization's size, starting maturity and the urgency of its use cases, and they overlap rather than hand off cleanly. Horizon one, roughly the first six months, mobilizes and proves: the charter, sponsors and steering committee are in place, the baseline and target state are agreed, flagship use cases are funded, and the first thin slices of governance, quality and catalog are in use. Horizon two, from about six to eighteen months, scales and delivers: flagships go live and are measured against their value hypotheses, shared foundations extend to the next cluster of use cases, and stewardship, quality rules and catalog coverage widen domain by domain.

Horizon three, to about thirty-six months, institutionalizes: capabilities run as services with owners, budgets and service levels, governance is embedded in change, procurement and project gates, and the strategy is refreshed for the next wave of use cases. Each boundary is a funding gate that the previous horizon must earn with evidence. These delivery horizons, measured in months, borrow only the name of the three horizons of growth described by Mehrdad Baghai, Stephen Coley and David White, which distinguish extending the core business, building new businesses and seeding options for the future.

Program structure and governance

A roadmap is delivered by a program, and the program needs a structure that stays stable while the use cases change. Five workstreams, four governance bodies and deliberate funding and staffing choices provide it.

Five workstreams

Governance and stewardship establishes the governance framework: policies, decision rights, owners and stewards, the council, and the process by which issues are raised and escalated. Platform and architecture sets the architecture direction and delivers shared platform services and integration patterns, so that reuse is the default. Quality and metadata builds rules and scorecards for critical data elements and the glossary, catalog and lineage that make data findable and trusted. Literacy and change runs role-based training, communities of practice and communication, and owns adoption.

Use-case delivery creates pull: cross-functional teams deliver the prioritized use cases with their sponsors and draw on the other four workstreams for what they need, in order. Each workstream has a lead, a backlog and key results, and all five plan against one shared dependency register. Workstreams that plan separately recreate the silos the strategy set out to remove.

Program governance

Program governance is the set of bodies that decide quickly enough for the roadmap to hold.

The steering committee consists of the sponsors who own the use-case outcomes, chaired by the executive sponsor, and decides scope, funding and trade-offs. The PMO maintains the plan, dependency register, risks, benefits tracking and reporting, and prepares the decisions the steering committee takes. The architecture authority makes design decisions and grants exceptions for platform and integration, so that technology choices follow the architecture direction rather than individual projects. The data governance council owns the policies and standards that will outlive the program. One escalation path runs from the workstreams to the steering committee, and escalations are decided within the monthly cycle rather than carried forward.

Funding and staffing

• Foundations are funded centrally as a multi-year line, released horizon by horizon on evidence.
• Use cases are co-funded by their sponsors, who also commit business people to the delivery teams.
• Run costs are budgeted from the start, so that capabilities become services rather than orphaned projects.
• A core team of permanent roles is supplemented by contractors for peaks, with knowledge transfer written into their contracts.
• Named owners are in place for each capability and each use case before funding is released.

The funding logic mirrors the portfolio logic. Shared foundations are justified by several outcomes and so are funded centrally, but released in stages against evidence; use cases are funded by those who benefit, which keeps pull and accountability together. A business case built from the organization's own evidence, with named benefit owners and measures finance can verify, is what secures the first horizon.

Change, measurement and risks

Delivered capability creates value only when behavior changes. This section covers change management and communication, measurement with OKRs and leading indicators, and the failure modes that most often derail data programs.

Change management and communication

Change management decides whether delivered capability becomes changed behavior. Stakeholder mapping identifies everyone whose support, work or approval the program needs, and gives each group a named relationship owner. The narrative keeps the facts the same while changing the framing for each audience. Early wins are the program's strongest communication asset, especially when the people credited are in the business rather than in the data team. Communities of practice spread standards peer to peer, and their feedback is one of the best early signals of whether the program is helping or merely adding process.

Measuring progress with OKRs and leading indicators

Objectives and key results give the program a measurement structure that sponsors recognize, and leading indicators give early warning before key results move.

Each objective is a business or capability outcome; each key result is a measurable change with a named owner, and in practice it carries a baseline and a numeric target agreed with that owner. The table omits numbers because they are organization-specific. Leading indicators are activity and coverage signals that predict the key result: offers that use the model, lineage coverage, domains with an active stewardship forum, rules monitored, assets with an owner and a definition, and community activity.

The PMO tracks leading indicators monthly and key results quarterly, and both are reviewed with the steering committee. Two cautions apply: leading indicators are not achievements in themselves, and a key result without a named owner is an aspiration. OKRs replace activity reporting; they do not sit alongside it.

Failure modes and how to mitigate them

These failure modes recur because each is the easy path. A strategy without funding is approved as a document and then absorbed into project budgets; approving horizon one funding with the strategy, and gating later horizons on evidence, prevents it. A roadmap that is really a tool-buying list selects platforms before anyone has agreed what they must deliver. No business pull shows up when the data team owns the use cases and sponsors attend without committing people or money; the confirm-pull filter in building the portfolio is the mitigation.

A big-bang platform defers the first measured outcome by years. Activity reported as progress is cured by OKRs with sponsor-owned key results. Governance ahead of value, where policies and councils appear before any use case needs them, erodes goodwill. Each failure mode has an early signal the PMO can watch for, and the mitigations belong in the roadmap itself rather than in a risk log.

Keeping the strategy alive

A strategy that is not refreshed decays into a historical document, so the cadence is part of the strategy itself. Four rhythms keep it current.

The monthly program review covers delivery, dependencies, risks and leading indicators, and escalates decisions to the steering committee within the same cycle. The quarterly review re-scores the portfolio, because feasibility changes as foundations land, checks key results with their sponsors and re-plans the next quarter. The annual refresh revisits the strategy's assumptions, reassesses maturity with the same rubric used for the baseline, resets capability targets, admits the next wave of use cases from the long list, retires those that have lost their sponsor, and renews funding for the next horizon. Certain events force an early refresh.

Through all of this, the vocabulary and the capability model stay stable, so that successive assessments and roadmaps can be compared. A program that renames its capabilities every year cannot show progress against them.

Readiness checklist

Where to start

The first steps are sized to be started within a quarter, and the first of them can begin before any budget is approved.

1. Create the demand signal. Draft the use-case long list and write value hypotheses for the leading candidates.
2. Measure the gap. Commission a maturity baseline against a recognized reference model and agree a target level per capability.
3. Make it real. Secure horizon one funding for the flagship use cases and the foundations they need, supported by a business case with named benefit owners.
4. Give it structure. Stand up the steering committee, the PMO and the workstream leads, and publish the OKRs.
5. Keep it adapting. Set the refresh cadence and the date of the first quarterly re-score.

A strategy becomes real when its first horizon is funded and measured.

Glossary

Data strategy

A set of choices about how data will support the business strategy: which use cases matter, which capabilities reach which level, how the work is organized and funded, and how value is tracked.

Use case

A specific business change enabled by data, with a sponsor, a value hypothesis and a list of capability dependencies.

Use-case portfolio

The prioritized set of use cases from which capability investment is derived.

Value hypothesis

A testable statement that a data-enabled change will move a named business measure, with a baseline, timing and sponsor.

Capability

A data management ability, such as data quality management or master data, assessed and targeted on a maturity scale.

Target state

The level each capability should reach within a stated horizon, justified by the use cases that need it.

Foundation

A shared capability needed by many use cases, funded centrally and delivered in thin slices.

Flagship use case

A high-value, high-feasibility use case delivered early to prove the strategy.

Quick win

A low-cost, fast result from data that is already usable, justified by the reusable assets it leaves behind.

Horizon

A phase of the roadmap ending in a funding gate that must be earned with evidence.

Thin slice

A narrow increment of a foundation delivered for a specific use case rather than built out in full in advance.

Dependency register

The shared record of which use cases depend on which capabilities, with interim workarounds, reviewed monthly.

Program management office (PMO)

The function that maintains the integrated plan, dependencies, risks, benefits tracking and reporting.

Architecture authority

The body that makes design decisions and grants exceptions for platform and integration.

Objectives and key results (OKRs)

A goal-setting method, introduced at Intel by Andy Grove and popularized by John Doerr, that pairs qualitative objectives with measurable key results.

Leading indicator

An early activity or coverage signal that predicts whether a key result will move.