Software

Seven (nasty) truths about IT spending

Michael Krigsman discusses a recent Harvard Business Review article that explores the harsh realities associated with out-of-control IT costs. He says the author suggests a certain Draconian inflexibility that just doesn't make sense.

This is a guest post from Michael Krigsman of TechRepublic's sister site ZDNet. You can follow Michael on his ZDNet blog IT Project Failures, or subscribe to the RSS feed.

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.]

9 comments
CG IT
CG IT

If so, then I can see some of the problems you guys have with the hard fisted suggestions Susan Cramm mentions. You guys create the "latest and greatest" programs. While "latest and greatest" is a good thing to market if your selling the program to the masses it's not necessarily what a company needs. While inhouse development of applications is great, if you guys don't create the "latest and greatest" and then "sell" it, then management begins to question why do we have high cost developers on the payroll if they don't really develop stuff. So it's a catch 22 for developers. Either come up with the "latest and greatest" and sell that an IT business value to the company, basically making IT it's own company inside a company, or risk losing out to standardized applications which often means management reviewing why the have high priced developers developing high priced applications in a company department which acts is if they are their own business. A department that really cost $$ and may or may not really provide any value to the company with their latest and greatest project. Then IT departments usually are looked upon as the money pit.

tsheehan
tsheehan

I believe numbers1, 3, & 4 relate to number 6. It?s been my experience that management relies too heavily on IT to know everything about the software used by the employees; here?s why: 1. Enhancement often don?t deliver results commensurate with their cost. This is not just an IT issue. Managers outside IT do not put forth the effort to research the enhancement they want to ensure it truly solves their problem; they see the part they like and what to hurry up and get it implemented. This hurry up and implement attitude causes things to be overlooked and/or not implemented correctly. The entire management team needs to do their due diligence prior to deciding to move forward with an enhancement, not just rely on the IT department because IT does not know their department(s) like they do. Money doesn?t have anything to do with this problem, making an educated decision does. 2. Previously purchased application and infrastructure technology are often underutilized. In every instance I?ve been in where applications are underutilized it is due to a lack of training, which is typically very expensive and not looked at as a priority to the long term profitability of the organization, namely SMBs. Management is too focused on the now and spending $10k - $50k to train their employees is an excessive amount of money at that time, especially during tough times when training is really needed. Upgrading or changing applications is not a wise decision if you don?t fully understand where you are and why your current software is failing. 3. Project failure rates are too high ? personally I have not had any projects that I lead that have failed. I have had projects that I wanted to have more time allocated to them, but didn?t, to ensure they were implemented correctly but they were not failures. The entire management team needs to buy in to a project and understand what needs to happen to make the project successful. I believe it is the responsibility of IT to initiate and educate but management needs to listen and investigate too; worrying about cost and time usually lead to failure. If you don?t have the time or money to invest in a project then don?t do it because you will usually be disappointed in the end. I understand why IT is looked upon as being the department that failed because IT is the focal of the change. However, the success and/or failure of a project must be shared by everyone. IT is no longer just a couple computers in the corner that do minimal work. IT is an intrical part of business and having everyone recognize and understand this is key to an organizations success. I also believe it is important for IT to sell themselves to the rest of management to prove their value. Without this proof IT can be looked at as a light switch that you turn on and off, which is a mistake.

gzoller
gzoller

I've got a problem with #5. Hold tech teams accountable for quality? That presumes they have control over quality. You have a bunch of guys pressured into slamming out code to meet some exec's star-crazed expectation, enduring endless changes and re-writes requested by those who don't know/care what the downstream impact is--now you want to make these guys accountable for the quality? Great way to see your developers head for the exit! Rather put positive quality incentives in place and the developers will join IT management in trying to contain creeping featurism. IT is a no-win business. Business internal customers of IT services are like crack addicts--they often live in a world of unrealistic expectations. IT managers are like pushers--all too often jumping to say "Yes we can" as much as possible. Why would they do that? Because every IT manager knows that if you don't jump-to, in time the business will start to listen to the army of hungry outsourcers promising the world in a month. Of course they can't do any better at the job than you can but by the time everyone figures that out it's too late for you: your job's been outsourced. You really can't win.

Tony Hopkinson
Tony Hopkinson

of that, though incentive for developers to produce quality, had me rolling on the floor. I can only assume that was a tongue in cheek reference to an IT in joke. Those of us who do the job, know exactly how important quality is to a business... A framework for killing, yes please. When I have a crap idea, as soon as I realise I have again been crap, I stop being crap. The only thing wrong with a bad idea is pretending it's a good one. As a developer, I regularly have ideas that don't pan out. This is a good thing. Rescuing a bad idea, is almost always much more expensive to the business in the long run, than stopping and having a rethink. The better you are at it, the quicker and cheaper you'll see your idea sucks. Reward that ability, not the one where you finagle more resources and polish the turd up, just in time for promotion away from the mess. If you discover an extra while doing a job, especially a cost reducer or a revenue generator, you've almost certainly gone out of scope. Your requirements, estimates, budget and the plan you had around them are now officially crap. Deal with that first.... I saw no real eveidence of rigidity, rules can be proven by exception as easily as they can by conformance. If you are going to break a rule, for a good reason, the good reason is reason enough to break it, so why sneak about and then look like you screwed up? May be the business benefits aren't as clear as you wish to believe, may be the other things you didn't do, or worse still couldn't do in favour of this, had a higher priority. Maybe you've invested resources in something that you now need to be a success.... I often lament business' failure to explain it's needs. The idea that we can solve that difficulty, by coming up with a need, explaining it clearly to ourselves, is outright lunacy. Stop it!

cssatx
cssatx

Agree with a lot of what Susan Says ... and agree with tempering ... but would offer these insight based on my experience. 1) Organizations do not often realize the secondary costs of implementing new systems ... maintenance and support ... which can be a huge annual hit. 2) Business Units almost never fully utilize all of the feature of the systems they acquire ... sometimes that percentage of utilization is woefully small. 3) Failure to align business unit workflows with system functionality contribute to (2) above ... and also often result in further requests for customization.

C_Zakalwe
C_Zakalwe

I wasn't too thrilled with the whole tone of the article, but I am willing to admit I'm not much of a C** prospect, so maybe I'm biased. I DO take exception to the following: "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." Your great idea is to hold people accountable, eh? How about actually PROVIDING AN INCENTIVE? I'm just guessing, correct me if I'm wrong, but I bet you never saw the funny in the T-shirt that says "The beatings will continue till morale improves" ...

addicted2speed
addicted2speed

I agree with some of the analysis; however at the same time, the reason why the business managers do not have realistic expectations is that IT managers do not (or maybe are not able to) communicate realistic guidance for the projects in terms that the business people can understand. IT is directly accountable for quality as it relates to the expectations that are agreed-upon by both the IT managers and the Business Managers. The second-half of my sentence is where most IT managers fail. Business Managers are not IT people, so communicating in IT language does not carry any value, even if the discussion is absolutely true. Conversely, the Business Managers sometimes use IT words in the wrong context, or they themselves are not effectively communicating their goals. Example: Business Manager wants a software application that automatically makes coffee every morning so the admin doesn't have to do it. His objective is to save the admin some time in the mornings. The knee-jerk reaction of IT managers will just say OK, it will take X Soft costs, Y Hardware Costs, Z Buffer budget, and be done in A months. Right? Why not offer the Business Manager a coffee maker, hooked to its own water line, with a built-in timer and pre-measured coffee packets? The perpective that IT is strictly a service-provider within the greater organization is a bit antiquated. IT has to be a business partner within the organization to function effectively.

Tony Hopkinson
Tony Hopkinson

an incentive. The real question is how much quality is the business willing to pay for. The answer is, enough. Less is an employee failure, more is an employee failure. And of course more is always required as soon as enough was found to be less than enough. Yu know the people who save money by cutting QA, and saying from now on we will get it right first time.... Clueless f'ing morons.

mdhealy
mdhealy

The iron law is that spending too much or too little on "official" IT support will cost more than spending enough. Survey users: if they are spending significant time doing things IT should be doing for them because they cannot get fast enough response time, then failing to increase the IT support budget will cost the organization much more -- but the cost of spending too little on IT is rarely visible to the bean counters.