I've sat in enough budget meetings to know the pattern by heart. Someone presents a clean number for a new system, the finance team nods, the project ships, and eighteen months later there's an awkward conversation about why the actual spend is 40 percent higher than planned. It's rarely fraud and rarely incompetence. It's it budget mistakes that repeat, year after year, business after business, because the planning method itself is broken.
The core problem is that most IT budgets are built to get approval, not to survive contact with reality. They're optimistic by design, because an honest number is a harder sell in the meeting. That works right up until February, when the first invoice for something nobody budgeted comes due.
I want to walk through the specific lines that go missing, and give you a structure that holds up past the first quarter.
The three missing lines
Almost every broken IT budget I've reviewed is missing the same three things.
Maintenance and support. A system that costs 500 million IDR to build doesn't cost zero to run. Bug fixes, security patches, hosting, minor feature requests, all of it adds up. Budget 15 to 20 percent of the build cost per year, every year, for as long as the system is in production. If nobody is asking for this line, it means nobody has run a system past year one.
Integration costs. The new system rarely lives alone. It needs to talk to your accounting software, your CRM, your point-of-sale, whatever else runs the business. Integration work is almost never priced into the original quote because the vendor scoped the core feature set, not your specific tangle of existing tools. Add a discovery phase specifically to price integrations before you commit to a number.
Training and change management. Software doesn't create value until people use it correctly. I've watched a retail chain in Tangerang spend on a solid inventory system and then lose most of the projected efficiency gains because staff kept working around it, using the old manual process in parallel, for months. Nobody had budgeted time or money for training, so nobody owned it.
Optimism is not a planning method
The deeper issue is a bias built into the estimation process itself. When a vendor or an internal team is producing an initial timeline and cost, everyone involved wants the number to look achievable. Overruns get treated as failures of individuals, so people quietly compress their own estimates to avoid looking like the pessimist in the room.
The fix isn't better people. It's a different question. Instead of asking "what will this cost if everything goes right," ask "what did the last three projects like this actually cost, start to finish, including the ugly parts." If you don't have that history, build it now, so the next budget isn't guesswork again.
A contingency line that survives February
Every IT budget should carry a contingency of 15 to 25 percent above the base estimate. That's not controversial advice. What's controversial is what actually happens to it.
In practice, the contingency line gets treated as free money the moment the project shows any slack. A stakeholder asks for one more feature, someone says "we have contingency for that," and by February the buffer is gone and the real risks haven't even shown up yet.
Protect it with a rule: contingency covers unplanned problems, not planned scope additions. If someone wants a new feature, that's a change request with its own budget conversation, not a draw against the safety margin. This single rule prevents more overruns than any spreadsheet trick I know.
A budget template that holds
Here's the structure I use when building an IT budget meant to survive the year:
| Line item | Typical share of total | Notes |
|---|---|---|
| Core build/license | 40-50% | The number everyone already has |
| Integration | 10-15% | Priced after a discovery pass, not guessed |
| Training and rollout | 5-10% | Time and materials, not an afterthought |
| Annual maintenance | 15-20% of build cost, recurring | Budgeted every year the system runs |
| Contingency | 15-25% | Reserved for unplanned problems only |
Notice maintenance is the only line expressed as a percentage of build cost rather than total budget, because it recurs independently of the original project. Put it in your operating budget, not just the project budget, or it will quietly disappear the year after launch.
Before committing to any of these numbers, run the same premortem you'd run on the project itself: what are the one or two most likely reasons this budget blows past its ceiling, and what's the cheapest thing you can do this month to catch that early. Usually the answer is a monthly actual-versus-planned review, not a new tool.
What to check before you approve the next one
If you're reviewing an IT budget before approval, ask three questions out loud in the room: where's the maintenance line, where's the integration cost, and what happens to the contingency if nobody touches it. If any answer is vague, send it back.
The businesses that get burned aren't the ones spending too much on IT. They're the ones spending the right amount but calling it the wrong thing, then discovering the real number in pieces over the following year. A budget that names its own weak points up front is worth more than one that looks perfect on the day it's approved. If you're deciding whether to build a system in-house or buy one off the shelf in the first place, that decision changes these numbers substantially, so it's worth working through before the budget is even drafted. See Build vs Buy Software: A Decision Framework for Owners for that groundwork, and if the budget keeps failing because the underlying system is old and expensive to patch, the real fix may be replacing it rather than budgeting around it, covered in The Hidden Cost of Legacy Systems in Your Business.