Quality projects rarely fail on the merits of the technology. They fail on one assumption buried on page four of the spreadsheet — usually the one nobody questioned when the case was drafted. The inspection system is sound, the engineering justification is solid, and then a controller asks a single question about utilisation, scrap rates, or warranty recovery, and the whole edifice collapses.
The pattern repeats because quality people build cases the way engineers build things: bottom-up, with confidence in each input. Finance reads them top-down, hunting for the assumption that, if halved, turns a two-year payback into a five-year one. That asymmetry is the problem. Until you write your case the way a sceptical accountant reads it, you will keep losing approvals you deserved to win.
Across two decades in automotive and aerospace, sitting on both sides of investment reviews, I have seen this discipline learned the hard way. It requires no MBA — only the willingness to attack your own numbers harder than the reviewers will.
The utilisation trap
The most common killer assumption is capacity utilisation of the new asset. A team calculates throughput on a labour-free, three-shift, no-changeover basis — the theoretical rate from the equipment datasheet — and builds savings on top of it. Then finance asks what the comparable line next door actually runs at today, and the honest answer is far lower. Breakdowns, changeovers between part families, operator availability, waiting on material: all of it erodes the denominator.
My rule is simple: never quote nameplate capacity in a business case. Measure the current equivalent process over a representative window — long enough to catch Monday morning startup, Friday afternoon, the week after a holiday shutdown. Log actual good parts per available hour, not per running hour. The difference between those two figures is precisely where your reviewer will drive a knife.
Then state the utilisation you assume explicitly, show the measured basis for it, and carry degradation forward honestly. If you assume the new vision system inspects at cycle rate with zero false rejects forever, write that down and defend it — because someone will ask how it behaves when the lens fouls or the lighting drifts. An assumption you can name is an assumption you can negotiate; one you hid is an assumption you will concede.
Scrap and rework baselines you cannot substantiate
The second favourite target is the claimed improvement in scrap or rework. Teams routinely take the worst week of the year, annualise it, and call it the baseline. Finance sees this instantly, because every department has shown them the same trick since the plant opened. If your baseline defect rate is drawn from a tail event, the savings you attribute to the investment are mostly phantom — the bad week would not have recurred anyway.
Build the baseline from the quality records themselves: containment logs, nonconformance reports, sort-and-rework hours booked against the affected part numbers, customer notification records. Take a trailing period long enough to smooth seasonality, then separate chronic losses from episodic ones. The chronic floor — steady dimensional drift, assembly errors, missed operations — is what an investment can credibly attack. Episodic disasters need containment discipline, not capital.
One more subtlety: attribute savings only to the failure modes your intervention actually touches. If you are buying in-line measurement to catch dimensional variation earlier, do not claim credit for reducing porosity rejects. Reviewers who know the process will spot the mismatch, and once they catch you on one inflated claim, they discount everything else in the document. Credibility, once spent, is not refunded by a stronger appendix.
The false-reject problem nobody prices in
Here is an assumption specific to inspection and detection investments, and it destroys more payback calculations than any other: overkill. A new detection system does not merely catch true defects — it flags good parts as bad. Every false reject either gets scrapped unnecessarily, triggers manual re-inspection labour, or drives sort activity downstream. All three cost money, and none of them appear in the enthusiastic version of the business case.
Before you commit a figure to paper, run a structured evaluation on retained samples and current production. Measure the false-accept rate against known-bad parts and the false-reject rate against known-good ones, at the decision thresholds you actually intend to run. This is basic measurement systems analysis applied to economics, not just to gauge capability — and it is routinely skipped.
Threshold tuning is not an afterthought; it is the economic dial of the whole system. Tighten it and you ship fewer escapes but destroy more good parts; loosen it and the reverse. Model the payback across a band of operating points, not a single one, then decide with finance at the table where the risk appetite sits. A case that shows you understand this trade-off reads as credible in a way a single optimistic number never will.
A defect caught in-process costs rework; the same defect found at the customer costs multiples more; found in the field, multiples again.
Sensitivity analysis that actually diagnoses
Most quality business cases contain a sensitivity table that is decorative rather than diagnostic: plus or minus ten per cent on everything, as if all inputs wobbled equally. That tells the committee nothing. What they want to know is which single assumption, if wrong, breaks the case — and whether that assumption is one you control, one you can monitor, or one you are simply gambling on.
Rank your assumptions by leverage: the ones where a modest change swings net present value most violently. Typically these are utilisation, defect baseline, headcount displacement, and — if you are replacing detection with prevention — the rate at which you can actually eliminate the failure mode rather than merely detect it. Then stress each one individually to its plausible worst case, grounded in what you have measured, not a round number.
Present the result as a breakeven statement: the case holds provided the false-reject rate stays below the level measured in the trial, and provided the scrap baseline is at least half the trailing figure. That framing converts your document from a sales pitch into a risk map, and risk maps are what get funded.
Building the baseline before the case
- 01Measure current processGood parts per available hour over a representative window, including startups and shutdowns.
- 02Segment the lossesSeparate chronic defect floor from episodic events using NCR and containment logs.
- 03Trial the interventionRun retained-sample and production evaluation at intended thresholds.
- 04Map the operating bandModel payback across false-reject and threshold scenarios, not one point.
- 05State the breakevenDeclare which measured conditions must hold for the case to survive.
What finance actually challenges — and how to answer
Sit in enough review meetings and the questions become predictable. Is the headcount reduction real, or do the people just move to another cell? Are the savings cash-released or merely accounting-shifted between cost centres? Does the warranty recovery assume the customer will actually credit you, or only that you will argue for it? Is maintenance and calibration of the new system included across the full horizon, or does it mysteriously start in year three?
Answer each in the document before the meeting. Be explicit about which savings are hard — avoided scrap material, avoided purchased components, deleted contract sorting — and which are soft: freed labour redeployed, reduced expedite freight, fewer customer audits. Hard savings pay back loans; soft savings pay back patience. Declaring the difference up front costs nothing and buys enormous credibility.
Also include the do-nothing cost with the same rigour you apply to the investment side. Escaped defects found at the customer carry containment, sort, expedited replacement, and — in aerospace particularly — formal investigation burden. Under an AS9100-type regime, a single escape can trigger a root-cause investigation, corrective-action evidence, and a customer audit of your system. Price the escalation honestly rather than assuming containment will hold forever.
Stage the investment to shrink the scrutiny
The size of the scrutiny scales with the ask, so shrink the ask. A staged deployment — prove the detection capability on one line, one part family, for one quarter, with the baseline measured beforehand — turns a large speculative capital request into a small evidenced one. The trial costs little, and the data it produces replaces the assumptions finance would otherwise attack.
Define the trial's exit criteria in advance, in writing: what false-reject level, what throughput, what baseline reduction would justify full rollout. Agree those numbers with finance before you run it. The second-stage approval then becomes not a fresh argument but a comparison of promised versus measured — and if you have done the groundwork, it is the shortest meeting you will attend all year.
Two versions of the same business case
Cases that die in committee
- Nameplate capacity as the throughput basis
- Worst-week defect rate annualised as baseline
- Single optimistic operating point
- Savings claimed across failure modes the system never touches
Cases that get funded
- Measured good parts per available hour
- Trailing chronic-loss floor from quality records
- Payback band across threshold scenarios
- Breakeven conditions stated as measurable, monitorable commitments
I have watched excellent engineering die in committee for want of this discipline, and mediocre engineering get funded because its owner understood the reviewer's perspective. The mathematics of payback is not the hard part. The hard part is admitting, before someone else does, which of your numbers is a hope rather than a measurement. Kill that assumption yourself first, and your case will survive.
The review-proof checklist
Before any quality investment case leaves your desk, run it through five tests. Can you show the measured basis for utilisation? Is the defect baseline drawn from records rather than memory of a bad month? Have false rejects been costed at measured rates, not assumed away? Does the sensitivity analysis identify the one assumption that breaks the case? And are hard savings separated from soft ones in the summary itself, not buried in an appendix?
If any answer is no, the case is not ready — regardless of how sound the engineering is. Finance is not hostile to quality investment; it is hostile to unexamined numbers wearing the costume of analysis. Give a controller a document where every figure traces to a measurement, a record, or a stated and defensible assumption, and the burden of proof shifts to whoever wants to say no.
That is the real prize. Not a cleverer spreadsheet, but a position where the weakest number in your case is one you have already named, already stressed, and already survived. Committees fund cases like that, and they remember the people who write them.