How to Align a Data Strategy to Business Outcomes
Alignment is a chain that can be followed in both directions: from a business outcome to the decisions behind it, to the data those decisions need, to the capability that supplies it. Where a link is missing, the work has no anchor.
A data strategy is aligned to the business when anyone outside the data function can pick an item in it and say which outcome it serves. The test is simple to state. A strategy fails it when it was written from the capability end: a catalogue, a platform, a quality programme, each defensible, none traced to something the organisation has said it wants.
This guide works in the other direction. It starts from outcomes the business already owns, follows each one to the decisions that produce it and the data those decisions depend on, and only then arrives at capabilities. It also covers how to test a benefit that someone has claimed, how to choose between competing uses, and how to turn down work that has no anchor. It assumes the account of strategy in what a data strategy is and the decisions it has to make, where the choice of outcomes is the first of five decisions.
Begin with outcomes the business already owns
The outcomes a data strategy serves should not be invented by the data team. They exist already, in the corporate plan, the regulatory commitments, the budget and the objectives of the executive team. The work at this stage is selection.
The US government’s 2020 action plan for its Federal Data Strategy describes the same move for public agencies and is candid about how large a change it is. Agencies were asked to begin with their priority questions and work back to data, an approach the plan calls “a paradigm shift in how agencies leverage data assets”1. Its reasoning is set out in one sentence: “Rather than constraining research based on data, the learning agenda process ensures that a research agenda starts with the priority agency questions”1.
Two practical rules follow for any organisation.
Keep the list short. Three or four outcomes can each be followed through properly. A longer list will be followed through for none of them, and the strategy will fall back on describing capabilities.
Take the outcomes in the business’s own words. If the corporate plan commits to reducing the cost of serving existing customers, that is the outcome. Rewriting it as an ambition to become insight-led loses the owner, and with the owner goes the person who will later defend the funding.
The way to find out what those outcomes really are is to ask. The Federal Chief Data Officers Council’s playbook advises new chief data officers to “interview stakeholders to identify their mission needs and challenges”, and to cover priority questions and data needs in those conversations2. The same document carries a warning that applies well beyond government: “Do not just start with data governance for the sake of data governance, partner on key questions to drive value”2.
Follow each outcome to the data behind it
An outcome is too large to connect to data directly. The connection runs through decisions. For each outcome, ask which recurring decisions determine whether it is achieved, who makes them, and what they would need to know to make them better.
The chain has four links.
- Outcome. Something the organisation has committed to and someone senior answers for.
- Decisions. The recurring choices that move the outcome: which customers to retain, where to hold stock, which claims to investigate.
- Data. What each decision needs to know, how current it has to be and how accurate.
- Capability. What must exist for that data to reach the decision in a usable state: sources, quality, integration, access, skills.
The table shows one outcome followed through. The example is illustrative and describes no particular organisation.
One outcome traced from business plan to data capability (illustrative)
| Link | Example | What it exposes |
|---|---|---|
| Outcome | Reduce avoidable customer loss in the retail division | Who owns the outcome and how it is measured |
| Decisions | Which customers receive a retention offer; when; through which channel | Who makes each decision and how often |
| Data | Contract dates, service history and contact preferences, current to the week, joined on one customer identifier | Whether that data exists, where, and in what condition |
| Capability | A reliable customer identifier across two systems; a weekly feed; an agreed definition of an active customer | The work to be funded, and what it depends on |
Working down the chain turns a general ambition into specific requirements. Working back up it is the test of alignment: every capability in the strategy should lead to at least one decision and one outcome. Capabilities that lead nowhere are not necessarily wrong, but they have to be argued for on other grounds, and the strategy should say so.
The US action plan makes a point here that saves money. Once the questions are known, “the data required to answer a priority agency question might already exist”1, in the organisation or outside it. Tracing from outcomes can show that the gap is access or quality, and that the new platform in the draft strategy was not the constraint.
The third link can fail on meaning before it fails on technology. If two functions count customers differently, no feed will reconcile them. Agreeing what a measure means is a task in its own right, taken up in how to define KPIs and metrics that mean the same thing everywhere.
Test the benefit before accepting it
Every proposed use of data arrives with a benefit attached. The claim can be made in good faith and still never have been examined. Four questions separate a benefit that can carry an investment from one that cannot.
Whose number moves? A benefit belongs to the person who owns the outcome. If no budget holder is prepared to have the improvement written into their own targets, the benefit is the data team’s estimate of someone else’s result.
What decision changes? Better information is worth something only where it leads to a different action. Ask what will be done differently, by whom, and how often. A dashboard that confirms what managers already do changes nothing.
What else has to be true? Data delivers a benefit only when other things are in place. A retention model needs someone to make the offers and a budget for them. Listing these dependencies shows how much of the benefit rests on things the data work does not control.
How will anyone know? There should be a measure, a baseline taken before the work starts and a date on which it will be checked. A benefit that cannot be observed afterwards was an assertion.
A shared definition of value makes these conversations shorter. The chief data officers’ playbook recommends that a data leader “create a standard definition for how your data and analytics strategy will return value” so that there is “a common understanding on what value creation means”2. Without one, each proposal is assessed on its sponsor’s terms.
The UK government’s data maturity framework shows how demanding this is. It places an organisation that has “a good understanding of the value of most of the data the organisation holds” and is “making attempts to quantify this” at the fourth of its five levels3. Quantified value is treated there as a mark of advanced practice. A strategy should be honest about which of its benefits are measured, which are estimated and which are judgement.
Choose between competing uses
With outcomes traced and benefits tested, there will still be more candidate uses than capacity. Four considerations help to rank them.
- Contribution. How directly the use affects a selected outcome, and how large the tested benefit is.
- Readiness. Whether the data, the owner and the people who must act on the result are in place now.
- Dependency. Whether the use needs foundations that do not yet exist, and whether building them would serve other uses as well.
- Reuse. Whether the data or capability created will be needed again.
These can be scored, and a scoring sheet is a useful record of the discussion. DII’s caution is against treating the total as the decision. A weighted score conceals the judgement inside the weights, and a ranked list invites argument about the third decimal place. It is better to use the four considerations to sort candidates into those that proceed, those that wait for a named dependency and those that are declined, and to write down the reason for each.
Dependency deserves particular attention, because it is where foundational work gets its justification. The National Audit Office noted in 2019 that government funding for projects to automate data feeds had “often been driven by new policies rather than fixing ongoing problems”4. Shared foundations lose out when every use is judged alone. Tracing shows which foundations several outcomes rely on, and that is the argument for funding them. How to order foundations and visible results over time is the subject of from data strategy to roadmap.
Decline work that has no anchor
Alignment has to be able to stop things. A strategy that can only add work has not aligned anything.
Unanchored proposals come in recognisable forms: a tool that a team wants to adopt, a dataset that might be useful one day, a capability that a peer organisation has announced. None is foolish. Each should be asked the same question: which selected outcome does this serve, through which decision?
Three answers are acceptable. The proposal traces to a selected outcome and joins the list. It traces to an outcome that was not selected, and is recorded for the next review. Or it serves a requirement that sits outside the strategy’s outcomes, such as a legal obligation, and proceeds on that basis with its own justification. A proposal that fits none of these is declined, and the record of why is kept.
The UK framework describes the weakest form of alignment as one in which an organisation “aligns data practices with work plans only where it is externally mandated or by chance rather than by design”3. Refusing unanchored work is what “by design” requires in practice.
Keep the chain visible
Alignment decays. Business plans are revised each year, owners move, and a capability that was justified by one outcome continues long after the outcome has been dropped.
Two habits keep it current. Record the chain, so that each funded item carries the outcome and decision it serves and the person who owns the benefit. Then review it when the business plan changes, not on the data function’s own calendar. The playbook’s advice to “analyze any existing and planned data investments to see if they are directly addressing your key business problems”2 describes that review, and it applies to work already under way as much as to new proposals.
The Data Strategy Alignment Guide provides a structure for the trace, with stakeholder interview prompts and an outcome-to-capability map. Where the result has to be put in front of an executive team, the One-Page Data Strategy Template holds the selected outcomes and the commitments against them on a single sheet.
When the chain is not kept visible, the risk is a strategy that everyone still supports and nobody can connect to current priorities. That condition, and the others like it, are examined in why data strategies stall after approval.
What alignment does not do
Two limits should be stated plainly.
Anchoring to current outcomes builds in current priorities. Work that would matter to a product not yet launched, or a regulation not yet in force, will not appear in the trace. A strategy needs a small, explicit allowance for that kind of preparation, argued on its own terms.
Alignment also says nothing about how well data must be managed once it is in use. That is a question of standards, ownership and control, which are set through governance and described in what data governance is and what a working programme contains. The US strategy’s own practices keep the two connected by asking agencies to “ensure that sufficient human and financial resources are available to support data driven agency decision-making”5. Alignment decides what the resources are for. It does not replace the disciplines that make the data fit to use.
Sources
- Federal Data Strategy (United States Government). Federal Data Strategy 2020 Action Plan. 14 May 2020.
- Federal Chief Data Officers Council (United States Government). CDO Playbook: Advancing the Federal Data Strategy. 2021.
- Central Digital and Data Office (UK Government). Data Maturity Assessment for Government: Framework. 27 March 2023.
- National Audit Office (UK). Challenges in using data across government (HC 2220). 21 June 2019.
- Federal Data Strategy (United States Government). Federal Data Strategy: “Overview” and “Practices” pages. 2019.
This article is general professional information. It is not legal or regulatory advice.