Approval Is Not the Decision

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

Why this investigation matters now

Two figures for the return on enterprise AI have been going round. MIT's NANDA initiative, in July 2025, reported 95% of organisations getting zero return [9]; a Wharton School study with GBK Collective, three months later, put nearly three-quarters already ahead [10]. Both are now travelling on slides inside business cases, and the first article in this investigation takes them apart: different samples, different observation windows, different tests for what counts as a success, and neither of them measuring the organisation whose committee is about to read the slide.

That is the visible edge of an older problem, arriving in a harder form. Master data management has always been enabling work. Its value lands in somebody else's programme, its cost is front-loaded and its return long-tailed, and it has no headline number of its own — which is why cases for it reach for the category's. What has changed is that master data now arrives folded inside AI proposals: larger asks, shorter timetables, and, for the first time, a cost line that does not hold still after approval. Part of an AI-bearing programme is metered. The unit price moves on a vendor's calendar, the number of units depends on how clean the records were before the call was made, and the relationship between the two is not a straight line. A case can be approved on an honest estimate and be wrong a quarter later without anybody having made a mistake.

The instrument being asked to carry all this has not moved much. In a 2006 survey of 102 organisations across the UK and Benelux — the most recent this investigation could find that measures both the requirement and the after-the-fact assessment on the same population — 96% required some form of business case and fewer than half carried out any formal assessment of the value actually delivered once the money was spent [1]. A later reading is kinder, and not by much. In a 2016 survey of 503 senior executives run by the Economist Intelligence Unit for the Project Management Institute, 52% said they monitor the extent to which business benefits are being achieved as part of project governance: just over half, a decade on, self-reported by executives about their own organisations, and not set against a requirement figure, so it narrows the gap rather than closing it. A document that almost every organisation demands and about half check is not a control. It is a toll gate, and the traffic through it has just got heavier and more expensive.

So this investigation asks a question earlier than the one usually asked. Not how do we write a better case but what is the document for, and then: what survives contact with a committee, what happens in the months after the committee says yes, and what changes when part of the cost is a meter rather than a purchase. Four articles, published together, answer those in order. This piece is what is left over when they are read side by side — the things none of them could say on its own.

One disclosure before anything below reads as advocacy. The practice behind this publication is a Profisee partner and implements its master data platform. Clients pay it for deployment work; a licence sale it refers earns it a referral fee from the vendor; and services revenue depends on this category of software being funded at all. An investigation arguing that master data deserves an honest case is written by an interested party. Weigh its criticisms above its reassurances.

The four articles, and where to start

The four core articles are sent as a package on request; this Wrapper is the open part of it. They are written to be read in order, but each answers its own question, and a reader with one problem in front of them should start where the problem is.

What a Business Case Is For is the foundations article, and the place to start if the case in front of you is for enabling work. It separates a document written to decide from one written to ratify, a rough order of magnitude from an estimate from a commitment, and a forecast return from benefits somebody actually checked. Its hardest finding is not from the literature: on the practitioner record the ratifying case is the ordinary product of a department head who has already chosen, and the competitive procurement that looks like an open decision has usually not been one.

Five Instruments, Five Questions is the frameworks article, for anyone who has been told to adopt a method. It asks what question each of five instruments answers and what each cannot see — then reports the answer that dissolves the choice: at a large client the structure is the client's, because procurement systematised it years ago, and the instruments become a way of reading a mandated pack rather than a menu.

The Room, and the Months After It is the application article, for once the money is approved. It sets out why the cases that look best on paper are the ones that leaned hardest, why the industry's own scorekeeping rewards leaning the other way afterwards, and names the three shapes in which a funded programme stalls — with the single move that works against all three, and what it costs.

The Line That Moves After Approval is the implications article, to read before costing anything with a model in it: the price list that has become a menu of ways to pay, the unit price that changes on somebody else's date, money released in tranches behind tests, and the accounting rule that may decide which budget the programme competes in. It ends on questions.

What only shows up when the four are read together

Each of the four articles runs in two registers and marks the line between them: published research above, and below it operating experience from Jeff Shabel. What follows draws on both and says which is which. None of it belongs to any one of the four.

One. Every corrective this investigation recommends is itself enabling work — which is why it is the easiest thing to drop. The foundations article establishes the shape of the enabling problem: the cost sits with one party, the benefit with another, and the party paying cannot point at a return of its own. Read the other three with that shape in hand and it keeps reappearing, in the machinery meant to fix it. A benefits dependency network works only if a manager in another department signs as the owner of a benefit; an outside view only if a finance function keeps a history nobody is asking it for; a stage gate only if the people who can say kill turn up and occasionally do. Benefits tracking, the implications article notes, is work somebody has to do and is rarely costed in the case that promised it. The frameworks article has the practitioner's verdict on this whole class of apparatus, given about councils and stewardship models and extended here rather than by him: correct, oversold, and dependent on people taking time out of their day for something that is not their deliverable. So the governance of a business case has the same profile as the programme it governs — diffuse benefit, concentrated cost, no owner with a reason. It is also a better explanation than dishonesty for a finding in that same 2006 survey: 38% of the 102 organisations believed their own approach led them to frequently overstate benefits to obtain funding [1]. The operational reading is short: a corrective with no named keeper and no line in the budget is decoration, and the useful question about any method is not whether it is sound but who has been given time to run it.

Two. Approval is not the decision, and the committee's real instrument is a calendar. The foundations article treats the slide from a rough order of magnitude to an estimate to a commitment as a labelling failure. The frameworks article then reports where the slide actually happens, and it is nowhere near the case: the number moves inside delivery, sprint by sprint, under a Product Owner whose latitude over cost and scope came with the move to Agile, and nothing announces that it has changed class. The cost-engineering standard that supplies the vocabulary — written for the process industries, and borrowed here by analogy — makes a class a property of how much has been defined at the moment the estimate is made [5]; on the record it is a property of a fortnight. The application article finds the same thing happening to the decision itself — the choice to keep funding a programme is re-made, silently, every time it is allowed to continue, which is the condition escalation research warns about [4] — and its answer is not a better document but a dated meeting with the people who approved the money. The implications article closes the set: the model named in a case is a choice to be re-taken at every gate, because its price can double on a date already printed on the vendor's page. Three mechanisms, in three of the four articles, and each is periodic rather than documentary. The appraisal tradition is not on the other side of this, whatever it looks like: the guidance cited here calls the business case "a working document which must be developed and revisited over the duration of the scheme" [2], and the revisiting it describes is tied to the three stages — which is to say, to a schedule. A committee that governs by re-reading the case between those points is governing a stale object. The instrument it actually controls is the calendar: when it next sits, who is in the room, and what it has asked to be shown.

Three. The enabling benefit has finally acquired an invoice — and that is where it can go missing. The oldest difficulty in this territory is that master data's return shows up as somebody else's improvement, which is why the frameworks article had to deal with the reflex to split the credit. The practitioner refuses the split there: the two cases count different things, so the gain belongs in both, and what stays forbidden is adding the two totals into one organisation-level figure. Set that beside the implications article's finding that deterministic pre-processing is cheaper than paying a model to cope with mess every time it is asked, and something genuinely new appears. Where the rules are stable enough and the volume high enough to repay building and maintaining that step, part of the master-data return is now paid out as a lower meter reading in the AI programme, every month, for as long as the model runs. On that estate, and not on one whose volumes are low or whose rules will not hold still — where there is no saving to find and so nothing to count — the enabling benefit lands somewhere it can be counted without anybody's forecast: a recurring bill that is smaller than it would otherwise have been. The catch is in the same sentence. A cost that did not happen appears in a budget nobody attributes it to, so unless the AI case says what its meter reading assumes about the state of the records, the saving is real and unclaimed, and the master-data programme is back where it started. No figure is offered for the size of that effect. One partner-run measurement of it now exists and it cannot be leaned on: a benchmark published by Alteryx on 21 September 2026, two days before this was written, reports a twentyfold cut — 95.06% — in the tokens consumed on a 120-trade reconciliation test when a deterministic step is put in front of the model instead of the model being asked to do the whole job. It was run by a consultancy that partners with the vendor, on one workload, and published by the vendor, and it runs in the direction this publication would prefer: three reasons to report that it exists and none to quote it as a size. The same post reports a second benchmark, the vendor's own — 480 trials, "up to 93%" — which was run by the vendor itself and points the same way. The partner interest disclosed above bears on this claim harder than on anything else in the series. There is a well-argued position against this: that these models now cope with messy records well enough to make the preparation unnecessary. Against it, the point here is only this — work a deterministic step can do is cheaper done there than paid for as tokens each time it is needed, on the estate described above and nowhere else. A case should not present advanced AI processing over raw source records as the cheaper path without a measured comparison of the two. The direction is what the record supports; the size is not.

What the Record Actually Says: what to do differently

The ground shifts here, and the warrant shifts with it. Everything above is this publication's synthesis of its own four articles and of the published work they cite. What follows is operating experience from Jeff Shabel, drawn out in interview, quoted from the record of his answers or restated and attributed. It is pattern rather than law, and no method is offered here for falsifying it. Four of his answers sit here rather than in a core article because they concern the assembly of a case as a whole rather than any one beat, and the third and fourth articles point back to this piece for them.

Start with the order, and with the two steps that drop out of it:

The real order of operations for a business case going to a funding committee is four steps, and only the first two are the ones people think of. (1) Figure out what you need to do, then — usually immediately after — what you want to do. (2) Figure out roughly how long it will take and what it will cost. (3) Shape the case to appeal to the needs of the company and of the specific members of the approval group. (4) Last thing in is the candy: low-hanging fruit that would be great to get done, doesn't move the timeline much, and can win support from business groups outside the core ask.

The first two steps are what this investigation has spent four articles arguing about. The last two are the ones no framework in the second article contains, and both keep reappearing in the other three from different directions.

Tailoring, on his account, is done approver by approver, the way an advocate frames an argument for the particular member of the bench who will hear it — so the representative from marketing needs something in the proposal that marketing gains by, and legal will push back on any new exposure that is not a core requirement unless the case has already answered the concern. The third article meets the same rule from the other side of the table: the way to bring a second executive in is to lower the cost and raise the benefit for that executive's own department, and above all to pull one of their live production problems inside the programme's scope. A benefits map records none of this. Tailoring is nevertheless, in his telling, much of what decides a vote.

The candy step is a distribution problem, and his reason for it explains where the other three articles keep finding trouble. Master data work, as he describes it, follows a Pareto shape: most of the visible value arrives early, and the remainder trails behind it for as long as the estate is complicated, so the argument for continuing gets harder to make the further the programme goes. His response is to spread the small, quick wins across the whole implementation rather than bank them at the start. Read that against the third article's three stall shapes, which that article places months in, and against the fourth's warning that a tranche gate falls in exactly the same stretch — the programme arrives at the people who can stop it carrying its weakest story. Candy is a funding tactic, not a morale one.

And contingency, in his practice, is written as a share of the schedule rather than of the budget: a fifth of the time, held back because something always comes up in an implementation. That is what the appraisal guidance's optimism adjustment [2] looks like when nobody has the data it asks for: the guidance wants the correction drawn from past projects, and a flat fifth of the schedule is the habit it exists to replace. A case with no time contingency has told the room its date is the happy path, and a committee can check for one in ten seconds. The practice also bears on the third article's one mitigation — proving the whole line end to end from the first weeks — because that proof is spent out of the same reserve it exists to protect. It draws the reserve down early to defend it later, and a status report read in month two shows only the drawing down. A committee that funds the proof has to be told in the case to expect that, before it sees the report.

What to watch

Four things in this territory are still moving, and a committee that watches them will be asking better questions a year from now than one that waits for a method to arrive.

Where the metered line lands in the accounts. The US standard-setter's 2025 update replaces the old project-stage test for internal-use software with a threshold that is not met while significant development uncertainty remains — uncertainty that has not been resolved through coding and testing — and it takes effect for annual periods beginning after 15 December 2027 [8]. What a particular organisation may capitalise is a question for its controller and not for an article. The thing to watch is second-order and nearer: whether the most uncertain part of an AI-bearing programme ends up in the operating budget, in the year it is incurred, competing with everything else, and whether anybody asked before the case was written.

Whether staged funding keeps its teeth. Releasing money a tranche at a time, with a test in front of each release, has come loose from the formal option-pricing it grew out of, and the fourth article argues that this is the right way round. A gate's value is its power to stop: the model's own vocabulary offers go, kill, hold and recycle [6]. The question worth putting to any organisation adopting the practice is whether one of its gates has ever returned the second of those. A gate that has never killed anything is a status meeting with a signature at the end.

The reference class that still does not exist. Return figures for this category of software are not scarce, and it costs this publication something to set them aside, because they are the numbers a case for master data would most like to quote. Forrester's Total Economic Impact studies, each commissioned by the vendor whose product it prices, report 366% over three years for Reltio's master-data platform (2022, six Reltio customers), 348% for Ataccama ONE (2024, six customers) — a unified data management platform of which master data is one module rather than an MDM platform — and payback inside three months for Dun & Bradstreet's master-data solutions (2020, five customers). The same vendor's January 2026 study of its wider data management solutions reports 208% and fourteen months, drawn from two decision-makers at one organisation, and it is the better illustration of the point: none of these is a reference class and none can be made into one. Each is paid for by the seller and resolved into an organisation that does not exist — a composite of six, six or five of that seller's own customers in the first three, and in the fourth a summary of the one company whose two decision-makers were interviewed. Either way it is a forecast in the same shape as the case it would be quoted in, which is the thing this investigation keeps saying not to trust. Each was read on a summary page rather than in the study itself: the studies are gated, and the January 2026 figures sit on Forrester's own client-branded page rather than the vendor's. The figures and the interview counts are those pages' own. What is missing is the unglamorous version: outcomes for a population of data programmes nobody selected, forecast set against what was delivered. That exists for what information-technology projects cost, and this investigation could find nothing of the kind for what data programmes return; the Treasury's own supplementary guidance records that its source study could not recommend bounds for benefits shortfall at all [7]. Until somebody builds that class, a case that says the benefit side is unmeasured is more honest than one that does not, and an organisation that starts keeping its own history of forecast against outcome will have something no published study can give it.

The question that is starting to replace the headline number. The foundations article records a newer question turning up from regulated and market-aware buyers: what it will cost not to do this. It is a better question because it asks why rather than how, and because no borrowed industry figure can answer it — the answer is arithmetic about one organisation's own estate. Whether it spreads is the most useful signal of the four, because it is the only one that would change what a case has to contain.

Affordable

In one widely published statement of the questions a funding body asks, the fourth is about affordability: whether the money exists in the budget of the bodies involved [3]. In that sense the word is granted without argument. Now take it seriously, because the practitioner record has a ruling on what it means:

While there's always a number, I'll fight about the number ever being the only factor. It's always one of a bunch of factors, even if it's the 'leading' one. Even in situations where companies establish 'thresholds,' those thresholds are established for other reasons than pure monetary figures--not the least of which might be they don't have that kind of money in the first place. Obviously if someone needs a trillion dollars to implement something, anyone other than Governments or Musk are going to reject it out of hand, but that's not because of the dollar figure--it's because of the infeasibility for them being the ones to do it in the first place.

Keep the word, then, and let it mean more than the number. An organisation cannot afford a thing when it cannot be the one that does it, and money is only the most visible way that shows. A threshold is a fact about the body that set it — its capacity, its mandate, what its money is already promised to, and often simply what it has. Read that way, we can't afford it stops being a wall and becomes we are not the ones to do this, this year — and an ask can be resized, resequenced, or taken to the sponsor under whose mandate it actually falls. Both errors are still errors: strip the number out to honour this and the case breaks as badly as it does when the number is allowed to decide. The guidance that supplies the word says as much itself, ranking options by their summary metrics and then stating that the ranking "by itself is not sufficient to make a decision" [3].

That is the investigation in one word. Approval is not the decision, the number is not the case, and affordability is a question about the organisation with the budget as one of its symptoms. Each of the four articles, in its own beat, is about the same refusal: a single figure standing in for a judgement that belongs to people.

The four articles this Wrapper is written from

These are this publication's own work, not sources, so they are named rather than numbered. All four publish with this piece and are sent as one package on request.

• What a Business Case Is For
• Five Instruments, Five Questions
• The Room, and the Months After It
• The Line That Moves After Approval

References

Every entry below was read for one of the four core articles, on the date its own entry there gives, and none was re-read for this Wrapper except where its own entry says otherwise; the rest are drawn on through those articles. Annotations have been rewritten to the narrower use made of each source here; every bibliographic fact, and every disclosure about how much of a source was read, is carried across unchanged. Three sources named in the body carry no number and are not listed here: the 2016 benefits survey run by the Economist Intelligence Unit for the Project Management Institute, the Forrester Total Economic Impact studies commissioned by Reltio, Ataccama and Dun & Bradstreet, and the September 2026 Alteryx token benchmark. Each was found while testing a claim this piece makes on its own account rather than while writing the four articles, and each is named in the body together with the interest that produced it. What was read of each: the PMI/EIU survey in full as the deposited PDF; the Forrester studies on the vendors' own summary pages and not in the studies themselves, which are gated; the Alteryx benchmark as the vendor's published post and not as a test report. This list stays what it says it is, the four articles' list.

[1] John Ward, Elizabeth Daniel and Joe Peppard, "Building Better Business Cases for IT Investments," MIS Quarterly Executive 7, no. 1 (March 2008). Read as the authors' accepted manuscript in the Open University repository, not the published version; the manuscript's pagination differs from the journal's. Cited here for the 2006 survey of 102 organisations in the UK and Benelux: 96% of respondents required to produce some form of business case; fewer than half formally assessing the value delivered; and 38% believing their current approach led them to "frequently overstate the benefits in order to obtain funding." https://oro.open.ac.uk/11215/2/WardDanielPeppard_MISQE_FINALas_submitted_after_revisions.pdf

[2] HM Treasury, International Guide to Developing the Project Business Case — Better Business Cases: for better outcomes, 2018 (editor's note by Joseph Lowe, Editor of the Green Book). Cited here for the instruction that optimism-bias adjustments be based on "data from past projects or similar projects elsewhere" (p. 35) and for the instruction to start from the upper bound of its table (p. 37, the table itself on p. 36). The international edition was read because the domestic edition linked from GOV.UK returned HTTP 410; the two are assumed, not verified, to agree on these passages. One passage was located in this source for this Wrapper rather than carried from a core article: the description of the project business case as "a working document which must be developed and revisited over the duration of the scheme" (p. 4), cited in the second cross-article finding. The p. 37 locator was corrected from p. 36 in the same check; all page numbers here come from a text-extracting fetch of the PDF and were not confirmed by eye. https://assets.publishing.service.gov.uk/media/5fb25b608fa8f55df27c18a8/Project_Business_Case_2018__International_.pdf

[3] HM Treasury, The Green Book (2026), GOV.UK, HTML edition; publication page last updated 5 February 2026. Cited here for Chapter 3, Table 2, "The Five Case Model" — the financial case "is concerned with the affordability of the proposal for the public bodies involved" — and for Chapter 2, "Identifying the preferred option": an initial ranking of options by their summary metrics of social value "by itself is not sufficient to make a decision." Direct download of the page and of the 88-page PDF was refused by network policy, so the HTML edition was read through a rendering fetch returning short passages rather than the whole text; both phrases quoted here were confirmed verbatim in a separate verification pass. The HTML edition's paragraphs are unnumbered, so locators are by chapter, section and table. This is a standard for UK central-government appraisal, cited as a published statement of the questions a funding body asks, not as evidence of how any private-sector committee operates. https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026

[4] Mark Keil, Joan Mann and Arun Rai, "Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models," MIS Quarterly 24, no. 4 (2000): 631–664. Read at the abstract only. Cited here for the condition the paper names and measures: escalation of commitment to a failing course of action, which its abstract reports in "between 30% and 40% of all IS projects". The body's framing of that condition — that the choice to keep funding is re-made, silently, at every continuation — is this publication's own and is not a finding of the paper, whose abstract says nothing about how the decision to continue is taken. https://aisel.aisnet.org/misq/vol24/iss4/4/

[5] AACE International, Recommended Practice 18R-97, Cost Estimate Classification System – As Applied in Engineering, Procurement, and Construction for the Process Industries, revision of 1 March 2016. Read from a copy hosted by the City of Austin; AACE's own distribution is to members and was not read. Cited here only for the framework's central move — an estimate's class is a property of how much of the thing it prices has been defined at the moment the estimate is made. The practice is written for the process industries and "specifically does not address" software development; its application to data programmes is this publication's analogy, and no percentage from its class table is carried here. https://services.austintexas.gov/edims/document.cfm?id=280770

[6] Robert G. Cooper, "The Stage-Gate Model: An Overview," Stage-Gate International, 15 December 2025. Written by the model's originator for the firm that licenses it. Cited here for the four decisions a gate may return: "Go, Kill, Hold, or Recycle." https://www.stage-gate.com/blog/the-stage-gate-model-an-overview/

[7] HM Treasury, Supplementary Green Book Guidance: Optimism Bias, published on GOV.UK 21 April 2013, prepared from a 2002 Mott MacDonald study of cost and time overruns. Cited here for the absence of sound upper and lower bounds for benefits shortfall, for lack of data (p. 5), and for the encouragement to "collect data to inform future estimates of optimism" (p. 2). https://assets.publishing.service.gov.uk/media/5a74dae740f0b65f61322c72/Optimism_bias.pdf

[8] Financial Accounting Standards Board, Accounting Standards Update No. 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, September 2025. Read through a summarising fetch of the FASB PDF; page numbers reported by that fetch were not verified by eye. Cited here for the capitalisation threshold, for "significant development uncertainty" where uncertainty "has not been resolved through coding and testing," and for the effective date, "annual reporting periods beginning after December 15, 2027." Cited for what the standard says, not as accounting advice. https://storage.fasb.org/ASU%202025-06.pdf

[9] Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, MIT NANDA, July 2025. Cited here only for the headline figure — "95% of organizations are getting zero return" — which the first article in this investigation takes apart on sample, window and definition of success. Read as a copy hosted by mlq.ai, an independent research and news site for investors with no connection to MIT or NANDA; the filename's version string is v0.1, and no copy on an MIT or NANDA domain has been checked against it, here or in the core article. Not re-read for this Wrapper; the annotation there governs. https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf

[10] The Wharton School of the University of Pennsylvania with GBK Collective, Gen AI Fast-Tracks Into the Enterprise, October 2025 (Year Three report). Executive summary only; the full report was not read. Cited here only for "nearly three-quarters already see positive ROI", self-reported by respondents about their own programmes. Not re-read for this Wrapper. https://ai.wharton.upenn.edu/wp-content/uploads/2025/10/2025-Wharton-GBK-AI-Adoption-Report_Executive-Summary.pdf