A technology strategy that survives the next budget meeting

A strategy becomes much easier to agree with when it avoids saying what the organisation will not do. Modernise the systems, improve the data, reduce risk and support growth. Few executives will argue with that list. The argument starts when those ambitions compete for the same money and the same people.

I would rather take a smaller set of explicit choices into a budget meeting than a polished catalogue of worthy projects. A strategy should help someone decide what to fund when the original funding assumption no longer holds.

That means showing the reasoning behind the sequence, not just defending the total.

Start with the choices the budget can change

Separate obligations from preferences, then check both carefully. A contractual commitment may have a genuine payment deadline. A preferred platform refresh might have a flexible start date. Calling everything mandatory prevents a useful discussion and makes the genuinely unavoidable items harder to see.

For each proposed investment, state the business problem, the intended change and the smallest useful commitment. Some decisions fund delivery. Others fund enough investigation to decide whether delivery is worthwhile. Those should not look identical in the budget.

Describe what the organisation will continue to experience if it does nothing. Avoid automatically calling that a catastrophe. Continuing with a manual process may be an acceptable short-term choice if its workload and error exposure are understood. It becomes a different choice when nobody owns the process or knows whether the checks still work.

A strategy earns credibility by admitting where waiting is reasonable.

Show which investments depend on each other

A list of ranked projects can suggest that any line can be removed independently. That is rarely a safe assumption to make without checking.

Consider a fictional organisation choosing between a new customer portal and work on its account records. The portal needs reliable account identities. Funding the portal while deferring the record cleanup may produce a service that requires staff to reconcile exceptions by hand. The apparently cheaper option has moved cost into operations.

The strategy should describe that dependency in ordinary language: the portal cannot meet its agreed service promise until the records are ready. Then offer choices. Fund both in sequence, narrow the first portal release, or defer the portal and complete the record work first.

Do not inflate every connection into a prerequisite. Ask the delivery team which dependencies are essential and which merely make implementation more convenient. An essential dependency should have an owner, a completion test and a place in the funding decision.

Write down a decision someone can revisit

A decision record should preserve why an option was chosen, including the conditions under which it stops being sensible. It need not repeat the entire business case.

For the fictional portal proposal, I would want a record along these lines:

• Approve record cleanup and a limited portal discovery phase, rather than full portal delivery.
• The operations director owns the account-quality rules; the technology lead owns the integration assessment.
• Do not promise a public launch date until the sample records pass the agreed checks.
• Defer the reporting redesign because it uses the same integration specialist.
• Return for a delivery decision when the data assessment and cost range are available.

This is an illustrative decision, not a report of work performed. Its usefulness comes from the explicit trade-off. Someone reading it later can see that reporting was displaced deliberately rather than forgotten.

Include dissent where it concerns a material assumption. If finance believes the current process can remain in place longer, record that view and the evidence needed to resolve it. A decision record should not rewrite a difficult conversation into artificial unanimity.

Distinguish deferral from disappearance

Deferred work needs a review trigger. Otherwise it becomes either a permanent complaint or an unofficial promise that the team will somehow fulfil later.

A review trigger could be a contract notice date, a service threshold or completion of a prerequisite. Assign someone to watch it. A note saying "revisit next year" provides little protection if the consequence arrives earlier.

The cost of deferral also needs a home. If an old system will remain, budget for its continued support. If staff must keep doing a manual check, agree who has capacity for it. Do not claim the cost of a project has been avoided while leaving its replacement work unfunded.

This is where making the technology budget easier to challenge helps: it separates changes to ambition from changes to existing commitments.

Take a smaller decision back when assumptions change

After a funding reduction, resist the urge to compress every project into a thinner version of the same roadmap. Some projects become less useful or less safe below a certain scope. Explain that threshold rather than pretending all work can absorb the same reduction.

Bring back a revised set of choices with a clear recommendation. Show what remains funded, what stops and which service or risk consequence requires acceptance. Update the people affected before the revised dates become a surprise.

Keep the original decision record alongside the new one. It gives the next quarterly strategy review something more useful than a comparison of slide decks.

The budget meeting should leave the organisation with commitments it can explain. If the team can name what it is doing, why it comes first and what it has permission to leave alone, the strategy has survived in a form people can use.