A data strategy without a delivery roadmap is a presentation, not a plan. Here is how to turn strategic intent into a sequenced, costed, and governed programme that delivers value in 90 days and builds toward the 3-year architecture.
The quick answer
A data strategy roadmap is a sequenced, costed programme that translates a data strategy (what you are trying to achieve) into a delivery plan (what gets built, in what order, by whom, and by when). Without a roadmap, a data strategy is a vision document that no one acts on. Without a strategy, a roadmap is a list of projects with no coherent direction.
The two common failure modes: roadmaps that start with technology (we will buy Snowflake, implement dbt, and deploy Tableau) without establishing what business value they deliver; and strategies that identify the desired end state without addressing how to get from current to future state in a sequence that delivers value before the 18-month mark. Both produce wasted investment.
Starting point: the current-state assessment
A roadmap cannot be designed without understanding the current state. The assessment covers:
**Data inventory**: what data exists? What source systems are in operation? What data is collected but not used? What data is needed but not collected? A data inventory does not need to be exhaustive before roadmapping — but the highest-value data domains (financial transactions, customer records, operational metrics) should be understood before sequencing initiatives.
**Architecture audit**: what is the current data infrastructure? Is there a data warehouse? How is data moved? What transformation logic exists, and where does it live (stored procedures, spreadsheets, BI tool calculated fields)? What are the known quality issues, gaps, and constraints?
**BI and reporting audit**: what dashboards and reports exist? What is used? What is trusted? What is requested repeatedly but cannot be answered reliably from existing data? The gap between what is requested and what the current infrastructure can deliver reliably is the most direct input into roadmap prioritisation.
**Team capability**: who is available to execute? What skills exist internally? What roles are missing? What is the budget envelope for external engagement? A technically ambitious roadmap executed with the wrong team (or no team) delivers nothing.
**Business priorities**: what decisions need to be made better? What operational processes could be improved with better data? What regulatory requirements impose data obligations? What strategic initiatives (M&A, market expansion, new products) create data requirements? Business priorities are not derived from IT — they come from conversations with the data consumers: CFO, COO, VP of Sales, VP of Marketing, VP of Operations.
The assessment phase typically takes 4–8 weeks depending on environment complexity. For a consulting firm assessment, see data architecture consulting cost for cost benchmarks ($15,000–$40,000 for a structured assessment).
The roadmap structure: three horizons
A data strategy roadmap operates across three time horizons:
**Horizon 1 (0–90 days): Stabilise and deliver first value.** This horizon must deliver demonstrable value to justify continued investment. It focuses on the highest-priority, highest-confidence use cases that can be delivered on current or near-current infrastructure. Examples: a single certified revenue dashboard that replaces the spreadsheet-based revenue review, a fixed data quality issue that has been causing incorrect reporting, a specific data source integration that unblocks a known analytical requirement.
Horizon 1 is not about architecture; it is about credibility. The goal is to demonstrate that the data team delivers reliable analytical value. Without this, longer-horizon investment is harder to justify.
**Horizon 2 (90 days – 12 months): Build the foundation.** This horizon establishes the architectural foundation: data warehouse, ingestion pipelines for core data domains, transformation layer, governance framework, and the BI platform configuration. These are the investments that enable Horizon 3 capabilities but do not themselves produce direct business value — they produce infrastructure reliability.
Horizon 2 initiatives are sequenced by dependency: data warehouse before transformation layer, transformation layer before BI semantic layer, ingestion pipelines before downstream analytics. The sequence is determined by technical dependencies, not by business priority.
**Horizon 3 (12–36 months): Scale and differentiate.** This horizon delivers the advanced capabilities that require the Horizon 2 foundation: ML models, real-time analytics, self-service analytics at scale, data product development, and the more complex analytical programmes that require reliable, governed, well-documented data to be possible.
Horizon 3 is where the strategic ambition lives. The roadmap makes Horizon 3 credible by showing how Horizons 1 and 2 create the conditions for it.
Prioritisation: what goes in which horizon
Prioritisation is a function of value and dependency, not just value alone. An initiative with high business value but significant technical dependencies (requires a data warehouse that does not exist yet) cannot go in Horizon 1 regardless of how important it is.
**Value framework**: for each potential initiative, estimate the business value across three dimensions:
1. Decision quality: does this data enable better decisions? How much is each better decision worth?
2. Operational efficiency: does this data or automation reduce manual effort? How many hours of manual work does it eliminate?
3. Risk reduction: does this initiative reduce a compliance, financial, or operational risk? What is the expected cost of the risk event it prevents?
**Dependency mapping**: for each initiative, identify what it requires:
- What data sources must be integrated first?
- What infrastructure must be in place?
- What team skills are required (which may require hiring or training)?
**Confidence adjustment**: high-value initiatives based on data that does not yet exist have lower delivery confidence than those based on existing data. Horizon 1 should contain only high-confidence initiatives — known requirements, known data, known path to delivery.
Building the 90-day plan
The 90-day plan is the most important output of the roadmap process. It is specific, committed, and immediately actionable:
- **Named initiatives**: specific named deliverables, not categories (not "improve data quality" but "implement dbt not-null and uniqueness tests on the customer_id column across all Silver-layer models and establish a weekly data quality report sent to the data engineering team lead")
- **Owners**: every initiative has a named owner. Unowned initiatives are not initiatives; they are suggestions.
- **Dependencies**: what must be true before this initiative can start? Dependencies determine the sequence.
- **Milestones**: 30-day, 60-day, and 90-day checkpoints for each initiative. Milestones are observable outputs, not activity descriptions ("data warehouse provisioned and connected to first source system" is a milestone; "working on data warehouse setup" is not).
- **Cost and resource**: what engineering capacity does each initiative require? What external spend? The 90-day plan must be resourced — if the plan requires 3 data engineers and only 1 exists, either the plan changes or the resource gap is filled.
The 90-day plan is reviewed at 30 and 60 days and adjusted based on what was learned. Roadmaps are not fixed documents; they are living plans that update as execution reveals new information.
Governance and steering
A data strategy roadmap requires governance to stay on track:
**Steering committee**: the group that owns the data strategy investment and makes prioritisation decisions when trade-offs arise. Typically includes the CDO or Head of Data, the CTO or VP Engineering, and representatives from the primary data consumer functions (Finance, Operations, Sales/Marketing). Meets monthly.
**Roadmap review cadence**: quarterly review of roadmap priorities against business requirements. Business priorities change; the roadmap must reflect current priorities, not the priorities that existed when the roadmap was written.
**Value realisation tracking**: for each initiative, track whether the expected value was delivered. Did the new revenue dashboard actually reduce time spent in the weekly revenue review? Did the data quality improvements reduce the number of ad-hoc queries to the data team to fix incorrect numbers? Without tracking, roadmap credibility is based on delivery volume rather than business impact.
**Escalation mechanism**: clear process for raising issues that block delivery — vendor procurement delays, resource constraints, scope creep from business stakeholders. Blocked initiatives that cannot escalate stall and kill roadmap momentum.
Common roadmap failure modes
**Starting with technology, not use cases.** A roadmap that leads with platform selection (we will implement Snowflake, deploy dbt, and adopt Tableau) before establishing what use cases those platforms will serve produces technically capable infrastructure that no one uses. Platforms serve use cases; use cases do not follow platforms.
**Horizon 1 too ambitious.** The most common failure: Horizon 1 is filled with complex, high-dependency initiatives that cannot be delivered in 90 days. By month 4, nothing has been delivered, stakeholder confidence is lost, and the programme stalls. Horizon 1 must be deliverable. It is better to deliver three small things in 90 days than to commit to ten large things and deliver none.
**No owner for the roadmap.** A data strategy roadmap requires a named owner who is accountable for its execution. Ownership by committee, or ownership by a consulting firm without an internal counterpart, does not work. The owner does not have to execute every initiative — they must be accountable for the programme's progress and escalate blockers.
**Underestimating data quality work.** Data quality remediation is almost always the work that takes the most time in a data platform build. Raw data from source systems is almost never as clean as assumed at the start. Build data quality assessment and remediation time into every initiative that depends on data from a new source system.
**Governance as an afterthought.** Treating governance (ownership, definitions, access control, quality standards) as something to implement after the platform is built is a common and expensive mistake. Governance is harder to retrofit than to build in. The roadmap should include governance design alongside platform design.
For a BI strategy that connects the data roadmap to the BI investment, see our BI strategy services. For the architectural design that sits beneath the roadmap delivery, see data architecture consulting. If you are building or refreshing a data strategy roadmap and want a structured assessment to start from, book a free 30-minute audit.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →