ie8 fix
madison

5 steps to cut IT budgets wisely

By | December 3, 2008, 6:39am PST

Summary: Although the chopping block isn’t a fun place to be, here are five reasonable things to consider when cutting budgets.

5 steps to cut IT budgets wisely

For many folks, economic planning these days has become synonymous with reduced spending; often, determining cutbacks is even more painful than budgeting. No, the chopping block isn’t a fun place to be.

That said, here are five reasonable things to consider when cutting budgets. The list comes from John Halamka, CIO of  CareGroup Health System and Harvard Medical School:

  1. Engage all your staff  - they can identify operational inefficiencies, redundancy, and savings opportunities.
  2. Find the low hanging fruit - vacancies, travel/training, consulting fees, food/entertainment, and other “nice to have” expenditures are the first place to start any budget reductions.
  3. Identify service reductions - all IT projects are a function of scope, resources, and timing. Reducing the scope of service and determining what projects to cancel is an important part of budget reductions.
  4. Extend timelines - assuming that resources are diminished and scope is already reduced, the last lever a CIO has is to extend the timelines of new projects.
  5. Accept risk - Our job in IT is to ensure stability, reliability, and security.

The key takeaway: successfully cutting budgets, especially unexpectedly, is all about balance and tradeoffs. Presumably, your projects are important or you wouldn’t have funded them in the first place. So, every cutback is likely to materially interfere with plans and goals, sometimes with severe downstream consequences.

John suggests that periods of economic turmoil offer CIOs an opportunity to focus on collaboration and team building:

CIOs should provide senior management with a list of services and a list of risks, then decide collaboratively what to do. This ensures that the CIO and IT is seen as an enabler and team player rather than a cause of the budget problem.

I suggest carefully examining the business value and ROI for every major project, activity, and purchase in the IT budget. Use anticipated business value as a metric, or reference point, when going through the budget. If you can’t explain the business value of a budget line item in straightforward terms, then it’s a candidate for deletion.

The budget axe is hard to wield, but thinking in terms of concrete business value will give you the strength to cut wisely.

[Image via iStockphoto.]

Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.

Topics

Michael Krigsman is a recognized authority on the causes and prevention of IT failures.

Disclosure

Michael Krigsman

Michael Krigsman writes and speaks about technology in a manner that most observers consider to be fair and balanced. Michael believes that writing about IT failures, which often have complex causes, creates a unique obligation to be reasonable and accurate in both reporting and analysis.

Michael maintains active personal and professional relationships with enterprise technology buyers, vendors, analyst firms (or individual analysts), consultants, and system integrators. As CEO of Asuret, Michael sells and delivers paid services to members of these same groups.

Vendors regularly reimburse Michael's out-of-pocket travel expenses to attend industry conferences and events. Conference organizers frequently waive entry fees when Michael attends industry events. Michael often speaks at industry conferences and events.

He is a member of the Enterprise Irregulars, a loose association of consultants, investors, industry representatives, analysts, and users of enterprise software.

For daily updates on Michael's activities, follow him on Twitter.

Biography

Michael Krigsman

Michael Krigsman is CEO of Asuret, Inc., a consulting company dedicated to reducing technology implementation failures. Asuret's suite of software tools improve the success rate of enterprise software deployments by quantifying and measuring governance issues that cause most project failures. Michael led the research effort underlying Asuret's model of collective intelligence and its practical application to reducing IT failures in consulting environments. He is a recognized authority on the causes and prevention of IT failures and is frequently quoted in the press on IT project and related CIO issues. He is considered an enterprise software industry "influencer" and provides advice to technology buyers, vendors, and services firms.

Previously, Michael served as CEO of Cambridge Publications, which develops tools and processes for software implementations and related business practice automation projects. Michael has been involved with hundreds of software development projects, for companies ranging from small startups to Fortune 500 organizations. Michael graduated with an M.B.A. from Boston University and a B.A. from Bard College. He is a Board member of the America's Cup Hall of Fame and the Herreshoff Marine Museum in Bristol, RI.

Related Discussions on TechRepublic

Did you know you can take part in these discussions with your ZDNet membership?
2
Comments

Join the conversation!

Just In

Contributr
Risk floor
mkrigsman@... 3rd Dec 2008
Interesting issue.

Every environment is risk-intolerant; the difference lies in degrees. Therefore, I think several considerations are important:

1. Gauging the degree of intolerance so you know what you have to play with and the degree of constriction against risk (and probably creativity) that you face.

2. Establishing a risk floor, or base, that is the worst case scenario. The risk floor must be "reasonable," as defined by what the organization is likely to find acceptable and logical. If the risk floor is too low, meaning the organization won't buy it, then you need to modify the proposal to make it workable.

3. Determining the best way to communicate the risk floor, so decision makers recognize your project falls within their (or the environment's) comfort zone for what's acceptable.

Much of this lies in communication: figure out the best way to present your argument, and back it up with irrefutable facts and figures.

Hope this helps!
0 Votes
+ -
Risk intolerant environment
jmavity 3rd Dec 2008
I'd be interested in hearing, if you're so inclined, an exploration of how to navigate risk-intolerant environments.
0 Votes
+ -
Contributr
Risk floor
mkrigsman@... 3rd Dec 2008
Interesting issue.

Every environment is risk-intolerant; the difference lies in degrees. Therefore, I think several considerations are important:

1. Gauging the degree of intolerance so you know what you have to play with and the degree of constriction against risk (and probably creativity) that you face.

2. Establishing a risk floor, or base, that is the worst case scenario. The risk floor must be "reasonable," as defined by what the organization is likely to find acceptable and logical. If the risk floor is too low, meaning the organization won't buy it, then you need to modify the proposal to make it workable.

3. Determining the best way to communicate the risk floor, so decision makers recognize your project falls within their (or the environment's) comfort zone for what's acceptable.

Much of this lies in communication: figure out the best way to present your argument, and back it up with irrefutable facts and figures.

Hope this helps!

Join the conversation!

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]
ie8 fix
Click Here
ie8 fix

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity

White Papers, Webcasts, & Resources
ie8 fix
ie8 fix