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,

Re:LESSON NUMBER #1

[Dragonslicer]

Also summarized by the saying, "Some people have 10 years of experience. Other people have 1 year of experience 10 times."

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

[LoyalOpposition]

While I suspect that you're a tad sarcastic here,...

I agree with you that Impy the Impious Imp was speaking sarcastically. It reminds me of the four types of spending Milton Friedman classified, and the value of its results. I'm working from memory here, so please forgive me my mistakes. Type 1 spending is where you spend your own money on yourself. This type of spending has the greatest results because you take care to spend as little as possible, and to purchase the things you want most. Type 2 spending is where you spend someone else's money on yourself. This has worse results than type 1 spending because, while you still take care to purchase what you want most, you are more likely to try to spend the entire amount. Type 3 spending is where you spend your money on someone else. In type 3 spending you try to conserve funds, but rather than getting someone what they most want, you get them what you think they should want. Type 4 spending is where you spend someone else's money on someone else. In type 4 spending you neither try to conserve money nor purchase what's most needed or wanted. I interpret Impy to be saying that all government spending is type 4 spending.

~Loyal
 

Re:Reasons things fail

[__aaclcg7560]

Not at my government job. A newly hired I.T. guy who expects to get paid for doing nothing because he thinks this is a "government job" will find himself on the unemployment line within a month. Most of my coworkers are ex-military who tolerate zero crap from each other. We worked very hard to provide the best services to our users despite taking abuse from the public for being government employees.

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.