The Business Case for Data Management

Executive summary

Data management rarely loses funding because its value is absent. It loses because that value is never traced to outcomes a CFO already measures. Typical cases describe capabilities, such as a catalog or a single customer view, and assert benefits in general terms. Finance hears costs that are certain and benefits that are not, with no executive prepared to put the benefit in a budget. The remedy is discipline rather than salesmanship: every line of value should state what will change in the business, what that change is worth in measures the organization already tracks, and who owns the benefit.

This paper treats data as an enterprise asset in the management sense. Accounting standards generally keep internally generated data off the balance sheet, but data still has owners, carrying costs and a rate of decay, and a business case is the instrument that turns that stance into funded, owned and measured commitments.

• Data is an unusual asset: non-rivalrous, cheap to copy, subject to decay, valuable only in context, more valuable when combined, and a source of liabilities as well as value.
• Five value drivers (revenue, cost, risk and compliance, speed, and AI enablement) organize the benefits, and a value tree links enterprise objectives to the business changes and data capabilities that realize them.
• The cost of poor data is real but rarely itemized; rework, failed projects, decisions on wrong numbers and regulatory findings can usually be evidenced from the organization's own records.
• A six-step method builds the case: baseline, value hypotheses, benefits dependency mapping, total cost of ownership, phasing and sensitivity.
• Funding usually blends central funding for foundations with sponsor co-funding for use cases, and a benefits register with quarterly reviews keeps value visible after approval.

The closing sections show how to frame the case for finance and the board, the pitfalls that undermine data business cases, a readiness checklist for the investment committee, and the first steps, all of which can begin before any funding is approved.

The funding problem

Data management rarely loses funding because value is absent. It loses because value is never traced to outcomes a CFO already measures.

Three habits make data business cases hard to approve. Benefits are stated as capabilities, such as a catalog or a single view of the customer, rather than as business change. Costs are visible and immediate while benefits are diffuse, delayed and owned by nobody. And technology-led narratives invite comparison with every other platform request, a comparison data management usually loses because its benefits arrive through other people's processes.

A case that survives a finance review answers three questions for every line of value: what changes in the business, what that change is worth in measures the organization already reports, and who owns the benefit and will put it in a budget. The rest of this paper shows how to answer those questions with the organization's own evidence, and how to keep the answers honest after the money is approved.

Data as an enterprise asset

Treating data as an asset is a management stance, and it rests on properties that make data unlike plant, inventory or cash. Understanding those properties shapes both the value a case can claim and the costs it must include.

What makes data an unusual asset

Each property has a consequence for the case. Because data is non-rivalrous, shared platforms and reuse are economically sound: one investment can serve many uses at once. Because copies are nearly free, an estate without ownership fills with duplicates that each need storage, reconciliation and protection, and retiring them is a legitimate benefit. Because data decays, the cost of refreshing it belongs in the run costs. Because value is contextual, quality must always be defined relative to a use, and benefits must name the use. Because combination compounds value, master data, reference data and shared identifiers often justify themselves through several use cases at once. And because data carries liabilities, holding more of it is not automatically better; a case can legitimately claim value from disposal as well as from accumulation.

What the accounts say, and what management must do anyway

Finance leaders will reasonably ask why data should be managed as an asset when it does not appear as one. Under IFRS, IAS 38 Intangible Assets sets strict recognition criteria. Research costs are expensed; development costs can be capitalized only when an entity can demonstrate a set of criteria that includes technical feasibility, the intention and ability to complete and use the asset, probable future economic benefits and reliable measurement of cost. The standard expressly prohibits recognizing internally generated brands, mastheads, publishing titles, customer lists and items similar in substance, because their cost cannot be distinguished from the cost of developing the business as a whole. In principle, a separately identifiable data product built to a defined plan might meet the development criteria; in practice, the cost of collecting and maintaining data in day-to-day operations is expensed.

US GAAP reaches a broadly similar result. Costs of internally developing intangible assets that are not specifically identifiable, or that are inherent in a continuing business, are expensed as incurred (ASC 350-30), and data conversion costs are generally expensed even when the related internal-use software is capitalized (ASC 350-40). Under both frameworks, data purchased from a third party, or acquired in a business combination, can be recognized as an intangible asset when it meets the recognition criteria, because the transaction establishes a cost or a fair value; many data subscriptions, by contrast, are accounted for as services. Treatment depends on facts and circumstances, and standard setters review the guidance on intangibles from time to time, so the finance function should confirm the position with its auditors.

The absence of data from the balance sheet therefore reflects recognition rules, not a judgment about value. Management can still apply asset discipline: an inventory of what is held and who owns it, quality measured against use, visibility of carrying costs, and valuation for decision-making. Infonomics, the discipline popularized by Douglas Laney, then a Gartner analyst, argues for exactly this kind of management valuation, independent of financial reporting, and proposes several ways of valuing information, some financial and some not. This paper takes the same stance without proposing any accounting change.

An asset that appears on no balance sheet still has owners, carrying costs and a rate of decay. Managing data as an asset means acting on those facts.

The asset stance is not a plea for recognition on the balance sheet, and it does not depend on any particular valuation method. It is a commitment to behave toward data the way a disciplined organization behaves toward any asset it depends on: know what it holds, name who is responsible, understand what it costs to keep, measure whether it is still fit for its purpose, and decide deliberately when to invest, share or dispose. The business case is where that commitment meets money. Without it, the asset language remains a slogan, and data management continues to be funded as an overhead and judged as an investment.

Where the value comes from

Value drivers are the categories within which specific benefits are later quantified; they are not benefits themselves. A value tree then connects them to the business changes and data capabilities that produce them, and an honest account of the cost of poor data shows where the case can draw on evidence the organization already holds.

Five value drivers

Revenue growth comes from using data to personalize, cross-sell, launch data-enabled products and price with better information; each depends on data that can be joined across channels and trusted. Cost reduction is usually the most defensible driver because the pain is already visible: reconciliation effort, rework, duplicate pipelines and storage, and slow onboarding of new systems and partners.

Risk and compliance benefits should be described qualitatively unless the organization has its own history of findings and remediation costs to draw on; fines avoided are not a line item. Speed and agility capture time to data and time to insight, which translate into faster product cycles, fewer dependencies on individual experts and quicker responses to regulators and customers. AI enablement is often the driver executives recognize first, because stalled pilots have made the dependency on governed data obvious: models trained on owned, documented and permitted data reach production faster and with fewer surprises.

An illustrative value tree

A value tree links what the enterprise wants to what data management will build, through the business changes in between.

The top layer is the organization's own objectives, taken from its strategy. The second names the value drivers that serve them. The third layer is the most important and the most often skipped: the specific business changes that will realize the value, such as a new pricing process, retired manual reconciliations, self-service access for analysts or a model governance process. The fourth lists the data capabilities those changes require, and the bottom layer the foundations without which the capabilities will not hold: ownership and decision rights, policy, platform and skills.

Read top down, the tree asks what each objective needs; read bottom up, it traces what a capability enables. Benefits attach to business changes, not to capabilities: a catalog alone changes nothing. Every branch should end in a measure the organization already reports. The tree above is illustrative; a real one is built with business owners and will have fewer, more specific branches.

The cost of poor data

The cost of poor data is real but rarely itemized, which is why cases built on it sound vague. Its shape is captured by a familiar rule of thumb: the further a defect travels from the point where data is created, the more it costs.

The 1-10-100 rule comes from the quality management literature: preventing a defect at capture is cheaper than correcting it later, which is cheaper again than living with its consequences. It is useful for deciding where to invest, but it is never evidence in a case. The evidence comes from four cost pools that can usually be documented from the organization's own records.

• Rework and reconciliation. The effort that analysts, finance teams and operations staff spend repairing or matching data before they can use it; time studies and ticket queues reveal it.
• Failed or delayed projects. Migrations, integrations and AI pilots that stalled because data could not be trusted or traced; post-implementation reviews record them.
• Decisions on wrong numbers. Pricing, provisioning and forecasting errors discovered late, often visible in write-offs, credits and forecast variances.
• Regulatory findings. Remediation programs whose cost usually dwarfs that of the controls that would have prevented them.

Building the case step by step

Six steps take a case from pain points to a fundable proposal. They form a method, and the order matters.

1. Baseline. Collect incident, effort and finding data from the organization's own records to size current pain.
2. Hypotheses. State value hypotheses tied to named business objectives and the executives who own them.
3. Map benefits. Link each benefit to the business change that produces it and the data capability it depends on.
4. Cost it. Estimate people, process, platform and change costs, and include run costs to give total cost of ownership.
5. Phase it. Sequence investments so that early benefits help fund later ones, and show payback timing honestly.
6. Test it. List risks and assumptions, and show sensitivity to adoption, timing and the range of each benefit.

The baseline comes first because a case that begins with a vision has nothing to compare against. Incident logs, reconciliation effort, audit and regulatory findings and project post-mortems are evidence the finance function accepts, because the evidence already exists and finance did not have to take anyone's word for it. Value hypotheses are then stated against named business objectives, each with an executive who agrees to own the benefit. Benefits dependency mapping links each benefit to the business change that produces it and the capability that enables the change; a benefit with no change behind it is removed.

Costing covers people, process, platform and change, plus run costs after delivery, so that total cost of ownership rather than project cost is presented. Phasing sequences the work so that early, well-evidenced benefits help fund foundations, with payback timing shown as it is rather than as the sponsor would like it to be. Finally, risks, assumptions and sensitivity ranges make the case testable rather than merely persuasive.

Benefits dependency mapping

Benefits dependency mapping comes from the benefits management literature, notably the benefits dependency network developed at Cranfield School of Management by John Ward, Elizabeth Daniel and colleagues. It makes the middle of the value tree explicit: each chain starts with a data capability, passes through the business change that uses it, names the benefit produced, and ends in an objective the enterprise already pursues.

The discipline sits in the second column: if no process, decision or behavior changes, no benefit is claimed, however impressive the capability. The rows above are illustrative composites. Customer master data pays only when onboarding is redesigned around it. Quality rules on critical report data pay through retired manual adjustments, which is why the financial close is often an early benefit. A catalog with lineage pays when analysts stop raising tickets, and governed training data pays when model approval relies on it. The pricing chain shows that revenue benefits need a named business change too, and they are the hardest to attribute. The real map should be drawn with the business owners who will deliver each change and report the benefit.

Benefit types and how to measure them

A table of benefit types forces precision about measurement and ownership, and about which benefits release cash.

Cost avoidance, such as retiring manual reconciliations, is measured by time studies before and after and by what happens to the freed capacity; it releases cash only if headcount or contractor spend actually changes. Cost reduction from decommissioned pipelines and stores is measured in run cost and license lines removed from budgets, which finance can verify. Revenue uplift is the hardest to attribute and should use controlled comparisons where possible, with margin rather than gross revenue as the measure. Risk reduction is tracked through finding counts and remediation cost trends, and described qualitatively until the organization's own history supports numbers.

Speed is measured as request-to-access time and time to insight, and AI readiness as pilot-to-production time and avoided rework. Capacity benefits, where experts stop firefighting, are real but non-cash and should be labeled as such. Every row needs a named owner who will report it, and cash-releasing benefits should be presented separately from capacity, speed and risk benefits so that finance can see exactly what reaches the budget.

Costs, phasing and sensitivity

Finance leaders distrust cases that cost the project and ignore the commitment. This section covers total cost of ownership, the typical shape of benefits against costs, and the assumptions that move the answer.

Cost the whole commitment, not the project

The four build categories are people, process, platform and change. People costs include the time of data owners and stewards drawn from the business, not only the central team, plus backfill where staff are seconded. Process costs cover redesign of capture, quality control and access workflows and the policy and standards work behind them. Platform costs include tooling, storage, compute and licenses. Change costs include training, communication, adoption support and the temporary productivity dip that accompanies new ways of working. One-off items such as migration, cleansing backlogs and decommissioning should be stated honestly rather than hidden in contingency.

Total cost of ownership then adds the run costs for the whole planning horizon: subscriptions and support, ongoing stewardship and operations effort, refresh of rules and reference data, and the cost of retiring old systems netted against the savings they release. Presenting total cost of ownership over three to five years matches how finance typically appraises platform investments and removes a common objection before it is raised.

The shape of benefits against costs

The table below shows the shape most data management cases take when costed honestly. The values are illustrative and indexed so that year-one cost equals 100; they are not benchmarks.

Costs are front-loaded because platform, cleansing backlogs and change effort arrive before any business change, then settle toward a run rate once foundations are in place. Benefits lag because they follow adoption and process change rather than go-live, and they grow as more use cases draw on the same capabilities. On these values, annual benefits exceed annual costs in year two, but cumulative benefits overtake cumulative costs only late in year three: that is the payback point a CFO will calculate, so the case should show it rather than leave finance to infer it.

Phasing changes the shape. Early, well-evidenced benefits such as retired reconciliations, sequenced ahead of larger platform spend, shorten payback and help fund the foundations that later benefits require. Finance will apply its own discount rate, so the case should present undiscounted figures with the timing of costs, benefits and decision points made explicit.

Sensitivity: which assumptions move the answer

Risks, assumptions and sensitivity turn a persuasive case into a testable one. The first step is to list every assumption behind the numbers: adoption rates, the timing of each business change, the size of revenue effects, team size, platform run cost, license terms and sponsor availability. The matrix below then sorts them by how much they move the net benefit and how uncertain they are.

High-impact, low-uncertainty items such as platform run cost are fixed in the case from quotes and reported as variances. High-impact, high-uncertainty items, typically adoption and timing, drive the sensitivity analysis: show net benefit across a range, state the adoption level at which the case breaks even, and name an owner for each. Low-impact items go into the assumptions log, with a review trigger for those that are uncertain. Delivery risks such as the loss of a sponsor, migration difficulty or dependence on another program belong in the same register, with mitigations. A case that shows its own weak points earns more trust than one that shows none.

Funding and value realization

Approval is not the end of the case. How the program is funded shapes how it behaves, and how benefits are tracked after approval decides whether the next funding request is believed.

Four funding models compared

No single funding model serves a data management program for long, so the choice is usually a blend. Central funding from an enterprise budget, typically held by the chief data officer, protects foundations such as governance, the catalog and master data, but it reads as overhead and generates little pull. Chargeback recovers platform and service costs from consumers by usage or allocated share; it makes consumption visible, yet it can deter the very reuse the program wants and create allocation disputes. Showback, which reports consumption without billing, is a sensible precursor. Product-based funding gives durable teams a budget per data product, which stabilizes capacity but requires product management maturity and portfolio review. Use-case co-funding creates the strongest pull and clear benefit owners, but starves foundations if used alone.

Most organizations settle on central funding for foundations, sponsor co-funding for use cases, and showback before any chargeback. The split matters because foundations benefit everyone and no one in particular: no single use case will pay for them, yet every use case fails without them.

Value realization after approval

Approval is where most business cases stop being read. Value realization keeps them alive, and it is organized around a single artifact.

The benefits register records every benefit from the case with its owner, baseline, target, measure and expected timing. Leading indicators show whether the business change is actually happening, for example adoption of a new onboarding process, catalog usage by analysts or quality rules running in production; they move early and warn when benefits are at risk. Lagging indicators confirm that the benefit arrived: effort hours removed, run cost lines retired, findings closed, time to data reduced or margin attributed through a controlled comparison.

Benefit owners report against the register at a quarterly review chaired by the sponsor, with the finance business partner present, so that the figures are challenged by the people who will account for them. Re-forecasting is expected rather than embarrassing: benefits that will not land are retired openly and funding is redirected to those that will. A register shared across programs also prevents the same freed capacity from being claimed twice.

Presenting to the CFO and the board

The same case can be accepted or rejected depending on how it is framed. This section covers framing and language, the pitfalls that lose the room, and a readiness check before the investment committee.

How to frame the case

Present data management as an investment in the operating model, with technology as one cost line, so that it is compared with business change rather than with other platforms. Describe it as a portfolio of business changes, each with a sponsor and a measure, and express risk benefits in the board's own risk language rather than as abstract governance. Offer a phased commitment with decision points instead of a single large request, and invite finance to measure the result.

Use the vocabulary finance already uses: baseline, run rate, payback and sensitivity, with effort hours and run costs removed rather than efficiency gains. Avoid the habits that lose the room: a return figure more precise than the evidence supports, a technology-led narrative, and fines avoided or revenue at risk presented as savings. Any experienced finance reviewer will also find benefits with no owner and capacity counted twice, and one such discovery discounts the whole case.

Pitfalls that undermine a data business case

• Starting from the solution. The case justifies a platform instead of a set of business changes, so the discussion becomes a tooling comparison and the changes that create value are never named.
• Double counting. The same freed capacity is claimed by several benefits, or has already been claimed by another program; a shared benefits register prevents it.
• Treating capacity as cash. Hours saved become savings only when budgets or headcount change; otherwise they are capacity redeployed and should be presented as such.
• Ignoring run costs and the productivity dip. The case looks cheaper than it will be, and credibility suffers at the first budget review.
• Single-point estimates with no baseline. The case can be neither tested before approval nor tracked after it.
• Reporting activity after approval. Catalogs populated and rules written are reported instead of benefits realized, hiding whether value is arriving.

Readiness checklist

Where to start

The first steps can start before any funding is approved, and each produces evidence the case will need.

1. Build the baseline. Pull twelve months of incident, effort and finding data. It usually reveals pain that nobody has totaled.
2. Test the value. Run a value-hypothesis workshop with three business sponsors and a finance business partner to produce the first testable statements of value and identify who will own each benefit.
3. Draw the chains. Draft the dependency map and the benefits register, with chains from capability to business change to benefit and named owners and measures attached.
4. Cost and test. Cost total ownership over the planning horizon and test the sensitivity, producing numbers finance can challenge.
5. Agree the terms. Agree the funding model and the quarterly review cadence with the CFO, which sets the terms on which the program will be judged.

The case is won on evidence already held, and kept on benefits the business agrees to measure.

Glossary

Business case

A testable proposal for investment that states what will change, what the change is worth, what it will cost and who owns the benefit.

Asset stance

Managing data with the disciplines applied to any important asset (inventory, ownership, carrying cost, fitness for use and deliberate investment or disposal), whether or not it is recognized in the accounts.

Intangible asset

In accounting, an identifiable non-monetary asset without physical substance; IAS 38 and US GAAP set strict criteria for recognizing internally generated ones.

Infonomics

The practice of managing, measuring and monetizing information as an asset, popularized by Douglas Laney.

Value driver

A category of value, such as revenue, cost, risk, speed or AI enablement, within which specific benefits are quantified.

Value tree

A structure linking enterprise objectives to value drivers, business changes, data capabilities and foundations.

Value hypothesis

A testable statement that a specific data-enabled change will move a named business measure, owned by an executive.

Benefits dependency map

A chain from data capability to business change to benefit to objective, showing what each benefit depends on.

Cash-releasing benefit

A benefit that changes a budget line, such as retired license costs or attributed margin, as distinct from capacity, speed or risk benefits.

Total cost of ownership (TCO)

Build costs plus run costs over the planning horizon, net of savings from retired systems.

Payback period

The time until cumulative benefits equal cumulative costs.

Sensitivity analysis

Testing how the net benefit changes as key assumptions vary, including the break-even level of adoption.

Benefits register

The record of every benefit with its owner, baseline, target, measure and timing, reviewed after approval.

Showback and chargeback

Reporting consumption of a shared service to the units that use it (showback), or billing them for it (chargeback).