Open ten value creation plans and the technology section will look broadly the same in nine of them: a cost reduction target, a modernisation initiative with no cost attached, and a line about data enabling better decisions.
None of that survives contact with the operating year, because none of it is specific enough to be actioned or measured. Here is what the section should contain instead.
Technology moves four things, and only four
Any technology item in the plan should say which of these it affects, and how much.
Revenue. Faster quoting, capacity the current systems cannot support, a channel that cannot be opened without a platform. Rare, and the most valuable when real.
Margin. Manual work eliminated, spend reduced, downtime avoided, procurement leverage recovered. The most common and the most reliably quantifiable.
Risk. Losses avoided, insurability preserved, obligations met that are conditions of holding customers. Harder to quantify and easy to under-fund until an incident does the quantifying for you.
Valuation. Diligence readiness, reduced key-person dependency, systems a buyer will not discount for. Realised at exit and therefore chronically deprioritised in year one, when it is cheapest to build.
An item that cannot be attached to one of these is not a value creation item. It may still be necessary maintenance, and it should be labelled as such rather than dressed up.
Three numbers per item, not one
Each line should carry a cost, a benefit with a mechanism, and a date. "ERP modernisation, $2m" is not a plan. "Consolidate three ERPs to one over sixteen months, $1.9m capital and $400k internal, eliminating $600k of duplicate licence and support and 1.5 FTE of reconciliation, from month eighteen" is one, and it can be argued with, which is the point.
The mechanism matters more than the number. A benefit stated without a mechanism cannot be tracked, and untracked benefits are not realised, they are assumed.
Sequence by dependency, not by size
The largest item is rarely the first one. Identity consolidation, data definitions, and reporting are unglamorous and typically have to precede the things that matter commercially.
A plan that front-loads the ERP programme and defers identity usually finds in month nine that it cannot safely give the new system to the combined workforce, and stalls.
Name the owner and the failure mode
Two columns most plans omit.
Who owns this inside the business, by name. And what happens if it slips: which other item, and which part of the thesis, is affected. That second column is what turns a status update into a decision, because it tells the board what a delay actually costs rather than just that there is one.
Budget for the boring half
Every technology plan has a visible half, the programme with the name, and an invisible half: licence true-ups, the security work that has no advocate, the upgrade the vendor will force in year three, and the internal time the operating team will spend that nobody costed.
Underfunding the invisible half is how the visible half slips. A rule of thumb worth arguing about: if the plan contains no maintenance line, it is not finished.