IT budget planning: the three layers most plans collapse into one
Annual IT budgets fail when run costs, change costs, and investment costs are mixed together. Separating them makes the conversation with management much more honest.
IT budget season tends to produce one of two outcomes. Either the number comes back from finance cut by 20% with no explanation, or the number is approved but midway through the year it turns out to be spent in the wrong places. Both outcomes have the same root cause: the budget was presented as one number rather than three.
I have been involved in IT planning cycles long enough to see the same structural mistake repeat across companies of different sizes. The fix is not a better spreadsheet. It is a clearer conceptual model.
The three layers
Run costs are what you spend to keep today's systems operational. Licenses, hosting, support contracts, on-call coverage, routine maintenance. These costs are largely fixed and non-negotiable in the short term. You can optimise them, but not by cutting the budget - by renegotiating contracts, consolidating tools, and eliminating unused licences.
Change costs are what you spend to deliver the projects already on the roadmap. New features, integrations, compliance work, migrations that have already been decided. These costs are discretionary in theory - you could delay a project - but in practice they often have hard deadlines attached to business commitments.
Investment costs are bets on future capability. A proof of concept for a new analytics platform. An exploratory engagement with a new vendor. A team learning exercise around a technology you expect to need in two years. These costs have the weakest short-term justification and are always the first to be cut.
Why mixing them is expensive
When these three layers are bundled into a single budget line, several bad things happen:
- Finance cuts the total and assumes everything will scale proportionally. In practice, run costs cannot be cut, so the entire reduction falls on change and investment, which are already under-resourced.
- Management cannot evaluate trade-offs. "Do we delay the CRM integration or drop the data platform pilot?" is a real decision; "cut IT by 15%" is not.
- IT looks like a cost centre rather than an investment portfolio, which makes every budget conversation adversarial.
What to do instead
Present the budget as three separate requests with different approval logic:
Run costs come with a justification of what breaks if reduced and by how much. This is usually approved without discussion, because the risk is concrete.
Change costs come with a project list, each item linked to a business outcome and a deadline. Management can prioritise or delay specific items. This turns a budget negotiation into a scope negotiation, which is more productive.
Investment costs come with a hypothesis, an expected learning, and a ceiling. "We are spending X to test whether Y is viable. By Q2 we will know enough to decide whether to proceed." This framing makes the risk visible and bounded, which makes it easier to approve.
The side effect of this structure
Separating the three layers has a practical side effect beyond the budget conversation. It forces IT leadership to know what they are running, what they are building, and what they are exploring. These are three different management disciplines and they should not be managed the same way.
The structure also makes it easier to defend IT investments during a hard year. When the company needs to cut costs, a clear separation makes it possible to reduce investment costs without touching run or change - rather than cutting across all three blindly and breaking things that were supposed to keep working.