Building an IT Budget You Can Defend

Before estimating anything, list what already has a date on it. Software subscriptions, support contracts, connectivity, domain names, certificates, the phone contract, maintenance on anything with a service engineer attached. Put each on a calendar in the month it falls, with what it cost last time.

Do this first, because it is the only part of the budget you can be nearly precise about, and because the total usually surprises whoever asked for the budget. A good share of next year is spoken for before anybody has proposed a single new thing. That is the cost of the setup you already chose rather than a sign of anything going wrong, and seeing it laid out is what makes the rest of the conversation realistic.

Gather the dates from invoices rather than from memory or from a supplier list. The ones that hurt are the ones nobody remembers agreeing to. An account somebody opened during a project. A tool renewing annually on a card. A licence that arrived bundled with something else and now bills on its own. Finance has all of these. Ask for a year of card statements and read them properly.

Note which renewals carry a notice period. A contract you must cancel a quarter in advance is a decision you have to take months before the money moves, and missing that date is the most common way a business buys something it had already decided to drop.

A per user subscription grows with hiring, and hiring is planned in a different meeting to the one you are sitting in. Get the headcount plan and apply it. If the business intends to add a team, the software bill goes up alongside the salaries, and finance has almost certainly budgeted the salaries on their own.

The same applies in the other direction and people forget it completely. When somebody leaves, the seat usually keeps billing until a human removes it. Across a year of ordinary turnover that is real money paid for accounts nobody is using. Tie the licence check to the leaver process rather than to the renewal date, because the renewal date is eleven months too late.

Then there are costs that move with usage rather than with people. Storage, which only ever grows. Data transfer. Anything charged per transaction or per message. Those need last year's trend rather than a headcount plan, plus a look at whether anything in the business plan will bend that line sharply.

Be careful with annual commitments sized against last year. They are cheaper per unit and they punish you for growing in the wrong direction. If you are genuinely unsure where the business is heading, paying a little more for flexibility is often right, and it is worth saying so in the budget rather than letting it look like carelessness.

If you bought most of your machines at once, you will have to replace most of them at once, it will land in a single budget year, and it will be refused. The way out is to turn replacement into a share of the estate every year, so the figure is roughly the same annually and stops being an event.

Include the things nobody counts as hardware. The switch in the cupboard. The firewall and its support subscription, which often costs more than the box did. The backup appliance. The wireless access points. Phones, where the business provides them. Anything with a fan in it that has been running since before the current office layout.

Getting from a cliff to a rolling cycle takes a couple of years of deliberately uneven buying. Replace the worst first, judged by the job the person does rather than by the purchase date, then even it out afterwards. Say in the budget that this is what you are doing, or the second year looks like you got the first year wrong.

Every year there is at least one piece of technical work the business has already committed to and has not mentioned to the technology budget. Sales promised a customer their orders would come in through a system link. Finance is changing something and needs a report that does not exist. A new site is opening and somebody assumed the network came with the lease. A rule is changing and there is a date attached to it.

You will not find these by looking at technology. You find them by asking each department head one question: what have you promised anybody this year that will need something from us. Ask it plainly, and ask before you write the budget rather than after. The answers turn up uncomfortably often.

Then size them roughly, and mark them as rough. A range with the assumptions written beside it is far more useful than a confident figure, and it protects you when the requirement turns out to be bigger than the sentence describing it. It nearly always is.

Contingency gets cut because it has no name and no owner, so it reads as padding. Everything else in the document is a thing somebody wants. This is the line that looks like money you have not thought hard enough about.

Make it survive by giving it a history rather than a formula. List the unplanned things that actually happened over the last couple of years. The failed drive. The supplier who raised prices mid contract. The emergency network work after the office flooded. The software replaced at short notice because the vendor was bought. Size the line against those and show the list beside it. A named history is much harder to delete than a percentage.

Give it a rule as well. Who can approve spending from it, what it may be spent on, and a note at the end of each quarter saying where it went. A contingency line with governance attached reads as a control rather than a slush fund, and it gets treated accordingly.

If it does get cut, and it might, record the decision in writing. Not as a complaint. As a fact, so that when something breaks in the autumn the conversation starts from the right place instead of from an argument about who should have foreseen it.

The most common budgeting mistake in technology is a project cost that quietly becomes a running cost. You buy the new system once. It then needs licences forever, support forever, and somebody's time forever. The project gets approved on the purchase figure, and the running cost arrives next year as a surprise.

So write every proposal with two figures. What it costs to do, and what it adds to the annual bill afterwards. Refuse to approve anything internally without the second one. That single habit will save you more grief than any other change to how you budget.

The same applies when you move from owning a thing to renting a service. That can be a good decision for plenty of reasons, and it turns an occasional purchase into a monthly bill. Compare them across the sensible life of the thing rather than across one year, and be honest about what happens to the monthly figure as usage grows, because usage grows.

Budgets get reduced. The wrong response is to absorb the cut quietly and stop doing things, because the expectation stays exactly where it was and only the capacity moves.

Write down what stops instead. Plainly, without theatre. If replacement is deferred a year, the consequence is more failures and slower machines, so say that. If a support contract goes, the consequence is a system with no supplier to ring, so say that too. Send it once, keep a copy, and do not raise it again unless something happens.

It also helps to present the budget in versions from the beginning. What must happen, what should happen, and what would be worth doing. A cut then becomes a choice between named things rather than a percentage applied evenly across everything, which is the version that damages you most, because it slices into the work that was already sized honestly.

Sit down at the midpoint with the actuals against the plan and find out where you were wrong. Not to defend the original figures. To find out which assumptions have stopped being true while there is still time to move money around.

The culprits become predictable once you have done this a couple of times. A supplier price rise. A currency move on anything billed from abroad. Hiring that ran faster or slower than planned. A project that slipped into next year and took its cost with it. Storage growing faster than the trend suggested.

Keep a register of what you asked for and did not get. Next year's conversation starts from that list, and it is a much stronger position than a blank sheet. When the thing you were refused turns out to have been needed, the register makes the point for you without anybody having to say anything.