Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=228000275
I've been through many budgeting processes in my career. At the simple end of the spectrum, you estimate the costs of the items you know about, take an educated guess about what you don't know, add the two, and that's your budget. Then, as the year unfolds, you do what you need to do and spend what you can afford.
At the other end of the spectrum, you cost out every possible item. Business units scramble to make up some list of initiatives that may or may not be related to their business plans. The numbers get massaged, analyzed, modified, adjusted, and readjusted. The business units sign off on their list of initiatives and agree to accept the corresponding IT charges.
This approach leaves no room for new ideas during the course of the year. Longer term, it often produces a three-year idea-to-market cycle, which for IT is brutally slow. In Year 1, you budget for the idea assessment and business case. Year 2 is for the pilot program, and Year 3 is for rollout. You can't move faster, because you need the results of each phase to establish the budget for the next.
Large companies think this process achieves tighter fiscal control, but they become dreadfully, frustratingly slow in their ability to innovate. And they wonder why their IT solutions seem out of date as soon as they're delivered?
Fortunately, our company is somewhere in the middle of these two extremes. We don't shoot from the hip, nor do we waste inordinate amounts of time negotiating budgeted charge-outs. We develop our plan with sufficient detail to give us a clear financial view of how we expect the year to unfold.
However, we do play the add-and-remove game, and it drives me nuts. We review our infrastructure plans, identify what was deferred during the recent slowdown, and ensure we have plans to address our needs. Our application leads meet with all of their business counterparts and review our lists, prioritize, and agree on the set of app development and enhancement priorities. We consolidate the details, review the overall spending plan, and ensure it's based on a bottom-up view of our needs.
We then assess the top-down view: Does the overall spending align with the expected business climate? Have we left room for our skunk works projects, which often seed our most progressive business change initiatives?
But then I get the inevitable note from Ron, our VP of finance: "John, your budget has increased 11% vs. last year. Please reduce it."
It's a game all departments, not just mine, must play. As managers learn the game, they include in their budgets amounts that they will remove to pass the first stage of approvals. The finance group's behavior is reinforced, and so we have our cycle of wasted time.
I don't like it. I prepare a plan I think is best suited to meet our company's needs. If we remove items, we will feel it.
However, our biggest challenge in IT is with development and enhancement, those areas that depend on our units having insight into expected changes to their business. Rarely do we have the granularity of detail needed to estimate those needs accurately. With many of our business unit managers, we have the "make sure you budget for what I will need next year" attitude. Nevertheless, I can live with this approach. I see it as a form of trust. It may be frustrating, and I will be defending certain phantom plans to our finance cops, but this has become our equilibrium point in a flawed process.
The author, the real-life CIO of a billion-dollar-plus company, shares his experiences under the pseudonym John McGreavy. Got a Secret CIO story of your own to share? Contact firstname.lastname@example.org.