Most PLM business cases die in the same meeting, for the same reason.
Someone presents a slide saying the platform will improve engineering productivity by 20%. The CFO asks one question — "so which 20% of the engineering budget comes out next year?" — and the room goes quiet, because nobody intends to cut anyone. The number was never real money. It was a feeling with a percentage attached.
Finance does not buy productivity. Finance buys cost that stops being incurred and revenue that arrives earlier. If your case cannot be expressed in those two currencies, it is not a business case.
The three numbers you already have
You do not need a study. Three numbers exist in your systems right now and each one is a cost the business is already paying without seeing it.
1. Scrap and rework caused by wrong-revision work.
Pull the last twelve months of non-conformance reports. Filter for causes that read like built to superseded drawing, wrong revision, change not communicated. Do not estimate this. Count it and total the disposition cost.
This figure surprises people and it is usually the strongest line in the case, because it is money that has demonstrably already left the building.
2. Time between change approval and change taking effect.
Take twenty recent engineering changes. Record the date approval completed and the date the shop floor actually worked to the new revision. The gap is your exposure window — the period in which everything produced is a candidate for number 1.
3. Engineering hours spent looking for things.
The only number requiring a survey and keep it crude: ask twenty engineers how long they spent last week finding the current version of something, or reconciling two versions that disagreed. Ask about last week specifically. Memory beyond seven days is fiction.
What the arithmetic looks like
A worked example. A 400-person manufacturer, 60 engineers, one plant.
| Line | Basis | Annual |
|---|---|---|
| Wrong-revision scrap and rework | 34 NCRs, avg £4,100 disposition | £139,400 |
| Expedite freight on late changes | 21 incidents, avg £2,300 | £48,300 |
| Engineering search time | 60 eng × 2.4 h/wk × 46 wk × £48 | £318,000 |
| Gross annual cost of the current state | £505,700 |
Now the part most business cases skip and the part that makes it credible: you will not recover all of it.
| Line | Recovery | Value |
|---|---|---|
| Scrap and rework | 60% — process problems remain | £83,640 |
| Expedite freight | 50% | £24,150 |
| Search time | 35% — and it becomes capacity, not cash | £111,300 |
| Realistic annual benefit | £219,090 |
Against a £180,000 implementation and £45,000 a year to run, that is payback at about fourteen months. That is a defensible number. £505,700 was not.
Say out loud which benefits are cash and which are not
This single distinction decides whether finance trusts the rest of your case.
Scrap, rework, expedite freight and licence consolidation are cash. They appear in the accounts. They can be committed to.
Recovered engineering hours are capacity, not cash — unless you genuinely intend to reduce headcount and you almost certainly do not. What that line buys is more projects from the same team.
Present them in separate columns. A CFO who spots you quietly counting capacity as savings will discount your entire case, including the parts that were sound. Volunteering the distinction earns you the benefit of the doubt everywhere else.
The benefit nobody quantifies and how to
Faster change execution shortens time to market. Most business cases wave at this and move on because it feels unquantifiable. It is not — your commercial team already has the inputs.
Take one product launched in the last two years. Ask two questions:
- How many weeks of the schedule were lost to engineering change churn?
- What was the monthly revenue run rate in the first year?
Weeks recovered × weekly run rate × gross margin. Use a fraction of it — half is defensible — and state the assumption in the paper.
For a product doing £400k a month at 40% margin, four recovered weeks is roughly £148,000 of gross profit pulled forward. That will usually be the largest single number in the case and unlike a productivity percentage, it is traceable to something that actually happened.
Three ways the case gets destroyed in review
Benefits with no owner. Every line needs a name against it — the person who will be asked in twelve months whether it happened. An unowned benefit is a forecast. An owned one is a commitment and finance can tell the difference instantly.
No do-nothing column. Show what the current state costs over three years if nothing changes. Half the value of a PLM case is the cost of the status quo, and it is the half most people leave out.
A single blended number. "£220k annual benefit" invites scepticism because it cannot be checked. Four lines, each traceable to a source system, cannot be argued with the same way.
What to do this week
Do not build a model. Pull the NCR extract and filter for revision-related causes. That one query usually produces a number large enough to justify the conversation and it takes an afternoon.
If the number comes back small, that is worth knowing too — it means the change process is working better than assumed and the case needs to rest on time to market instead. Better to find that out from your own data than from a CFO.
If you want a second pair of eyes on a business case before it goes to your board — including an honest view on whether the numbers hold — get in touch.