Lessons From a Decade of IT Failures (ieee.org)

New submitter mixed_signal writes: IEEE Spectrum has an online set of articles, or "lessons," on why big IT projects have failed, including analysis of the impacts of failed systems and the life cycles of failed projects. From the summary: "To commemorate the last decade's worth of failures, we organized and analyzed the data we've collected. We cannot claim—nor can anyone, really—to have a definitive, comprehensive database of debacles. Instead, from the incidents we have chronicled, we handpicked the most interesting and illustrative examples of big IT systems and projects gone awry and created the five interactives featured here. Each reveals different emerging patterns and lessons. Dive in to see what we've found. One big takeaway: While it's impossible to say whether IT failures are more frequent now than in the past, it does seem that the aggregate consequences are worse."

Comments

LESSON NUMBER #1

[Lisias]

You will never write good code without writing bad code first.

And you will never stop writing bad code without being accountable for the results of writing bad code.

Experience is not how long you spend writing code. Is about how much time you spend fixing code, learning how to avoid having to do it again,

Reasons things fail

[JustAnotherOldGuy]

There are a million reasons why things fail, but they fall into a few broad categories:

Failure to plan ahead ("we'll worry about demand later, once we have a viable product"),
Failure to adapt to changing circumstances ("buggy whips will always be essential to our lives"),
Failure to avoid predictable or likely failures (i.e. "develop a perpetual motion machine")
Failure to manage resources properly ("have everyone working on this and not that).

There are millions of others, but most of them fall under one of these primary categories.

Re:Reasons things fail

[Impy the Impiuos Imp]

You neglected "massive government waste who cares it isn't really my money being spent."

Re:Reasons things fail

[JaredOfEuropa]

I would add to that: stakeholder apathy, or failure to generate sufficient buy-in. I have seen this apathy in big projects from everyone involved: the project team, business stakeholders, steering group, sponsors, focus groups, and vendors. There are many small things that cumulatively will cause this; it certainly doesn't set in only after the project is already on the fast track to failure. The result is sloppy work, an increased tolerance for shortcomings (in systems as well as people), mutual acceptance of missed deadlines and broken agreements, leading towards a project where people will be happy to deliver anything, no matter how crappy, just to be done with it.

Re: Reasons things fail

[Anonymous Coward]

That's actually 2 more entries, not just 1.

1) Poorly defined project specifications (the specs say to build a Chevy, but the customer/user is expecting a Ferarri)
2) Scope creep (the customer asked for a no-frills Ford, then says they need air, cruise, and a high-end stereo/GPS)

Re:Reasons things fail

[chipschap]

As an ex-government person I support your statement. There were/are some of us, quite a few in fact, who actually did care and actually believed in the mission and tried despite all obstacles to carry it out. We understood that it was American taxpayer money we were spending and that we were morally accountable.

The biggest problem I saw was the army of Beltway Bandits anxious to land contracts and then bill for millions while producing nothing of value.

Re:Reasons things fail

[JustAnotherOldGuy]

This is an older article, but according to the research, 68% of IT projects fail.

I'm not surprised. The more people involved and the more moving parts you have, the less likely anything will ever come to completion.

SAP projects are a perfect example of this. Those clowns could fuck up a guestbook script, all 30 lines of it. By the time they got does it would be 550 megs of object oriented code (java, C++, Oracle, COBOL, and maybe some perl just to help make it unreadable).

Re:Root cause analysis

[tomhath]

Suggests that management hubris plays a big part in IT Failures.

I think it's a combination of hubris and naiveté. Management and architects look at legacy systems and think all the complexity is unnecessary - that they can implement a "modern" system with the methodology that is in vogue (OOA/OOD, SOA, whatever). Anyone who tries to point out that the complexity is there for a reason is branded a naysayer and ignored. Years later management and architects are still struggling to deal with all the complexities they didn't want to see at the beginning, then the money runs out.

Reason 1: Magical Thinking

[ErichTheRed]

I have worked for a lot of large companies, and one of the things I've seen cause a lot of failures is thinking a problem will disappear by throwing Magic at it.
- Cripplingly-slow WAN speeds? Vendor X is the Gartner Magic Quadrant leader in WAN Optimization, we'll just use that! Here's $2 million, Vendor X. Just put it in, you're smart IT guys, how hard could it be?
- Developers and IT guys are expensive. I know, let's call Infosys/Tata/Accenture/HP/IBM, all I have to do is write them a check and all my IT problems disappear offshore!
- I don't want to pay for equipment. I know, let's put it in the cloud! The cloud makes all problems disappear for a low low monthly fee!

I'm a pretty avowed generalist, but my two "specialties" are end user computing stuff and systems management. EUC is rife with magic solutions -- I can't tell you how many thin client/zero client/cloud desktop/VDI/Citrix/Whatever iterations I've been through where the CIO didn't realize that the problems don't go away. Problems just get moved around and may be more expensive to solve in the new configuration. Systems management is a whole other ball game. In this field more than others, vendors like CA, Microsoft and some of the startups have the art of the stunning sales demo down pat. As a result, people like me have spent untold hours and company dollars on expensive vendor consultants getting even a fraction of that sales demo working in the real world.

I love the constant innovation that our field serves up, but one needs to temper that with the reality that most innovation is a rehash of something done before, with the underlying pieces improved. I think the IT field is long overdue for at least some standardization where we don't let vendors run the show.

Failures 1A and 1B: Offshoring and Outsourcing

[sethstorm]

They overpromise, underdeliver, and screw everyone when all is said and done.