When IT savings need more than a target
Most large IT cost programs report a familiar pattern: ambitious target at year-zero, confident green status through Q1 and Q2, slippage starting in Q3, and a quiet rollover of the unrealized portion into the following year. The mechanism is rarely failure of intent. It is structural disconnection between financial logic and delivery reality.
Diagnostic
Is your IT savings program drifting?
- Savings targets were set top-down without being mapped to specific technical levers, owners and milestone dates.
- The same line item is reported as "saved" by IT and "not yet realized" by Finance — and the discrepancy is unresolved.
- No named individual owns each lever; only an executive sponsor owns the program total.
- Evidence rules ("when does a saving count?") were never agreed in writing with the controller community.
- Year-end re-baselining quietly pushes unrealized savings into the next plan instead of being recognised as a miss.
Context
Cost reduction programs begin with a top-down target. The number may be correct, but it does not explain how savings will be created, when they will be recognized or what evidence will be accepted. Without translation into specific levers owned by named individuals, the target floats above the operating layer — real on paper, unrealized in the ledger.
What usually goes wrong
Savings are distributed across infrastructure, applications, contracts and operating model changes, but the technical levers are not linked to the financial forecast. Owners are nominal. Milestones are soft. Evidence rules are absent. The program reports savings that IT recognizes and finance does not — and the discrepancy surfaces only at year-end, when replanning has already begun.
Five elements per lever: driver, owner, milestone, technical evidence, financial evidence reconciled to the GL.
Where savings physically live
Real savings come from specific technical moves: decommissioning a legacy server estate, terminating unused software licenses, reducing cloud capacity, automating a manual run process. Each financial target must be mapped to the specific action that produces it. Without that mapping, the saving is a projection.
Demand is the re-inflator
Cost programs that do not control demand growth produce no net saving. Business growth re-inflates the cost base as fast as the technical savings are realized. Demand governance — business cases, charge-back, prioritization gates — must be in scope, not deferred to a separate initiative.
The ledger is the arbiter
Each realized saving must be reconciled to the general ledger by the controller community. If finance and IT cannot agree that a saving has materialized, it has not. Evidence rules must be defined at program design — not negotiated at year-end.
Forums that review by lever — not by colour
If the executive forum reviews savings by category and RAG status, accountability dilutes. If it reviews by lever, owner and evidence — with the technical milestone on the table — the framework holds through slippage and escalation.
"The difference between a savings target and a realized benefit is governance."
— RSV Consult perspective
What works in practice
A value-capture model connects each saving to a driver — decommissioning, capacity reduction, license rationalization, sourcing change, operating model redesign. Each lever has an owner, a dependency chain, a milestone date and a financial evidence rule. Governance reviews by lever and owner, not by category and colour.
The first 90 days
Inventory and translation
Map every announced saving target to a specific technical lever, named owner, milestone date and evidence rule. Reject any line item that cannot be traced. The output is a single value-capture register replacing the program tracker.
Baseline and instrumentation
Reconcile the program baseline to the general ledger with the controller community. Lock evidence rules in writing. Configure reporting at lever level, not category level — so finance and IT read the same number.
Forum redesign
Replace RAG-only reporting with a monthly review that decides at lever-and-owner level. Slippage becomes visible at the technical milestone — not at year-end re-baselining — so it can still be recovered.
What changes when this works
Programs running on a working value-capture framework convert announced savings into ledger-recognised reductions at materially higher rates than category-and-RAG programs. Slippage is identified at the technical level, weeks earlier, when there is still time to mitigate it through scope, sequencing or sourcing decisions. Finance and IT stop arguing about whether savings are real and start working together on which lever recovers the gap. The CFO no longer hears "we saved €X" from IT and "we didn't see it" from the controller — the same number lands in both reports.
Cost transformation succeeds when finance and technology speak the same evidence-based language. If the saving cannot be reconciled to the ledger, it is a forecast — not a saving.