If yours is a typical IT organization, you won’t be dealing with your 2005 IT budget until sometime in the fall. That’s when you’ll be facing that same mad dash to the finish line that you face every other year, cobbling together a rough idea of what you might do and what it might cost with a smattering of “What did we do and what did we spend this year?” and a bit of “Where are those stupid spreadsheets we built?”
If you’re smart, you’ll be giving a lot of thought to that budget this summer. You’ll remember how painful and unorganized it’s been in the past, how so much of what you put in it was simply a series of placeholders for real projects, and how you swore you wouldn’t let the madness happen again.
The madness, for example, of that 20 per cent across-the-board budget cut. The madness that was the “lobotomize the whole portfolio” approach that threatened the success of every single project, instead of intelligently pruning entire projects from the bottom up.
If you’re lucky, you’ve built an organization where creating a budget isn’t a particularly stressful exercise — you’re in an organization where strategy flows naturally from mission, broad program initiatives rest on a solid strategic foundation, and a prioritized project portfolio supports the program.
You may be typical, you’re probably smart, but I wouldn’t count on being lucky. In most IT shops, budget season is probably the least-liked time of the year, that panicked few weeks during which any flaws in the organization’s planning and structure most visibly manifest themselves.
Budgeting really shouldn’t have to be a painful exercise, and it can be a whole lot easier if you know four things about the process before you start:
1. Understand your baseline: Do you have a solid grip on what your baseline costs are to operate your shop for a year? Can you answer this question: if your IT shop took on no new projects in the next budget year, not one at all, if all you did was maintain what you’ve already got, maybe upgrade operating systems and purchased applications, what would your budget be?
Every incremental project should have a cost associated with it, and logically, if the project is cancelled, that amount should disappear from your budget.
2. Know what’s capital, know what’s G&A: If you don’t know the rules about expensing or capitalizing IT stuff by heart, get thee to your friendly Finance folks, fast. This is not one you want to screw up. General guideline? If you want to capitalize something IT-ish, it should represent the buying or building of an asset that could be sold if you had to, something of enduring value (beyond one year) that should be depreciated over time. Otherwise, plan to expense it. Don’t get yourself into the embarrassing position of planning to capitalize something and then later having to shift it to G&A.
Aside from putting a big dent in your plans for the budget year, CFOs hate this kind of thing. Items that are capitalized when they should have been expensed can get them thrown in the slammer if there’s evidence that the miscalculation was intentional and fraudulent.
3. Anticipate big change: Prepare for projects to come and go. You know full well that the business you’re working with is going to change, and you’d better know that your budget’s going to have to change with them.
A wise CIO once told me that most IT organizations end up doing a third of the projects that were in their original plans, canceling a third of the balance, and then doing another third that they didn’t even anticipate when the budget was set.
Think ahead: When submitting your budget, don’t accept anything that doesn’t include a full analysis of associated go-forward costs, or you’ll find yourself in the same spot next year. Buy a piece of software this year, don’t forget that it’s going to have a maintenance cost next year. Keep track of it, and brutally review the list of maintenance fees next year.
So, in conclusion, be smart. And lucky.
Hanley is an IS professional in Calgary. He can be reached at isguerilla@hotmail.com.
