The Problem Picks the Sponsor, and the Budget Sets the Road

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

Most of the roadmaps I have reviewed opened with a vision. The order that implies, as I read it, is to say where the organisation wants its data to be in five years, then lay out the road that gets it there, then go and find the money. In none of them did the money arrive in that order.

Some published playbooks still put the vision first. Google Cloud's 2025 guide to building a data strategy makes its first step "Establish your vision, AI and business priorities", and calls the vision "a guiding principle for all subsequent work" [1]. The published guides are mixed, though, and even Google's first step ties the vision to business priorities. AWS's prescriptive guidance on a data strategy roadmap tells the reader to start with executive sponsorship and business interviews, and names no vision step [2]. Teradata's 2021 framework starts from "already-planned and already-funded business initiatives" and sets the vision in the third and last of its stages [3].

Asked what order gets an enterprise from a vision to a funded roadmap, I did not start with the vision at all:

First the problems. Always the problems. The problems lead to the Sponsor and the Sponsor defines the road map. You can try to do it in other ways, but you’ll almost always come back to solving the problem first. Then figuring out who that helps. How much that helps them and how much that impacts their budget—and how large that budget is to begin with—almost always defines how long your road can be.

That is a sequence, and each link in it does something the vision cannot. A problem has an owner, because somebody's operation is hurting and somebody's budget is paying for the hurt. The owner of the worst problem with the deepest budget behind it is the sponsor. The sponsor, not the data team, decides what the first stretch of road has to fix, because that is what the money is for. And the length of the road is set by arithmetic the vision never touches: how many people the fix helps, how much it helps them, how much of their budget it moves, and how large that budget was in the first place.

Here is the narrow claim I will defend. A data roadmap that is going to be funded is almost always built from the problem backwards, not from the vision forwards, and its length is bounded by the budget it serves, not set by the ambition it states. That rules out a good deal of what gets written under the heading of data strategy: a roadmap whose phases were drawn before anyone with a budget had agreed they had the problem the first phase solves, and a five-year horizon set by the vision rather than by the money.

It also has an uncomfortable consequence for master data management, which I will come to. In the current market, MDM rarely gets onto that road under its own name.

What a vision statement is for

If the vision is not the first step, what is it? I put it somewhere else entirely:

Vision Statements are Marketing for the Review Boards and the Prospectuses, but, ultimately, they have very little to do with the actual implementation.

The audience is the point. A review board and a prospective investor are judging the work, not doing it; neither is going to build anything.

The investor's side has a written standard. The Securities and Exchange Commission's rule asks a registrant to describe "the business done and intended to be done by the registrant and its subsidiaries" and lists among the topics a filer may need to cover "material changes to a previously disclosed business strategy" [4]. The annual report built on it, the commission's investor site says, "offers a detailed picture of what the company does, and the risks it faces" [5]. The filings show a description of the business and of any material change of strategy; that a vision statement is marketing rather than a plan is my own account, not theirs.

Richard Rumelt made the same distinction from inside strategy. The core of a good strategy, in his account, begins with a diagnosis, "an explanation of the nature of the challenge," followed by a guiding policy, "an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis," and then "coherent actions" [6]. He is blunt about what happens when the diagnosis is skipped: "If the challenge is not defined, it is difficult or impossible to assess the quality of the strategy" [6]. And he names the template behind many corporate vision documents, the one that says "Fill in your vision of what the school/business/nation will be like in the future" [6]. His diagnosis is my problem, stated in a strategist's vocabulary. A data vision that names no challenge cannot be judged, and a roadmap drawn from it cannot be priced.

I concede that a stated purpose is not worthless. Sebastian Desmidt, Anita Prinzie and Adelien Decramer pooled twenty years of studies on mission statements and reported "a small positive relation between mission statements and measures" of financial performance, with large differences depending on how each study measured performance [7]. Mission statements are a close cousin of the vision statement, not the same thing, and the effect is small, but it is not zero. A stated direction may help people pull the same way. In the sources I read, nothing shows that writing the direction first is what gets a programme funded.

Kotter's original eight steps form the vision in the third step, not the first. John Kotter's eight steps begin with "Create A Sense of Urgency" and "Build A Guiding Coalition," and only then "Form A Strategic Vision" [8]. Kotter's urgency is not quite my problem; his page frames it as inspiring people to act "to achieve a bold, aspirational opportunity" and as building momentum toward "a compelling (and clear) vision of the future" [8], which leans toward the upside. But the order of the steps is the point. Kotter's firm now describes that sequence as the "linear" original and has evolved it into a "dynamic" model, but its page still lists urgency and a coalition before the vision. Before the vision, somebody has to feel that something must change, and somebody with weight has to commit. In my sequence, those two are the problem and the sponsor.

The strongest direction-first data strategy I know of is public. The United States Federal Data Strategy was built from a mission statement that "articulates the intent and core purpose of the Strategy," ten principles, forty practices, and an "Annual Action Plan" to "Specify measurable activities to implement the practices and that are the priority for a given year" [9]. Read carefully, even that design hands the road to a yearly plan, and the yearly plan is where priorities enter, and on the argument here budgets follow them. The mission states the purpose. The annual plan decides how far anyone travels this year.

None of this means an enterprise strategy is decoration. I have called an enterprise strategy a statement of goals, values and how success is measured, and the yardstick that project proposals are later measured against, at least in consistent organisations. That is a real job. But a yardstick measures roads somebody else has already decided to build. It does not build them, and it does not pay for them. Write the vision; write it last, for the readers it serves, and do not mistake it for the first step of the road.

Problems first, because problems have owners

Why does the problem come first? Because it is the only thing in the sequence that already has a budget attached. A vision belongs to everyone, so it belongs to no one's cost centre. A problem belongs to whoever is paying for it now: the finance team re-keying customer records before month end, the sales operation that cannot see a customer's other accounts, the supply chain that orders the same part under three numbers. Each of those is a line in somebody's budget already. The problem is how a data roadmap finds its way into a budget that exists.

The research on sponsorship puts the sponsor at the top of what makes projects succeed. Prosci, a change-management firm whose benchmarking reports go back to 1998, reports that "Sponsorship has been number one on the list of top contributors in all of Prosci's benchmarking reports since 1998," and that projects with an extremely effective sponsor "met or exceeded objectives more than twice as often" as projects whose sponsor was rated very ineffective [10]. The Project Management Institute's 2017 survey of 3,234 project professionals found that "Actively engaged executive sponsors continue to be the top driver of whether projects meet their original goals and business intent," while 62% of projects on average had one [11]. Both are self-reported surveys by bodies that sell training in the thing they measure, and both measure delivery rather than funding. I read them as consistent with the sequence, not as proof of it.

What neither tells you is how a sponsor is won. Prosci says which leader a change needs and that a sponsor may enlist others; neither says what makes an executive back the work. My experience is that a sponsor is found through a problem, not recruited to a cause. My own account of the ask to a peer executive is that it is a sales pitch more than a request: you have to show them that their priorities are best served by backing the project, and if you can fold one of their current production problems into it, you are well on the way. That is the sequence again, at the scale of one meeting. The problem is what turns an executive's agreement into an executive's money.

It also explains why a project with a vision and no problem can collect sponsors and still go nowhere. Executives will endorse a vision freely, because endorsing it costs nothing. They fund problems, because a problem they fund is a cost they stop paying.

The sponsor draws the road, and the budget measures it

Once the sponsor has the problem, the sponsor defines the roadmap. That sounds like a loss of control to a data team, and in one sense it is: the first phase is whatever fixes the sponsor's problem, not whatever the data architecture would build first. But it is almost always the arrangement in which the first phase gets paid for, and a first phase that delivers is what earns a second.

What sets the length? I named four things in sequence: who the fix helps, how much it helps them, how much of their budget it moves, and how large that budget is to begin with. Put plainly, and as a pattern from my own record rather than a measurement, a road is as long as the budget behind it can carry. A problem that touches one department with a small budget buys a short road, however strategic its data. A problem that sits across the operating budget of a large division buys a long one, even if the data work is modest.

Two published ideas make that arithmetic sharper, and one of them cuts against it. The first is cost of delay. The Scaled Agile Framework prioritises work with Weighted Shortest Job First, "estimated as the relative cost of delay divided by the relative job duration," from inputs it lists as "relative user and business value, time criticality, risk reduction and/or opportunity enablement, and job size," and it quotes Don Reinertsen: "If you only quantify one thing, quantify the Cost of Delay" [12]. That is a disciplined version of asking who a project helps and how much. It gives a data team a way to put its problems in the same units as everyone else's.

The second idea is a warning. Bent Flyvbjerg, studying megaprojects, describes how they are "systematically subject to 'survival of the unfittest,'" "explaining why the worst projects get built instead of the best" [13]. His point is that the way projects are selected can favour the wrong ones. His evidence is about megaprojects, not data programmes, and I would not carry his numbers across. What I take from it is the warning. In my sequence, funding follows the perceived size of the issue, and the arithmetic of the road is real arithmetic, done on estimates that everyone at the table has a reason to inflate.

A third frame helps a data team see which problems fund themselves. Leandro DalleMule and Thomas Davenport split data strategy into defence and offence: "Data defense is about minimizing downside risk," while "Data offense focuses on supporting business objectives" [14]. On my reading, defensive problems, the regulator's finding and the failed audit, are short to explain and often well funded, because the downside is visible. Offensive problems, the revenue a better customer view might bring, are easier to promise and harder to price. A roadmap usually needs at least one of each, because a defensive problem pays for the foundation and an offensive one pays for the next phase.

And the sponsor has to stay. I have said that a change of sponsor is survivable and the absence of one is not: when a sponsor is replaced by somebody who has a different priority, the project needs another sponsor willing to fight, or protection from higher up, or it ends. A roadmap's length is set by the budget, but its life is set by the person who controls that budget still wanting the problem solved.

Where roadmaps die

Research can show that sponsorship matters for delivery, and Flyvbjerg's study of megaprojects warns that selection can favour the wrong projects; where a funded roadmap actually stalls is where the warrant becomes my own record, and it is pattern, not law.

Asked where they die, I gave two causes and then the reason behind both:

They usually die because the Sponsor doesn’t have enough pull or the problem they’re attempting to solve isn’t perceived to be bigger than the problem being solved by a different Sponsor through a different project. All of this ties back to how projects get funded in the first place: they need to be perceived to address a sufficiently large enough issue for the Enterprise to allocate the funds. It’s extremely simple, but simultaneously the hardest thing in Business.

The two causes are different failures, and a playbook has to treat them differently. The first is weight. A sponsor who cannot carry the problem to the people who allocate funds cannot carry the road either, however real the problem. The remedy is not a better slide; it is a second sponsor whose budget the same problem touches, or a sponsor higher up. The second cause is comparison. A roadmap is never judged alone. It is judged against the other sponsor's problem, in the other project, competing for the same money in the same cycle. A data roadmap that is the right thing to do can lose to a warehouse expansion that is merely the more visible thing to do.

Here is how losing the comparison goes, in a hypothetical of mine, not a case I watched; real examples risk embarrassing clients, former clients and friends. The figures are an illustrative standard, not data; the comparison between the two returns matters more than the exact numbers. At Max Corp, the Widget department produces 20% of the revenue. It wants a project that costs 2% of corporate revenue and raises its productivity by 10% (an efficiency gain, which usually means more throughput and shorter timelines), with a return in one year. The Thingamabob department produces 40% of the revenue and wants a project that costs 3% and raises its productivity by the same 10%, with a return in nine months. Without strong backing from senior leadership, the Thingamabob project can ride its numbers to a funded project and the Widget group will have to wait another year. The number does not always get you the deal, but it can get you the backing that does. The Widget group could bring in the marketing division and its chief marketing officer to say that Widgets will grow by 100% over the next five years, and that backing can change how the numbers are viewed, because the executives who decide are guided by numbers and not bound by them.

Other things equal, cost against benefit, the return on investment, drives the decision; executive and business-group buy-in are the other things, and they can change it. Without that backing, the gap between the returns sways the decision, so the balancing act is to bring enough clout to overcome it; and in some environments, on some projects, it does not matter how much clout is brought to bear, because the better return wins. My rule for the board room is short:

Make a good argument, have solid numbers and get strong backing. You need all three to succeed in the board room.

The first cause, weight, has a second face, and the same hypothetical shows it: a road can be too heavy for any sponsor's pull. In my judgement, raise Max Corp's numbers by an order of magnitude and neither is likely to be funded. My heuristic is that a return beyond about ten years is rarely funded outside industries stable enough to be predictable across a generation, and that a fast-moving industry demands a shorter return because it cannot be predicted. When disruptors enter a market, executives are forced to reconsider longer-return projects. That is a heuristic of mine, not a measurement and not a case I watched.

That is why I called it simple and the hardest thing in business in the same breath. Simple, because the rule fits on one line: fund the problem that is perceived as biggest. Hardest, because every word in it is contested. Perceived by whom? Biggest against what? The data team rarely gets to decide either.

Gartner's analysts reached a version of this from the other side. In February 2024 the firm predicted that "By 2027, 80% of data and analytics (D&A) governance initiatives will fail due to a lack of a real or manufactured crisis," and its analyst Saul Judah said that "A D&A governance program that does not enable prioritized business outcomes fails," [15]. That is a forecast, and the release states no method behind the number. But notice the word "manufactured". A crisis that has to be manufactured is a problem that has not yet been perceived as big enough. Gartner's forecast fits the comparison I am describing, and it admits that the perception sometimes has to be built.

I would put one guard on that. A manufactured crisis that collapses under its first question costs the sponsor their weight, which is the first cause of death. Perception can be helped by pricing the problem honestly in the owner's terms; it cannot safely be invented. The roadmap that survives comparison is the one whose problem is both big and provably so.

Drawn as the tests a sponsored roadmap has to pass, and where each failure leads:

Can master data be funded for its own sake?

Before I assess how master data management gets funded, here is the interest behind this section. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Our services revenue depends on this category of software being bought, and on exactly the kind of MDM project this section describes being funded. That interest runs toward any advice that gets MDM funded, so weigh what I say in favour of funding it below what I say against. One source below is Profisee's own case-study page, published to sell its product, and our interest runs toward it; another is a survey published by Informatica, which sells MDM in competition with Profisee, and our interest runs against it, though nothing here criticises it.

Asked whether master data can be funded on its own merits, I said mostly not:

Unless you’re dealing with a Company that’s currently experiencing acute pain from problems with their Data that can be directly traced to Master Data issues, you’re not likely to be able to get MDM funded for its own sake. In the current market, making data ‘AI ready’ is the best and (almost) only path to success.

That answer has an exception and a rule. The exception is acute pain traceable to master data. The rule is that, absent such pain, the road MDM travels in the current market is mostly labelled AI.

The rule is visible in what buyers say. Gartner reported in February 2025 that "Sixty-three percent of organizations either do not have or are unsure if they have the right data management practices" for AI, according to its survey, and predicted that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data" [16]. The release is not consistent about its own survey, giving 1,203 respondents in the body and 248 in its summary [16], so I lean on the prediction's direction rather than its decimals. Informatica's CDO Insights 2025 survey found that 86% of data leaders expected their data management investment to rise in 2025, and that 44% named data readiness for generative AI as the main reason [17]. Wavestone's executive survey of data and AI leaders found 87.9% calling data and analytics investment a top organisational priority and 89.6% saying generative AI investment was rising [18]. Money for data management is moving, and a large share of it now moves under the AI label.

Acute pain from data problems is visible in public too. On Unity Software's first-quarter call in May 2022, its chief executive described two issues, a fault in its platform that reduced the accuracy of one of its tools and the loss of "the value of a portion of our data, training data due in part to us ingesting bad data from a large customer," and estimated the combined "impact to our business of approximately $110 million in 2022" [19]. In July 2024 the Federal Reserve fined Citigroup $60,625,620, finding "ongoing deficiencies in data quality management and ineffective compensating controls" after a 2020 order had required the bank "to submit a plan to enhance its data quality management program" [20]. Neither is a master data failure in the narrow sense: Unity's data loss was training data for a machine-learning tool (its estimate also covers a platform fault), and Citigroup's was data quality management across a bank. But they are the kind of pain that funds data work without a further argument, because the cost is already on the books.

Pressed on which of those two I hold, funding MDM through AI-ready phases or admitting that MDM beyond AI's reach rarely gets funded, I took both:

A and B are both viable. MDM qua MDM on a green field is almost never a 'win.' This may be changing given the number of horror stories and the movement of directors between companies who carry their own stories, but MDM is always better paired with another offering that provides direct value to the business--such as AI adoption and increased process automation.

The hedge on "may" is deliberate, and I would keep it. Stories of data failure travel with the people who lived through them, and those people move. MIT Sloan reported in 2022 that "The average tenure of a chief data officer is 30 months" [21]. Chief data officers hold the role for about thirty months on average, short enough that one may arrive at the next company carrying the last failure. If enough of them do, a board may one day fund master data because somebody in the room remembers what its absence cost. I see the possibility. I will not promise it, and nothing in the evidence above shows that it has happened yet.

So what does the honest playbook say about MDM? It accepts a complaint I have made before, without pretending the complaint has a cure. I have complained that the MDM roadmap ends up existing only to enable the AI roadmap, and that only that part of it gets built. The sequence explains why. The AI initiative has the problem the sponsor perceives, so it has the sponsor, so it draws the road, and MDM travels as far as that road runs. The part of master data that no AI use case needs has no problem attached on that road, and so no place on it.

That is not an argument against the AI path. It is an argument for walking it with open eyes. I have argued that MDM is an enabler rather than a transformer, and that it should stand beside other initiatives as a deliverable multiplier rather than "lead" a transformation. Inside a larger initiative it shares the initiative's fate, and its failures can tar MDM with problems it did not cause, yet that is sometimes the only way to get it funded at all. The AI path is the larger initiative of the moment. Gartner predicted in July 2024 that "At least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025," "due to poor data quality, inadequate risk controls, escalating costs or unclear business value" [22]. That deadline has passed; the figure is cited as what Gartner forecast, not as an outcome. A study from MIT's Project NANDA, built on interviews with representatives of 52 organisations, 153 survey responses and a review of over 300 public initiatives, reported that "95% of organizations are getting zero return" from generative AI, and put the cause not in model quality or regulation but in tools that "don't learn and don't integrate well into workflows" [23]. If MDM rides only on AI, it inherits those odds.

What reduces the odds is the second half of my remedy: pair MDM with direct value that does not depend on a model working. Process automation is the plainest case. What even sceptics accept, in my account, is a proof of concept that cut a downstream process from days to hours, because the sceptic recognises the process. There is also a newer argument that turns AI's cost into MDM's case. I have had discussions about limiting MDM's own use of AI because master data touches too many records to afford the tokens; the same arithmetic runs the other way, because deduplicating at the source can cut the number of records sent to downstream AI processes.

Evidence that master data is funded without AI would cut against the rule, and one vendor's public showcase offers a check: of the 24 case studies listed on the first page of Profisee's case-study index, read on 18 October 2026, one is framed around AI, and most are framed around operational efficiency or a revenue use such as cross-selling to a single customer view [24]. The pages are undated, many plainly predate the current AI wave, and a vendor chooses which stories to tell. Even so, that leans against the strong form of the rule, that AI is almost the only path, across the life of the category. What it does not show is MDM bought for its own sake: almost every story names a business result the master data served, which is the pairing I recommend, not an exception to it. The rule that survives is narrower and still bites. In the current market, a master data project proposed with no business result attached, on the strength of cleaner data alone, almost never gets on the road.

Drawn as a decision, the rule and its exception look like this:

A playbook, in the order the money moves

Each step follows my interview answers, with analysis filled in between them; where a step also rests on a source, it cites it.

Here is the order the money moves in, set beside the order a vision-first roadmap implies:

1. List the problems before the capabilities. Write down the operational problems the data causes, each in the terms of the person paying for it: hours lost, revenue missed, findings outstanding. This is the step a vision-first order leaves until after the vision, and Rumelt's diagnosis is its warrant [6]. Price each one. The approval tell I have described applies here, and it is this: in an ordinary project the first question is almost always what it will cost, so the problem has to plainly cost more than the answer to that question.

2. Let each problem find its owner. For every problem, name the executive whose budget is paying for it now. That executive is the candidate sponsor. If no one's budget carries the problem, it is not yet a problem the enterprise perceives, and no roadmap will carry it either.

3. Choose the sponsor by weight, and recruit a second. Of the candidates, pick the one with the most pull over the money and the biggest problem, because those are the two things my record says roadmaps die without. Then pitch a second sponsor by folding their problem into the first phase. One sponsor is a single point of failure. Write executive and business-group buy-in into the funding plan itself: with other things equal, cost against benefit decides, and their backing is what can change that.

4. Let the sponsor define the first phase. The first phase fixes the sponsor's problem. If the data architecture wants something built first, it must be built inside that phase or justified by it. A first phase that delivers is the strongest argument for the second.

5. Size the road with the four questions. For each phase, ask who it helps, how much, how much of their budget it moves, and how big that budget is. Cost of delay is a useful common unit for the answers [12], provided everyone remembers that the estimates come from whoever wants the money, and Flyvbjerg's warning, from megaprojects, that selection can favour the wrong projects [13]. The answer is the length of road the phase can fund, not the length the architecture would like.

6. Put master data on the road as a passenger with a ticket. Fund MDM inside the phases that need it: AI readiness where the AI initiative is real, process automation where the sceptics can see the process. Name the business result each MDM phase serves. Do not promise the depth beyond what those phases need will be funded; in my record it rarely is.

7. Refuse completion goals. "AI-ready" is a direction, not a finish line. I have called any goal tied to being done, fully "AI ready" data sets among them, a deliberate falsehood, and Gartner's own analyst says that "AI-ready data is not 'one and done.'" [16]. A roadmap that promises completion has promised the one thing nobody can deliver, and it hands the sponsor's opponents their argument.

8. Write the vision last. Once the problems, sponsors and phases are known, write the vision for its real readers: the review boards, and the investors who read the prospectus. It will be truer for coming last, because it will describe a road someone is paying for. The roadmaps I write open with an executive summary, objectives and deliverables, and I leave the vision statement for the sponsor to add.

None of the eight is a guarantee: a playbook can order the work, but it cannot make a problem look bigger than it is to the people holding the budget.

What the order changes

The usual brief for this work asks for a compelling vision and a roadmap. My answer is that the compelling part is the problem, and the vision is the summary written once the problem has found its money. Kotter's original eight steps, read for their order, put urgency and a coalition before the vision [8]; Rumelt puts the diagnosis first [6]; even a direction-first federal strategy hands each year's road to an annual action plan [9]. Of the two direction-first sources I cite, Google's guide ties the vision to business priorities [1] and the federal strategy ties its mission to a yearly plan [9]; the others begin elsewhere: AWS with executive sponsorship [2], Teradata with funded initiatives [3], Rumelt with the diagnosis [6] and Kotter with urgency [8].

What my record adds is where the sequence breaks. Roadmaps usually die when the sponsor lacks the pull, or when the problem loses the comparison with somebody else's. And master data, in the current market, gets on the road as part of making data ready for AI, or as part of a process that sceptics can watch speed up, and, in my record, seldom any other way. The honest playbook funds MDM through those phases, pairs it with value a sponsor can see, and tells the sponsor plainly that the depth beyond them will probably not be funded. That still rules something out: a roadmap that promises the master data foundation for its own sake, sold on a vision, with no problem and no sponsor attached. In my record, that roadmap almost never wins.

References

[1] Andre Walker-Upshur and Ram Katuri (Google Cloud), "Building a data strategy for the AI era," Google Cloud Transform, 14 May 2025. Read 2026-10-19. A vendor's guide, cited as a published example of a playbook that puts the vision first. https://cloud.google.com/transform/building-a-data-strategy-for-the-ai-era

[2] Amazon Web Services, "Data strategy roadmap," in "Creating a data strategy on AWS that supports your company's goals," AWS Prescriptive Guidance (undated page). Read 2026-10-19. A vendor's guide. Cited for where it starts (executive sponsorship and business interviews) and for naming no vision step. https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-aws-data/roadmap.html

[3] Teradata, "Building a roadmap for enterprise data and analytics – a framework," 25 July 2021 (the page metadata gives 2 December 2021). Read 2026-10-19. A vendor's guide. Cited for the phrase quoted in the body and for the stage, the third of three, in which it sets the vision. https://www.teradata.com/insights/data-analytics/building-a-roadmap-for-enterprise-data-and-analytics

[4] Securities and Exchange Commission, 17 CFR § 229.101 (Item 101 of Regulation S-K), "Description of business," Electronic Code of Federal Regulations, as amended 85 FR 63759 (8 October 2020). Read 2026-10-18 on eCFR (paragraphs (a), (a)(1) and (c) checked). Cited for the two passages quoted in the body. https://www.ecfr.gov/current/title-17/chapter-II/part-229/subpart-229.100/section-229.101

[5] U.S. Securities and Exchange Commission, Investor.gov, "How to Read a 10-K" (undated page). Read 2026-10-18. Cited for the phrase quoted in the body. https://www.investor.gov/introduction-investing/getting-started/researching-investments/how-read-10-k

[6] Richard Rumelt, "The perils of bad strategy," McKinsey Quarterly, 1 June 2011. Read in full 2026-10-18. Cited for the kernel (diagnosis, guiding policy, coherent action), the sentence on an undefined challenge and the vision template quoted in the body. https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/the-perils-of-bad-strategy

[7] Sebastian Desmidt, Anita Prinzie and Adelien Decramer, "Looking for the value of mission statements: a meta-analysis of 20 years of research," Management Decision 49, no. 3 (2011): 468–483, doi:10.1108/00251741111120806. Read 2026-10-18 at the abstract only; the full text is paywalled. Cited for the finding quoted in the body and the effect of how performance was measured. https://www.emerald.com/insight/content/doi/10.1108/00251741111120806/full/html

[8] Kotter Inc., "The 8-Step Process for Leading Change" (undated page; page metadata shows a modification of 14 September 2026). Read 2026-10-18 and again 2026-10-19. The model's original article (Harvard Business Review, 1995) was not read. Cited for the order and names of the first three steps, the two step-1 phrases quoted in the body, and the page's note that the firm has evolved the linear 8 Step into a dynamic model. https://www.kotterinc.com/methodology/8-steps/

[9] Federal Data Strategy, "Overview," strategy.data.gov (undated page; the page lists the 2020 and 2021 action plans and says the site is being retired). Read 2026-10-18. Cited for the four components and the passages quoted in the body. https://strategy.data.gov/overview/

[10] Tim Creasey, "Primary Sponsor's Role and Importance," Prosci, updated 7 August 2026. Read 2026-10-18. Self-reported benchmarking by a change-management firm; the underlying reports were not read. Cited for the two findings quoted in the body. https://www.prosci.com/resources/articles/primary-sponsors-role-and-importance

[11] Project Management Institute, Pulse of the Profession 2017, "Transforming the high cost of low performance" (9th Global Project Management Survey, 2017). Read 2026-10-18 in a copy of the report hosted by the State of Montana's IT services division; fieldwork dates are not stated. Cited for the sample size, the finding quoted in the body and the 62% average. https://sitsd.mt.gov/_docs/ITMC/SMPMAW/2017.08.23/pulse-of-the-profession-2017.pdf

[12] Scaled Agile, "Weighted Shortest Job First," SAFe Framework (undated page; partly behind a sign-in). Read 2026-10-18 as far as it is public. Cited for the definition, the inputs and the Reinertsen line quoted in the body. https://framework.scaledagile.com/wsjf

[13] Bent Flyvbjerg, "What You Should Know About Megaprojects, and Why: An Overview," doi:10.1002/pmj.21409 (as listed on the arXiv page); arXiv:1409.0003, submitted 29 August 2014. Read 2026-10-18 at the abstract on arXiv. Cited for the two phrases quoted in the body. https://arxiv.org/abs/1409.0003

[14] Leandro DalleMule and Thomas H. Davenport, "What's Your Data Strategy?," Harvard Business Review, May–June 2017. Read 2026-10-18 at the summary and opening only; the body is paywalled. Cited for the two definitions quoted in the body. https://hbr.org/2017/05/whats-your-data-strategy

[15] Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," press release, Stamford, Conn., 28 February 2024. Read 2026-10-18. A prediction; the release states no method. Cited for the prediction and the analyst's sentence quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

[16] Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk," press release, Stamford, Conn., 26 February 2025. Read 2026-10-18. The release gives two different sample descriptions (1,203 data management leaders in July 2024 in the body; 248 in the third quarter of 2024 in its summary) and does not reconcile them. Cited for the survey finding, the prediction and the analyst's sentence quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

[17] Informatica, "Global Data Leaders Seek to Harness the Power of GenAI for AI-Driven Success," news release on the CDO Insights 2025 survey, 28 January 2025. Read 2026-10-18. A vendor's survey; the release does not state the number of respondents or the fieldwork dates. Cited for the two percentages in the body. https://www.informatica.com/about-us/news/news-releases/2025/01/20250128-global-data-leaders-seek-to-harness-the-power-of-genai-for-ai-driven-success.html

[18] Wavestone, "The 12th Annual Survey of Fortune 1000 and Global Data and AI Leadership" (2024 Data and AI Leadership Executive Survey; undated page). Read 2026-10-18 at the published summary; the page does not give the response count. Cited for the two percentages in the body. https://www.wavestone.com/en/?p=910361

[19] Unity Software Inc., first-quarter 2022 earnings call, 10 May 2022, transcript published by The Motley Fool. Read 2026-10-18 and again 2026-10-20. Cited for the chief executive's account of two issues (a platform fault and the bad data) and the two passages quoted in the body; the estimate covers both. https://www.fool.com/earnings/call-transcripts/2022/05/11/unity-software-inc-u-q1-2022-earnings-call-transcr/

[20] Board of Governors of the Federal Reserve System, "Order of Assessment of a Civil Money Penalty Issued Upon Consent," In the Matter of Citigroup Inc., Docket No. 24-017-CMP-HC, effective 10 July 2024. Read 2026-10-18. Cited for the penalty amount and the two passages quoted in the body. https://federalreserve.gov/newsevents/pressreleases/files/enf20240710a1.pdf

[21] Brian Eastwood, "Chief data officers don't stay in their roles long. Here's why," MIT Sloan Ideas Made to Matter, 1 September 2022. Read 2026-10-18. The tenure figure is the article's subtitle, which it ties to a 2021 Harvard Business Review article that was not read. Cited for the sentence quoted in the body. https://mitsloan.mit.edu/ideas-made-to-matter/chief-data-officers-dont-stay-their-roles-long-heres-why

[22] Gartner, "Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025," press release, Sydney, 29 July 2024. Read 2026-10-18. A prediction. Cited for the prediction and its listed causes quoted in the body. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

[23] Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, "The GenAI Divide: State of AI in Business 2025," MIT Project NANDA, July 2025. Read 2026-10-18 in the PDF. Method as stated: 52 structured interviews, surveys of 153 senior leaders at four conferences, and a review of over 300 publicly disclosed initiatives. Cited for the method, the finding and the phrase quoted in the body. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

[24] Profisee, "Case Studies" index page (undated entries). Read 2026-10-18, first page only (24 case studies); the second page was not read. The vendor's own marketing. Cited for the count and the framing of the summaries described in the body. https://profisee.com/case-studies/