A defensible number is one where every line traces to a contract, a replacement cycle or a risk the business agreed to reduce. Here is how to build one in three weeks.
The IT budget conversation goes badly for a predictable reason. One side presents a total with a short justification, the other side asks what would happen if it were ten percent lower, and nobody in the room can answer that question with anything better than an opinion.
A budget that survives is one where each line can be traced to something outside the opinion of the person presenting it. That is the whole technique. Everything below is how to build one.
What the number is made of
The ordering on that bar matters more than the percentages. The first two categories are effectively fixed: you cannot stop paying for licences people are using, or for the people and contracts who keep the lights on. Hardware refresh is deferrable for a year and not for three. Security tooling and projects are where real choices live.
When finance asks what could be cut, this ordering is the answer. It converts an argument into a conversation about which specific things not to do.
Build it from what is happening anyway
Start with the parts that are not choices. This is almost always the bulk of the budget and it is the part most often assembled last, from memory.
Contracts. Every technology agreement, its annual value, its renewal date, and whether the price is indexed. Many agreements have an uplift clause of three to five percent that nobody models, and across a dozen contracts that is real money.
Replacement cycles. Devices do not last forever. Take your asset data, apply your cycle, and the forecast falls out. If you do not have asset data good enough to do this, that is this year's first project, and it is a small one.
Support and lifecycle dates. Operating systems, databases and line-of-business applications leaving vendor support. These dates are published years in advance and they are the most predictable cost in the entire budget, which makes it remarkable how often they arrive as a surprise.
Headcount changes. Every new person has a licence, a device and an onboarding cost. Get the hiring plan from HR rather than estimating it.
Add those four up. That is your floor, and it is not negotiable without a decision somebody has to own.
Then add what you chose
The discretionary part should come from two sources only, and both should predate the budget conversation.
From the risk register: the items the business has already agreed to reduce. Because these were agreed earlier, in a different conversation, they arrive in the budget with their justification attached rather than needing to be argued from scratch.
From the roadmap: the projects already on the one-page plan. Same logic.
If something is in the budget and in neither of those places, it needs a very good explanation, and the honest version is usually that somebody wants it.
The calendar
The item worth protecting is negotiating renewals that land next year, because that work has to happen before the budget is set rather than after. A renewal negotiated in Q4 for a Q2 contract changes the number you are about to submit. The same negotiation in Q2 is a variance to explain.
Presenting it
Four things, in this order, and the whole thing is two pages.
The total, and the change from last year, with the change explained in three lines. Not twenty lines. If inflation on contracts, two new hires and one deferred refresh account for the movement, say that.
What is fixed and what is not. With the fixed part dominating, which it will. This single slide reframes the conversation away from the total.
The options, priced. Three things you are proposing to do, each with a cost and a consequence of not doing it. The consequence has to be concrete. "Increased risk" is not a consequence; "we would be declining the security questionnaire from our second-largest client" is.
What you are not proposing. The things you considered and rejected, with the reason. This does more for credibility than anything else in the document, because it demonstrates that the number has already been filtered.
Questions to have answers for
"What happens if we cut ten percent?" Have a real answer, worked out beforehand, naming the specific things that would not happen. If you cannot answer this, the budget was not built from traceable lines.
"Why is this more than last year?" Contract uplifts, headcount, and whatever was deferred last year arriving. Know the split.
"Can we defer the refresh?" Yes, once. Have the number for what deferring twice costs, because it is not linear: support costs rise, failure rates rise, and eventually you replace everything in one year instead of a third each year.
"What do our peers spend?" Benchmarks exist and are mostly unhelpful, because the range within any sector is wider than the difference between sectors. A better answer is to explain what drives your number specifically, and offer the benchmark as context rather than as justification.
The thing that is always missing
A reserve. Not padding, which is what finance suspects, but a named contingency of around five percent for the incident, the failure or the acquisition nobody forecast.
Ask for it explicitly, with that reasoning, and report on it. A contingency that is visible and accounted for survives scrutiny. Padding hidden across other lines does not, and when it is found it costs you the credibility of every other number on the page.
Three weeks, realistically
Week one: pull contracts, asset data and lifecycle dates. Build the floor.
Week two: add the register and roadmap items, price them, and work out the consequence of not doing each.
Week three: write the two pages, then give them to somebody non-technical and ask them to explain the total back to you. Whatever they cannot explain is the part that will not survive the meeting.
