Bob Lewis
Columnist

Penetrating the mysteries of IT budgeting

analysis
Nov 7, 20074 mins

Dear Bob ...OK, I like what you have said and the questions you have raised concerning employee compensation (in "Poor Joe" and "Comp logic," Keep the Joint Running, 10/22/2007 and 10/29/2007). I have a related issue you may like to consider.It is that time of year, again, in most organizations, where we need to develop next year’s budget. Like many other companies this year, we need to look at ways to cut expen

Dear Bob …

OK, I like what you have said and the questions you have raised concerning employee compensation (in “Poor Joe” and “Comp logic,” Keep the Joint Running, 10/22/2007 and 10/29/2007). I have a related issue you may like to consider.

It is that time of year, again, in most organizations, where we need to develop next year’s budget. Like many other companies this year, we need to look at ways to cut expenses – at the same time that we (in IS) are being asked to tackle several major, complex projects – involving system-wide impacts, multiple interfaces, all users, and not to mention continuing support of our existing applications.

Sound familiar? The list of projects would lean towards the addition of staff, not reduction or maintenance of status quo.

The conventional logic is that “census” is down, revenues are down, and therefore we must reduce expenses: translation – no more staff.

In IT, the workload is not a function of the in-patient or out-patient census. Our workload is a reflection of such things as:

  • Number of Users
  • Complexity of the System (number of interfaces, etc)
  • Number of devices to support
  • Number of applications to support
  • You get the idea …

My question is: has anyone come up with a “number/score” to reflect this workload – to use as a (Very) rough basis for staffing need? Perhaps a score of 1 – 5 on each critical area could be created – for an average score?

It may be a useless endeavor, but it is very difficult to talk numbers to Accountants without some number.

So – thoughts? Ideas? Any research out there? Have I snorted too much coffee, resulting in total malfunction of my two remaining synapses?

– Budgeting

Dear Budgeting …

Just my opinion: You’d be better off drinking your coffee than snorting it. Tough on the nasal septum. Trust me on this.

Just my opinion on the question you asked: You are, for the most part, on the right track. Your next step is to segment IS, because different areas of responsibility have different staffing drivers. So:

Major projects: Staffing is purely a function of your company’s IS Governance process. The more projects they approve, the bigger they are, and the more they want to have happen concurrently, the more staff you need for them.

Discretionary enhancements: Similar answer, only governance for discretionary enhancements shouldn’t be the same process. I usually prefer to handle these as a budgeted allocation, but instead of having a dollar budget, department heads receive an allocation of developer hours. The IS Governance committee (or whatever) is responsible for establishing this allocation. The more enhancements they want to have happen concurrently, the larger the budget.

Non-discretionary maintenance: It’s non-discretionary. Inform the IS Governance committee of the staffing required for this. To take the sting out of future staffing requirements, make sure every project’s business case includes the impact on maintenance staffing.

Discretionary infrastructure: This category supports infrastructure build-outs for new facilities, remodeling efforts, departmental moves and so on. Let business plans drive it. If the answer is, “We don’t know what will be required next year,” it’s perfectly fair to respond, “Then it’s awfully hard to predict what staffing we’ll need to support it. For now, I suggest we leave last year’s staffing alone, assuming we’ll have to deal with the same level of requirement this year.”

IS Operations: This is where servers per sysadmin ratios and that sort of thing come into play. I’d advise including a continuous improvement target in your ratios – as staff get better, processes improve and you improve your infrastructure, each sysadmin should be able to handle more servers.

End-user support: This is the biggest challenge. Start with the current ratio of end-users to analysts. Then propose three alternatives – one based on reduced support, one supporting at current levels, and one that invests in maximizing business user effectiveness. There are severe limits on the possibility of continuous improvement in this area because most of the improvements that would let you increase the end-user/analyst ratio depend on improvements in your end-users, not your analysts.

I’ve probably left out a few areas of responsibility, in part because they depend on how you’re organized (do you have a separate Architecture function to house your DBAs/Data Analysts, for example). You can apply the same sort of thinking to these as well.

– Bob

Powered by ScribeFire.