ie8 fix
madison

7 (nasty) truths about IT spending

By | April 14, 2009, 6:55am PDT

Summary: An article in Harvard Business Review suggests Draconian inflexibility is the way to achieve IT cost containment. That view makes no sense.

An article in the March issue of Harvard Business Review, written by former CIO Susan Cramm, discusses harsh realities associated with out-of-control IT costs. Although cost containment is integral to reducing failed IT projects, the article suggests a certain Draconian inflexibility that just doesn’t make sense.

The article includes a sidebar called “The Seven Truths,” reflecting Susan’s position that, “companies overspend on IT because they are unwilling to say no to frontline managers.” Here are the seven truths (reformatted from original):

  1. Enhancements often don’t deliver results commensurate with their costs. Establish a fixed budget for IT enhancements for each function or division, in line with the goals they are expected to achieve. Do not extend funds. When they run out, they run out.
  2. Projects are often too big and take too long, partly because unnecessary functionality is built into applications. Require leaders to commit to delivering measurable value for application functions before granting them project approval and before allowing them to maintain funding at each stage. Tie executive compensation to realization of value.
  3. Previously purchased applications and infrastructure technology are often underutilized. Use what you have before investing in new technology. Require IT to counterbalance the added cost of new infrastructure investments with sensible reductions in the cost of maintaining the basics.
  4. Project failure rates are too high. Minimize the duration of project stages. (Limiting scope makes projects less risky and more likely to succeed. That, in turn, increases buy-in for subsequent stages.) Establish “kill switch” rules for projects (for example, “Kill project if initial budget has been modified twice and beta deployment still has not occurred”).
  5. Tech teams do not have sufficient incentive to achieve high quality, and quality is often not measured. Make sure development and applications support teams are accountable for the operational costs associated with defects, including emergency change requests and help desk calls.
  6. Managers don’t know enough about the systems that support their areas. Follow Intuit’s lead and charge units for “helpless” help desk calls.
  7. IT is too risk averse: “No one ever got fired for buying IBM or Microsoft.” Require IT to examine the costs and benefits of extending refresh cycles, delaying upgrades, discontinuing maintenance agreements, and using open source platforms and applications.

THE PROJECT FAILURES ANALYSIS

The very existence of this IT Failures blog testifies that many organizations lack sufficient discipline and control around IT spending and execution. However, relying on Draconian guiding principles that ignore realities on the ground is no solution.

For example, in point one Susan recommends blindly killing projects when funds run out. While that sounds nice, some successful projects run over budget for legitimate reasons, often because unexpected opportunities to add value show up as work proceeds. Former CIO and project portfolio management analyst, Lewis Cardin, believes some project course corrections are valuable and he warns us against falling prey to “first number syndrome.”

On point four, discussing failure rates, Susan suggests establishing a rule-based kill switch. I agree with this to an extent, but again, her perspective is overly mechanical. For example, should an organization automatically terminate a critical strategic initiative because the IT execution component is flawed?

Susan’s HBR article is on the right track, but I’d prefer to see her advice tempered with greater nuance and flexibility. These complex issues have no simple answers, but rigidity is definitely not the right path forward.

[Via David Consulting Group blog. Image from 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.

24
Comments

Join the conversation!

Just In

There's a challenge with that tho
rickb@... 17th Apr 2009
Driving until the wheels fall off can often mean significantly higher cost to actually replace a system. One thing that is often overlooked in IT Project Planning is evaluating not only the cost to replace versus maintain a system, but understanding the implications of keeping a system beyond it's expected life.

Unfortunately, that's a tough thing to attach a hard number to - it's nearly always a SWAG and sometimes, not all that sophisticated.
0 Votes
+ -
Wisht that I could work....
Ryoko_z 14th Apr 2009
For an over funded IT department. Or even have a project that is anywhere near properly funded. Where do these slices of heaven exist?
0 Votes
+ -
Contributr
What about wasteful spending?
mkrigsman@... 14th Apr 2009
I'm not advocating more money to be allocated to IT.

MANY projects are wasteful and pointless and should be killed or never even started. However, I don't think the kind of rule-based metrics Susan describes are overly simplistic.

Susan's issues and the points she raises are valid and important. I just disagree with how she proposes solving them.
0 Votes
+ -
And don't take into account that fact that EVERY project goes over it's budget, because..... THERE IS AN INCENTIVE TO UNDERSTATE COSTS!

If we would get rid of that and tell people "Give us your HIGHEST estimate of what this would cost, not your lowest, and take into account problems being found in certain areas!".... most of the problems with IT overruns would disappear or be more manageable.

As to most projects being 'wasteful' and 'pointless'...... no! That's a bottom line 'no' there.

Most projects are not really 'wasteful' when it comes down to it, otherwise they wouldn't be approved by the NUMEROUS people in the chain of command.
As they say: 1 person can be snowballed..... 100 cannot! Even 10 cannot.
0 Votes
+ -
Not "EVERY"
ParrotHeadFL 15th Apr 2009
It's true that many projects experience cost overruns, but not *every* project does. The problem is that IT projects are more likely to experience budget problems than projects in other areas. It doesn't have to be that way.
0 Votes
+ -
True, but...
rickb@... 17th Apr 2009
...it seems to be more prevalent in IT projects.

One key reason (IMHO) is that project managers are often facing pressure to bring a project in under a certain number, rather than giving an honest estimate. Combine that with the fact that once a project is underway, it's usually cheaper to go over budget than to scrap it, and most PMs know they can go back to the well once the true costs become clear. So long as the original budget was close - well, they're pretty safe.

Another problem for IT budgeting: lack of a true understanding of the scope of the project. How often does a relatively simple upgrade become a much larger project as risks and issues are uncovered? The project was budgeted based on what was thought, and the true costs are reflected in what was actually found.
0 Votes
+ -
agreed
philsimonsystems 14th Apr 2009
It does seem simplistic to simply kill a project because it hit a threshold. If an unexpected data integrity problem caused a 1M project to go ten percent over budget (but will save $200K/year for ten years), then would you simply pull the plug?

Phil Simon
www.philsimonsystems.com
0 Votes
+ -
More logical than Draconian
Takalok 14th Apr 2009
More functionality does not necessarily mean more profit, and that, I believe, is her point.

Whether it's Web 2.0, Cloud Computing, SOP or whatever - hey - all great ideas - but where's the $$$? Where's the profit?

Without sidetracking the discussion down those topics, I maintain it is still legitimate to ask if spending several hundred thousand or even a few million dollars will result in a comparable increase in the bottom line. If that benefit isn't clear, well, drive IT until the wheels fall off.
0 Votes
+ -
Contributr
Extremes on both sides don't work
mkrigsman@... 14th Apr 2009
Which is why I have a problem with highly defined prescriptive solutions. Too much flexibility is bad, but trying to package complex problems into neat little boxes also doesn't work.
0 Votes
+ -
There's a challenge with that tho
rickb@... 17th Apr 2009
Driving until the wheels fall off can often mean significantly higher cost to actually replace a system. One thing that is often overlooked in IT Project Planning is evaluating not only the cost to replace versus maintain a system, but understanding the implications of keeping a system beyond it's expected life.

Unfortunately, that's a tough thing to attach a hard number to - it's nearly always a SWAG and sometimes, not all that sophisticated.
If she is saying this is the approach that needs to be followed in her own organization, then the "rightness" of her position depends on:

* What kind of organizational environment she faces regarding how projects get identified, valued, approved, run, and managed

* What are the typical projects that her organization faces

* Whether her seven "issues" are meant to frame the issues of accountability in how projects get identified, valued, approved, run, and managed or are they meant to be prescriptions and proscriptions to be followed


I can see her point of view if the organizational environment is fairly free-form. That is the people who want or approve such initiatives possess only a notional sense of business justification or case. The development approach used follows the big waterfall method versus some form of evolutionary / incremental method. If there is no internal business model for determining usage of IT assets (i.e. organizational value. Or there is no means to ensure accountability of execution and decisions of project participants on the project.

I can also see her point if projects tend to be those whose purpose is to standardize platforms, for example, they?ve got 15 different e-mail systems and they want to winnow down to say five. This kind of need is fairly regimented in and of itself.

If her goal was to have a catalyst for meaningful discussion on key governance issues for IT projects, or to demonstrate the value of the IT organization, then I can see these seven issues doing just that.

However, as general prescriptions and proscriptions for how the profession should conduct all IT projects, I disagree. I think her seven points assume that the causes of failure are solely mechanistic in nature.
0 Votes
+ -
Idiotic.

Killing a project because it went over-budget - idiotic. That guarantees that money already spent on the project was a complete waste. Continue with the project to completion, even though it went over budget, and you can get at least some ROI.

A more intelligent approach is to learn from the project going over budget - see if projections were realistic. See what caused the project to go over budget (sometimes, requirements changed, or there were unforseen roadblocks). See how future projects can be more optimized.

This lady is clueless, and if she were in my organization, flicking the kill switch on every over-budget project, I'd fire her useless rear-end in an istant.

She knows absolutely nothing about project management.

The only useful thing she said was to look at open source solutions, or solutions from vendors other than the biggies - i.e. get out of the "nobody ever got fired for going IBM" syndrome. That is very wise advice.
0 Votes
+ -
Right for the wrong reason
fogcitykid 14th Apr 2009
All Susan Cramm's points are correct in that these things do increase IT overspending -- but obviously what we have here is a failure to communicate. It gets back to not wanting to say no to the line managers.

Terminating projects or maybe their managers once the hoped-for results are lacking is locking the barn door after the horses are in the next county. The initial step on any project of any scope should be the financial analysis scoping increases in revenues or decreases in expenses against the project's step-by-step costs. Whenever a deviation from plan occurs, everyone needs to huddle down and decide if it makes sense to continue or if the costs can be made up later or if there needs to be rescoping.

Management needs to work as a team on determining the benefits as wellas costs of each project and continue to review and communicate moving forward. Incidentally, over many years in IT, I have seldom seen good tracking of anticipated benefits after turning the finished product over to the line departments.
0 Votes
+ -
Arrogance is the answer
Keegan2149 14th Apr 2009
If everything could be fixed by the sanctimonious
ramblings of an ivy leaguer the would be be a much better
place. The fact is that the author was only partially right.
Many of those problems do exist but there are reasons for
them? For example how do you develop acurate budget
expectations, r success benchmarks if the management
team does not understand the project. If they did the
company would save money and have the executives do it.
One of the biggest problems is that the actual technology
is too far removed from he upper management decision
process. This is why many projects fail. The goals are
unrealistic at best and the people that know it are in no
position to change them. I'm betting that somewhere there
is a team of developers that is very happy Susan is their
"ex" CIO. According to her profile the company was
actually Taco Bell... I'm sure they do some in house
projects, but it's not exactly ATT labs is it? I wonder if the
money Harverd Business review paid for this poorly written
and inaccurate article counts as a failed IT project? I can
only pray that my CIO doesn't become this self-righteous.
0 Votes
+ -
THX1138
Roger Ramjet 14th Apr 2009
Lucas' first movie should be a must-see for anyone involved in cutting projects arbitrarily.

Step 1 is the architect. If you have a good (full-time) one, then your project has a better than 50% chance of succeeding. This is because ALL of the stakeholders are represented at gate reviews. If the lowly sysadmin shows that this idea can't work, then the architecture gets changed.

Too many times a clueless manager with too much power will just go on a shopping spree and dump stuff in the IT's lap. It happened at FORD when a manager of mine went to a convention (since no one under his level was allowed to), got hijacked by an IBM sales droid, and proceeded to buy everything in their application suite (Tivoli, ClearCase, Rational, etc.). THEN the "project" was to incorporate them into the business.
0 Votes
+ -
Why does one rarely hear of outsourced studies prior to making IT investments? Just to get clear on what questions have to be answered? Have a different paths defined and analyzed for yield/cost?
There never is just the one solution before you start.
0 Votes
+ -
And maybe most important: Give those responsible for IT decisions an incentive to lessen spending money.
Most will fortify their own position by spending more, because it's way too profitable for your career to be able to say you are responsible for spending a lot of money.
0 Votes
+ -
7 wishful thinking truths you mean...
muzza2005 15th Apr 2009
1.Enhancements often don?t deliver results commensurate with their costs.
: so who dreamed up the requirement with fantasy ROI/TCO figures, and who didn't check it as part of project startup?
: depends on the ROI and importance to the business

2.Tie executive compensation to realization of value
: you're having a laugh! never happen ? bonuses are based on share price or quarterly/annual profit ? only external consultants get the big come-on for bonus for project completion (on top of sizeable day rates)

3.Previously purchased applications and infrastructure technology are often underutilized.
: under-utilised only in respect of new requirements that have been dreamed up after said apps/infrastructure were installed ? take care in not interpreting head-room for under-utilisation; you may save a few bucks, but keep your head down when the systems max out and the SLA is toast
: also, telling IT to add new while maintaining old and reduce the cost depends on the operational and support matrix ? if its larger you will see an increase in cost, not a reduction... oh, and don't even think of trying this with an outsource contract

4.Project failure rates are too high. Minimize the duration of project stages.
: minimising project stages duration means more stages: time wasted and navel gazing; no, you nail the scope to the floor; and squeeze change requesters until their eyes bulge or their wallet opens (to pay for it)...
: scope creep is a killer - I call it scope sprint, because runaway changes have cork-screwed most projects.

5.Tech teams do not have sufficient incentive to achieve high quality, and quality is often not measured
: tech teams rarely have incentive, full stop.
: QC will out if the 'user acceptance testing' fails; more often than not, UAC is barely hunt+peck on the keyboard with a few test datasets

7.IT is too risk averse:
Not risk averse, but exploding budget averse, and blowout-the-SLA averse.
0 Votes
+ -
Contributr
Ouch!
mkrigsman@... 15th Apr 2009
Boy, you folks are harsh with your comments. But I have to agree that some of her points are correct, but the prescription is over the top.
0 Votes
+ -
Management by Automatons
jacsas2001@... 15th Apr 2009
Return on investment and business performance are key to any business decision, including IT. Automatically cancelling a project that hits a trip wire may exhibit poor business judgment. Each situation needs to be carefully considered on its own merits. A decision to cancel a $5M project just before rollout, for example, when another $50K would complete it and provide needed business functionality albeit at a marginally less ROI should require some level of analysis. An alternatives analysis of the options should be conducted. Factors to consider would include such things as costs, sunk costs, benefits, profit, ROI, break even point, life cycle costs, and corporate health.

While these 'truths' can get worker's and reader's attention, I am amazed at he lack of business acumen exhibited by this 'CIO'. It would appear HBR published the article to show just that. (Do I smell a book coming?)

This is a great example of why IT managers must understand the business side of IT. Please do not submit any articles to HBR until you do. It may get published!
0 Votes
+ -
Accountability?
kckn4fun 15th Apr 2009
One thing missing from the list, and from EVERY endeavor out there, is that leadership is rarely held accountable for mistakes and are often rewarded for nothing.

Accountability for failures to meet deadlines should be carefully planned so that the "if" becomes the "fact" then the "accountability plan" gets executed and heads roll.
0 Votes
+ -
Re: Couldn't Agree More...
blackfalconsoftware@... 15th Apr 2009
I have been a strong proponent of software engineering concepts and methodologies for years and I have never seen any interest by management of including such recognized strategies into their development efforts.

Even when I was promoting these concepts with the corporate direction at one company that wanted to implement CMMI, my SE proposals were completely ignored.

The problem is that management in general whether it be technical or upper management have no idea what they are doing except to play the politics of the situation. If an important user needs something, it is simply added into the project work with little or no analysis.

With 30+ years of excellent research and results with SE implementations there is little need for management to question such success. However, their most common excuse is that they don't have the time.

An added hindrance is also the growing number of Indian IT managers who though more technically competent than their American contemporaries, have little understanding of system development efforts and processes usually implementing everything in an "on the fly" atmosphere. And yet, many of my colleagues from India are some of the most talented and enjoyable people I have worked with in my career.

Until the US eliminates the catastrophic type of management that has been allowed to infest our companies with the antiquated concept that business should be left alone to employ its own methodologies, this problem will never resolve itself. And the proof is the fact that after over 30 years of growing US Information Technology we are still dealing with the same issues when it comes to software development. That should tell everyone something...

0 Votes
+ -
Interesting rules but a distinction needs to be made between business management and IT management. Rules such as these can have some value but cannot be applied except when IT management is the one with spending and project authority. When a corporate board of directors decides to "save money" by buying an already written application and "modifying it to suit the company", insists on budget "estimates" of what will be needed to implement without IT having a chance to really evaluate the product or how well it fits the business, does their own scope changes and then wants to know why things are costing so much, how could such rules be useful? Who could apply these rules when the board of directors set the unrealistic goals originally?
0 Votes
+ -
It's all about the PM methodology
ParrotHeadFL 15th Apr 2009
A formal scope modification structure requires that every change be documented. If a member of the BoD or some other executive asks why the project is over budget, you simply show them the change requests.

One issue seems to be that project managers aren't assertive enough. If I'm managing a project, I'm responsible for making it succeed. If someone over my head tries to make changes to any of the triple constraints that are going to put the project's success at risk, I'm going to fight those changes tooth and nail. I have an obligation to do so.
0 Votes
+ -
This is not IT...
Narg 16th Apr 2009
This article took to many shortcuts in it's conclusions and missed a lot of details. In the end, it's about the people. On both ends. Yes, that includes the users, who drive a lot of the costs anyway. IT support is about people, not computers. Figure that out and you'll change this story 100%.

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