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

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