Planning a BI project

How to Develop a Data Strategy Roadmap

A data strategy roadmap sequences work into phases, each with a deliverable and a gate that decides when to start the next one. The four phases explained.

Sajagan Thirugnanam

·

Updated

A data strategy roadmap sequences data work into phases, each with a defined deliverable and a gate that decides whether to move to the next one. It is not a list of every initiative a company could run. A roadmap with no order attached is a wish list, and a wish list gets reprioritized every quarter with nothing finished.

For the structure each phase builds toward, see how to build a data strategy framework. For turning goals into the KPIs a roadmap should be built around, see how to create an analytics strategy.

Four phases, each with a gate

Each phase below has a stated deliverable and a gate: a condition that has to be true before starting the next phase. Moving to phase two before phase one's gate is met is the most common reason a roadmap stalls.

Phase

What it delivers

Gate to move on

0. Assess

A source inventory and a data maturity gap list

An owner is assigned to every gap on the list

1. Foundation

One platform, governance rules, one accurate report

The first report is trusted enough to replace a manual spreadsheet

2. Expand

A shared semantic model reused across teams, row-level security

Two or more teams have self-serve reports live on it

3. Scale

Broader self-service, predictive measures, wider automation

Phase 2's reports are stable with no recurring data-quality fixes

Phase 0: assess before building anything

Assessment means listing every source system, who owns it, and where the current data breaks: missing fields, duplicate records, no shared customer identifier across systems. The deliverable is a gap list with an owner assigned to each gap, not a maturity score with no names attached to it.

Phase 1: build the foundation

This is where the platform and governance layers get built: one place data comes to rest, row-level security rules, and a first semantic model. The gate for this phase is concrete: the first report built on it has to be trusted enough that someone stops maintaining the spreadsheet it replaces. A foundation phase that never produces a report people actually use has not met its own gate, no matter how complete the underlying platform is.

A data quality measure is a practical way to track this phase's exit criteria directly in Power BI:

Rows Failing Validation % =
DIVIDE (
    CALCULATE ( COUNTROWS ( Sales ), Sales[ValidationFlag] = FALSE () ),
    COUNTROWS ( Sales )
)

Watching this measure trend down across the foundation phase is a better signal that the platform is ready than a fixed calendar date.

Phase 2: expand to more teams

Once one report is trusted, the same semantic model extends to a second and third team, each with its own row-level security rule instead of its own copy of the data. Fabric deployment pipelines move a validated report from a development workspace through test and into production, so a change gets checked before it reaches the teams already depending on it.

The gate here is usage, not completion: two or more teams need self-serve reports live and in regular use before phase three starts. Building a report nobody opens does not meet this gate.

Phase 3: scale and automate

With the foundation stable and several teams self-serving, the roadmap can turn to predictive measures, wider automation of refresh schedules, and self-service extending past the teams that asked for it first. This phase depends entirely on phase 2 being stable. Starting it while phase 2's reports still need weekly data-quality fixes means building automation on top of a platform that is not ready for it.

Deciding when to move to the next phase

Use the gate column in the table above as a checklist, not the calendar. A roadmap that measures progress by dates instead of by the gates tends to move on schedule and stall in practice. Phase 2 quietly starts before phase 1's report is actually trusted. Data governance rules set in phase 1 are what make phase 2's row-level security expansion possible without rebuilding access control per team.

FAQs

What is a data strategy roadmap?

A sequenced plan with four phases, assess, build the foundation, expand to more teams, then scale, each with a deliverable and a gate that decides when the next phase starts.

Why is assessing current capabilities important?

Skipping the assessment phase means building a foundation on top of source data whose real problems, missing fields, duplicate records, no shared identifiers, are still unknown. Phase 1 work built on that foundation inherits every one of those problems.

How often should I review my data strategy roadmap?

Review it at each phase gate, not on a fixed calendar. If a phase's gate has not been met after several months, that is a signal to fix what is blocking it rather than moving to the next phase regardless. A related question, what a data strategy consulting engagement actually covers, is answered in our data strategy consulting guide.

Sources

A data strategy roadmap sequences data work into phases, each with a defined deliverable and a gate that decides whether to move to the next one. It is not a list of every initiative a company could run. A roadmap with no order attached is a wish list, and a wish list gets reprioritized every quarter with nothing finished.

For the structure each phase builds toward, see how to build a data strategy framework. For turning goals into the KPIs a roadmap should be built around, see how to create an analytics strategy.

Four phases, each with a gate

Each phase below has a stated deliverable and a gate: a condition that has to be true before starting the next phase. Moving to phase two before phase one's gate is met is the most common reason a roadmap stalls.

Phase

What it delivers

Gate to move on

0. Assess

A source inventory and a data maturity gap list

An owner is assigned to every gap on the list

1. Foundation

One platform, governance rules, one accurate report

The first report is trusted enough to replace a manual spreadsheet

2. Expand

A shared semantic model reused across teams, row-level security

Two or more teams have self-serve reports live on it

3. Scale

Broader self-service, predictive measures, wider automation

Phase 2's reports are stable with no recurring data-quality fixes

Phase 0: assess before building anything

Assessment means listing every source system, who owns it, and where the current data breaks: missing fields, duplicate records, no shared customer identifier across systems. The deliverable is a gap list with an owner assigned to each gap, not a maturity score with no names attached to it.

Phase 1: build the foundation

This is where the platform and governance layers get built: one place data comes to rest, row-level security rules, and a first semantic model. The gate for this phase is concrete: the first report built on it has to be trusted enough that someone stops maintaining the spreadsheet it replaces. A foundation phase that never produces a report people actually use has not met its own gate, no matter how complete the underlying platform is.

A data quality measure is a practical way to track this phase's exit criteria directly in Power BI:

Rows Failing Validation % =
DIVIDE (
    CALCULATE ( COUNTROWS ( Sales ), Sales[ValidationFlag] = FALSE () ),
    COUNTROWS ( Sales )
)

Watching this measure trend down across the foundation phase is a better signal that the platform is ready than a fixed calendar date.

Phase 2: expand to more teams

Once one report is trusted, the same semantic model extends to a second and third team, each with its own row-level security rule instead of its own copy of the data. Fabric deployment pipelines move a validated report from a development workspace through test and into production, so a change gets checked before it reaches the teams already depending on it.

The gate here is usage, not completion: two or more teams need self-serve reports live and in regular use before phase three starts. Building a report nobody opens does not meet this gate.

Phase 3: scale and automate

With the foundation stable and several teams self-serving, the roadmap can turn to predictive measures, wider automation of refresh schedules, and self-service extending past the teams that asked for it first. This phase depends entirely on phase 2 being stable. Starting it while phase 2's reports still need weekly data-quality fixes means building automation on top of a platform that is not ready for it.

Deciding when to move to the next phase

Use the gate column in the table above as a checklist, not the calendar. A roadmap that measures progress by dates instead of by the gates tends to move on schedule and stall in practice. Phase 2 quietly starts before phase 1's report is actually trusted. Data governance rules set in phase 1 are what make phase 2's row-level security expansion possible without rebuilding access control per team.

FAQs

What is a data strategy roadmap?

A sequenced plan with four phases, assess, build the foundation, expand to more teams, then scale, each with a deliverable and a gate that decides when the next phase starts.

Why is assessing current capabilities important?

Skipping the assessment phase means building a foundation on top of source data whose real problems, missing fields, duplicate records, no shared identifiers, are still unknown. Phase 1 work built on that foundation inherits every one of those problems.

How often should I review my data strategy roadmap?

Review it at each phase gate, not on a fixed calendar. If a phase's gate has not been met after several months, that is a signal to fix what is blocking it rather than moving to the next phase regardless. A related question, what a data strategy consulting engagement actually covers, is answered in our data strategy consulting guide.

Sources

More on this topic.

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

Show us your report nobody trusts.

1 · A 30-minute call.

2 · We look at your current reports together.

3 · We tell you what we would do.

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English

CaseWhen is a Berlin BI consultancy that builds reporting that leaders can trust, on the Microsoft stack: Power BI, Fabric and Azure.

Berlin, Germany

© CaseWhen Consulting GmbH

English