The good news is that you are likely to receive incremental spending authority for new IT initiatives in 2006. The bad news is that your IT budget will still not be sufficient to meet your strategic goals.
Those numbers, drawn from a survey by CIO Insight (part of the Ziff Davis Enterprise Group, which includes eWEEK), sum up the IT dilemma for this year. While IT budgets have increased for 2006, the expectations of what you can accomplish with those increased dollars exceed the skills of even the best technology budget stretcher.
According to the survey, which can be found at cioinsight.com, in 2006, IT budgets will be up about 5.4 percent over last year. Add to that the expectation by about 70 percent of those responding that additional spending authority will be granted for new IT initiatives, and the technology budget seems absolutely robust.
Well, robust until you read that 58 percent of those taking the survey agree with the statement that their companies are not spending enough to meet strategic goals.
A deeper cut of the 2006 budget spending shows that about 55 percent is devoted to maintaining ongoing operations, 21 percent to completing current projects and 24 percent to launching new projects.
So much for the numbers. More important, what do all those stats mean to the technology manager? Id suggest that some of the same old rules, along with a few new ones, apply to technology projects.
Old rule No. 1 is that projects always take longer than you would expect and cost more than youd ever budget. Why is that rule still in effect? Projects take longer because too little time is spent on pilots as well as on estimating the difficulty of scaling pilots to the full enterprise.
I think RFID projects will fall into this category in a big way. The price of RFID chips is decreasing, but the focus on only the chip on the physical package is like judging how fast a car can go by looking at the range on the speedometer. The boring but important parts of inventory management projects are less in the package identification and more in the back-end database systems.
Is your system really ready to track everything, everywhere? I think the new wrinkle in this old rule is that companies were too ready to cut their development teams over the past years. Before you can start a pilot project, you might end up rehiring a development team.
Old rule No. 2 is that projects have to play nice with other projects. One of the bywords in corporate IT today is data integration. If you are going to chop down that 55 percent spent on maintaining ongoing operations, you had better find a way to integrate disparate hardware and software systems.
Projects that spring up full blown out of sales, financial or human resources departments without an understanding of how they will work with other departmental systems are destined to wither.
The new twist on this rule is the widening list of options for data integration. With the rise of open-source platforms, vendors such as Oracle buying up the application vendors, and offshore and hosted data integration services, you might want to consider other methods for integrating your existing operations.
The final old rule is that technology projects never die, they just go on life support for corporate eternity. While lots of execs will focus on the cost of maintaining ongoing operations, you probably could find more fertile savings in the 21 percent of the budget dedicated to completing current projects.
New projects tend to have many champions, while existing projects have a way of living on long after those champions have left the company. If a good government objective would be to require that before any new regulation can be passed, an old regulation must be killed off, then a similar rule with regard to projects would benefit the corporation.
The twist is that the rise of big corporate acquisitions can keep old projects alive longer than anyone realizes. Before you start those new 2006 initiatives, maybe you should try counting your existing projects.
Editorial Director Eric Lundquist can be reached at email@example.com.