Data strategy: what it is and how to write one

A data strategy is the plan that sets out which decisions you want to make better with data, which sources, definitions and skills that takes, who owns each of them and in what order you build it. For an organisation of fifty to five hundred people it fits on five to ten pages and takes four to six weeks to write.

That is not what most documents with that title contain. The data strategies we come across are about a platform, an architecture and a list of tools, written by IT or by the vendor of that platform. They say exactly how the data will flow and nowhere which decision gets better as a result.

The outcome is predictable: the plan is approved, the platform is built, and a year later finance is still checking figures in Excel on the third working day of the month. So this article starts with what a data strategy is and is not, and then covers what goes in it, how to write one in six steps, who owns it, how big it should be in a mid-sized company and where it usually fails.

What is a data strategy?

A data strategy is a plan that sets out how you will use data to reach your business goals. It answers three questions, in this order:

• Which decisions must improve? Not “we want to become data-driven”, but: margin per customer group has to be on the table every month, capacity has to be visible three weeks ahead, the board has to know for each revenue stream whether anything is left at the bottom line.
• Which data does that take? Which sources it comes from, what each figure means exactly, how good the underlying records are and where it all comes together.
• Who does what, and in what order? Who owns the definitions, who builds, who maintains, which project comes first and when you look back.

A few neighbouring terms are worth keeping apart. The business strategy says where the organisation is going; the data strategy is derived from it and never stands on its own. Data-driven working is the behaviour you want to reach, the data strategy is the plan that makes that behaviour possible. And data governance is one part of the strategy: the agreements on ownership, definitions and access.

What a data strategy is not: a technology choice. Whether the data warehouse ends up in Fabric, Azure or somewhere else is a consequence of the strategy, not part of its first version.

Why do you need a data strategy?

Because the alternative is also a strategy, just an unconscious one. Revenue lives in the ERP, the pipeline in the CRM, costs in the accounting package and the corrections in an Excel file on the controller’s drive. Each system is right about its own part. In the monthly meeting those parts meet, and the first fifteen minutes go on which revenue figure is correct. By the time that is settled, the agenda has moved on and nothing has been decided about margin.

Sound familiar? Then it is not the data that falls short, but the agreement about it. Without a data strategy, every new request for a figure becomes its own little job, with its own export, its own definition and its own dashboard. A year later there are ten of them, and they contradict each other at exactly the moments you need them.

With a data strategy, each project builds on the last. The definition of revenue is fixed once and reused from then on. The connection to the accounting system is built once and feeds both the finance screen and the sales screen. The order of projects is set in advance, so the question “what do we do next” is answered before the first delivery lands.

That has recently come to apply to anything involving AI as well. A model that produces forecasts or answers questions about your figures relies on the same sources and the same definitions as your dashboards. Get those two wrong and you do not get smarter answers, only faster wrong ones. Microsoft describes the relationship between BI strategy, data strategy and business strategy as three layers that feed each other, and explains in its own implementation planning why you start with the top layer. In mid-sized companies the layers largely coincide, because reporting is usually the first and biggest use of data there.

What goes into a data strategy?

Seven parts, and the order is no accident: the first part determines the content of all the others.

• The decisions that must improve. One or two steering questions per role, concrete enough to check whether they were answered. This is the part you derive from the business strategy and that the board writes itself.
• The KPIs and their definitions. Which figures belong to those decisions, how they are calculated, from which source, against which target. How to choose and define them per department is covered in our article with KPI examples.
• The sources and the place where they meet. Which systems supply which data, how often it refreshes, and in which central model it comes together so that everyone looks at the same figure.
• Ownership and data quality. A name per source and per definition, not a department. Plus the agreement on what happens when the input is wrong, because a dashboard only makes poor record-keeping visible faster.
• Security and privacy. Who may see which figures, how you arrange that per row and per role, how long you keep personal data and in which region the model physically sits. Since the debate on data sovereignty, that last point is no longer a detail.
• People and skills. Who builds, who maintains, what you do yourself and what you outsource, and how you keep the knowledge from ending up with one colleague or one vendor.
• The roadmap and the rhythm. The order of projects for the next twelve months, and the fixed moment each quarter when you hold the strategy up to the light.

What does not belong in it is an extensive description of the tooling. We have seen data strategies thicker than the annual report, and the only part the whole organisation had read was the title page.

What does a data strategy look like? An example

Take a wholesaler with a hundred and twenty employees, an ERP for orders and stock, a separate accounting package and a CRM that sales half uses. The board wants to grow, but does not know which customer groups make that growth profitable. That is the first steering question, and the one-page data strategy then looks like this:

• Decision. Every month, decide for which customer groups we adjust price, service or effort, based on margin per customer group.
• KPI and definition. Gross margin per customer group: revenue from the accounting system minus cost price from the ERP, per calendar month, excluding VAT and including retrospective discounts. Target: last year’s weighted average plus two percentage points.
• Sources and model. Accounting leads for revenue, the ERP for cost price and customer group. Both come together daily in one central model registered in the wholesaler’s own name.
• Ownership and access. The controller owns the definition, the sales director owns the customer grouping. The board sees everything, account managers only their own customers.
• First project. One margin screen, working within four weeks, discussed at the next monthly meeting.
• Roadmap. Then delivery reliability for operations and pipeline coverage for sales, each on the same model. Review of the strategy every quarter.

The first version does not need to be more than that. Everything that comes later, from a second KPI to a choice for a larger platform, follows from what the first project taught you, and that is exactly the point.

Writing a data strategy in six steps

The steps below are written for an organisation that has no data strategy yet, or has one nobody opens any more. Allow four to six weeks, with the board in the room for steps one, three and six.

1. Translate the business strategy into decisions. Take the goals for the next two years and ask each board member: which decision do you currently take on instinct that you would rather take on a figure? That usually yields five to eight steering questions. More is a sign that no choice has been made yet.
2. Take stock of where you stand. Which systems exist, who owns each one, how good the records are, which reports already exist and which Excel files hold things together in practice. This step always disappoints, and that is precisely its value: the number of sources is almost always bigger than assumed, and the shadow spreadsheets are exactly where the definitions drift apart.
3. Fix definitions and ownership. For each KPI from step one: formula, source, period, target and the name of the owner. This is an afternoon’s work per department and it prevents most of the discussion that would otherwise return every month. It is also the moment to decide which source leads when two systems disagree.
4. Choose an architecture that fits your size. For most mid-sized companies that is one central data model that the sources connect to and all reports draw from, in an environment registered in the organisation’s own name. Whether a data warehouse belongs underneath it depends on the number of sources and reports, not on ambition. It only needs to get bigger once the first projects show where it pinches.
5. Build the first version around one steering question. Not all eight at once. Pick the question with the most pain and the best records, and deliver a working screen for it within weeks. That proves the value of the strategy before the big work starts, and tests whether anything is actually decided differently. What such a first version looks like and what it costs is set out in our article on getting a Power BI dashboard built.
6. Set the rhythm and the review. One hour every quarter: what did the last project teach us, is the order of the roadmap still right, which definition has quietly changed. A data strategy that is never opened after approval describes, within a year, an organisation that no longer exists.

Who owns the data strategy: the board, IT or the departments?

Data is not a subject you can park with IT. IT owns the technology: the connections, the security, the platform. But the question which decision must improve, and which one comes first, can only be answered by the board. And the question what a figure means exactly belongs to the department that steers by it: the definition of delivery reliability belongs to operations, that of pipeline coverage to sales.

That shared ownership is exactly what the centralised-versus-decentralised debate is about. Fully centralised means one team manages all the data and every department waits for that team: consistent, but slow. Fully decentralised means every department produces its own figures: fast, but within a year you have three definitions of revenue. Microsoft distinguishes three forms of ownership in between, from business-led self-service to fully central management, and describes for each form who manages what and which questions to ask.

For mid-sized companies the middle form is almost always the right one: one central model with fixed definitions, on which departments build their own reports. The board guards the strategy, a small team or a partner guards the model, and the departments guard what their figures mean. As soon as one of the three is missing, ownership drifts to whoever happens to be best at Excel.

A data strategy for the mid-market: five pages, not fifty

Most examples of a data strategy you find online are written for organisations with their own data department, a chief data officer and a seven-figure budget. Mid-sized companies have none of those, and do not need them. What they do need is the same order at a fraction of the size.

In practice that means: one page with the steering questions per role, one with the KPI definitions, one with the sources and the model, one with ownership, access and privacy, and one with the roadmap for the next twelve months. Anyone who wants to add a sixth writes down what the organisation keeps in-house and what sits with a partner: in whose name are the environment, the model and the definitions, and what happens if that partner disappears tomorrow. That is the page that prevents dependency, and it is the page most vendors would rather not write for you.

Writing it costs mostly board time, not money: two or three half-day working sessions, with the inventory from step two in between. If you have an outside party facilitate it, the thing to watch is that they ask the first question and not straight away the fourth. A partner who opens the conversation with a platform choice is writing a technology plan under a different title.

Where a data strategy fails

Four causes keep coming back, and all four can be spotted in advance:

• The plan starts with the platform. If the first page is about Fabric, Azure or a data warehouse, the strategy was written from the solution. The decisions that must improve appear as examples at best.
• The plan was written by the vendor. A vendor writes towards its own product, that is its job. Let the vendor contribute to steps four and five, not step one.
• Nobody has time for it. A strategy without an owner who has hours in the diary is an archive document within a quarter. That owner does not need to be a data expert, but does need a mandate.
• Everything at once. Eight steering questions, all the sources, one big delivery in nine months. By then two of the eight questions have changed and the support has run out. One question first, then the next.

In all four cases the remedy is the same: back to the question which decision must improve. As long as that is on the table, the rest corrects itself.

---

Is your data strategy a plan the board steers by, or a document IT delivered once? Want to know what those five pages would look like for your organisation? Get in touch and we will walk through the first step together.

Frequently asked questions