Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Compare cell phone plans using Wirefly's innovative plan comparison tool ×
IT

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

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."
This discussion has been archived. No new comments can be posted.

Lessons From a Decade of IT Failures

Comments Filter:
  • LESSON NUMBER #1 (Score:5, Insightful)

    by Lisias ( 447563 ) on Friday October 30, 2015 @11:54AM (#50832931) Homepage Journal

    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,

    • by Dragonslicer ( 991472 ) on Friday October 30, 2015 @02:29PM (#50834387)
      Also summarized by the saying, "Some people have 10 years of experience. Other people have 1 year of experience 10 times."
    • Good judgment comes from experience.

      Experience comes from bad judgment.
    • I've worked on big IT projects, and I've worked with government people who've worked on them, or managed or procured them. One director at Livermore Labs in the late 80s commented that he'd never seen a billion-dollar computer project succeed - it's just too big to do the communications that are needed to make it work, through the requirements, design, and management parts, and he was trying to work on how to break projects down into things that were small enough that they could be managed and implemented.

      • When small projects fail, the contractors move on. By the time large projects fail senior managers need to be promoted.

        Over time, people that work on smaller projects are the competent ones, whereas the people that work on large projects have fantastic skills in working in a bureaucracy, but none in actually developing software.

      • by Lisias ( 447563 )

        You underestimate the importance of good coders. Or perhaps, overestimate the importance of managers.

        Good developers can delivery a viable product besides bad management. But the best management of the World can't deliver a viable product without a minimum threshold of good code!

        I agree and understand the problematic of big projects, I had my share of it too. But when the worst happens, and it eventually happens (more than once I saw a project being trashed by external causes, as a legislation that was chan

      • I've worked on big IT projects, and I've worked with government people who've worked on them, or managed or procured them. One director at Livermore Labs in the late 80s commented that he'd never seen a billion-dollar computer project succeed - it's just too big to do the communications that are needed to make it work, through the requirements, design, and management parts, and he was trying to work on how to break projects down into things that were small enough that they could be managed and implemented. Even the successful things are messy at large scale.

        This was long before Agile (which is pretty tasty Kool-Aid, for some kinds of projects, but has its own limitations).

        Agreed. Any software project which requires managing, rather than getting managed as a side effect of the code writing, is already halfway on the road to failure. Because at this point, human ability to write software outstrips human ability to manage software projects.

    • by ebvwfbw ( 864834 )

      No.
      Lesson number one is untested code doesn't work.

      Lesson number two is to always document what you're thinking in the code. Don't read more into this than I intended - brief, to the point notes that anyone that codes would understand what you're up to. Don't write a book. Don't go into too much detail.

      Lesson number three is the toughest. Your code, sometimes code you spent a year or more developing may be thrown away at a later date. Don't take it personally. I had something I maintained for about 10 years

    • First you see the code. Then you study the code. Then you know the code. Then you love the code. Then you hate the code. Then you rewrite the code.
    • Makes me wonder then why every developer I met so far (about 100) is fatally allergic to bug fixing. They rather fake their own death than fix bugs that they put into the code. Commonly, they just state "This is not a bug!" or "This was never requested!" effectively dismissing QA having any clue or say in the matter. QA is not the bad guys, QA is a mirror that developers can stand to look into....entirely self-inflicted! Yes, please, write bad code if that helps you learn, but then, please, fix it once you
      • by Lisias ( 447563 )

        Makes me wonder then why every developer I met so far (about 100) is fatally allergic to bug fixing. They rather fake their own death than fix bugs that they put into the code. Commonly, they just state "This is not a bug!" or "This was never requested!" effectively dismissing QA having any clue or say in the matter. QA is not the bad guys, QA is a mirror that developers can stand to look into....entirely self-inflicted!

        You need new friends, i mean, developers.

        You get what you promotes. If you promotes bad developers, you will get bad developments.

        Yes, please, write bad code if that helps you learn, but then, please, fix it once you know better and don't give me all that BS. And stop discussing and triaging bug reports, go and fix the issues. Takes typically way less time than the discussion aimed at convincing everyone not to do anything.

        And by all means, fire the fscking bastards that don't fix their mess. You get what you promotes.

  • impossible to verify?
  • by JustAnotherOldGuy ( 4145623 ) on Friday October 30, 2015 @12:00PM (#50832993)

    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: (Score:1, Insightful)

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

      • who cares it isn't really my money being spent

        While I suspect that you're a tad sarcastic here, I would like to point out, yes, it is your money being spent. It is your money. It is my money. It is our kids and grandkids money (debt).

        The fact that I have to say it is really sad. And yet, enough people don't care that it is still a reality. "Not my money" is a big fat lie.

        • I think the point is, one driver for govt IT failures is lack of accountability or concern over finances. If the govt wastes a lot of money, no worries, there will be more money next year. Maybe a head will roll just for the good publicity. but otherwise things keep moving forward BAU.

          • by creimer ( 824291 ) on Friday October 30, 2015 @01:01PM (#50833543) Homepage
            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.
            • by chipschap ( 1444407 ) on Friday October 30, 2015 @04:22PM (#50835195)

              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.

              • Beltway bandits AKA Contrators not the little guy contractor that is actually on the ground doing the work but the three-letter types. Most of the little guys doing the work are conscientious about doing a good job and saving money.

                • Good point, thanks for posting the clarification. The little guys competed and survived on merit alone. They ended up doing a lot of good work for just enough money to get by[1]. The big guys had the right friends in the right places. They did a lot of bad work, if you can even call it work, and collected the maximum possible. Two different worlds.

                  [1] There was one major exception to this, but I'll leave it unsaid and avoid all the flames from the SJWs.

                  • And that observation confirms the problem with government.

                    The peons doing the work are obviously not calling the shots and essentially stealing from the taxpayer. It's the corporate entities and the politicians who kiss their ass who are responsible for the massive waste and fraud. And they are rarely held accountable.
        • by LoyalOpposition ( 168041 ) on Friday October 30, 2015 @12:33PM (#50833321)

          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
           

        • by khallow ( 566160 )

          I would like to point out, yes, it is your money being spent. It is your money. It is my money. It is our kids and grandkids money (debt).

          It is, if you control the project in question. But when it's just shoved down a rathole without any consequence for the guilty, then it's not your money any more.

        • The OP meant that those in the govt agencies who make the decisions think that way. There is no mechanism to fire anyone in an administration for mismanagement unless it is ridiculously obvious to be a criminal act...and even then many are shielded by any responsibilities due to politics.
      • by joss ( 1346 )

        Do you think the people running corporate IT programs are spending their own money ?

        No, ok.. well, do you have any evidence that large government run IT programs are more prone to failure than large commercial sector IT programs ?

        I think it's more a question of people are not very smart and large scale software development is hard.

      • by plopez ( 54068 )

        For as much money as the Gov't has wasted, I have seen the private sector waste more. I have work for small, midsized, and fortune 500 companies. I have worked for the US government, and have helped people, and state government. An there is nothing like a fortune 500 company when it comes to throwing money down a rat hole. They waste money like crazy and then lay people off. Small and mid-sized businesses are the most efficient and nimble; and the difference between working for state governments and the Fe

      • Re: (Score:2, Interesting)

        by nbauman ( 624611 )

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

        Actually, the Spectrum article says the opposite. The private sector wastes just as much money, and manages just as badly, as the government.

        The "Software Hall of Shame" includes

        http://spectrum.ieee.org/compu... [ieee.org]
        large companies and small; in commercial, nonprofit, and governmental organizations.

        I think free-market ideologues should read less Ayn Rand and more IEEE Spectrum. And pay less attention to right-wing theories and more attention to what actually happens in the real world.

        You ought to meet some government employees, as I did, who would rather serve their country than make a lot of money, corny as it sounds.

        I found

        • by khallow ( 566160 )

          Actually, the Spectrum article says the opposite. The private sector wastes just as much money, and manages just as badly, as the government.

          Here's what the article [ieee.org] you quote actually says on the matter:

          This is only one of the latest in a long, dismal history of IT projects gone awry [see table above, "Software Hall of Shame" for other notable fiascoes]. Most IT experts agree that such failures occur far more often than they should. What's more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. The business and societal costs of these failures--in terms of wasted taxpayer and shareholder dollars as well as investments that can't be made--are now well into the billions of dollars a year.

          Quantify "universally unprejudiced", show the authors actually did that analysis here, and then show that is even remotely relevant to your claim that the much larger private sectors wastes just as much money on IT projects.

          Recall that a lot of paying IEEE members work for government projects. Saying that the much larger private sector wastes money too at the same level while having no evidence to support that assertion is a sop to them.

          The

      • Having worked in/with the US military on and off for 30+ years I can honestly say I have never encountered this attitude or heard some say "Who cares it isn't really my money being spent."

        Now some contractors will try to rip off the government and perhaps they have that attitude but none of the GS civilians or GIs or the actual peon contractors have ever exhibited that attitude. A lot of them get pissed at waste because they know it is their own tax money being wasted.

        There is the bad thing where if you do

        • by khallow ( 566160 )

          Having worked in/with the US military on and off for 30+ years I can honestly say I have never encountered this attitude or heard some say "Who cares it isn't really my money being spent."

          [...]

          Now some contractors will try to rip off the government and perhaps they have that attitude

          There we go. Who gets to spend public funds again? The GI grunt on the front line or the contractor paying off the right people?

          The argument that government is chock full of honest people and hence, doesn't have the above attitude is only relevant, if those honest people are the ones doing or controlling the spending. They aren't.

    • by Anonymous Coward

      I'd like to add to your list: poorly defined scope. Everything I do seems to have a constantly moving goalpost as far as project scope.

      • Re: (Score:3, Insightful)

        by 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)

        • 2) Scope creep (the customer asked for a no-frills Ford, then says they need air, cruise, and a high-end stereo/GPS)

          Or, they say they don't need air, cruise and a high-end stereo and then complain it is too hot, doesn't maintain its speed and they aren't able to hear any music during their test drives.

        • by Bengie ( 1121981 )
          I have limited experience working with projects for customers, but it seems like the customer doesn't know what they want, but they know what they didn't want once they see it.
    • by Rob Y. ( 110975 )

      Here's another:

      Decision makers deferring technical decisions to project managers with a stake in defending their past bad decisions. Results in doubling down on mistakes long after they proved to lead to dead ends.

      And another:

      Corporate business plans focused on 'selling the company' or 'an IPO in a few years'. Creates a perverse incentive. An incomplete project with the promise of 'enormous success just around the corner' is an easier sell than the finished, quantifiable result. So the above 'doubling d

      • Decision makers deferring technical decisions to project managers with a stake in defending their past bad decisions.

        Generally falls under #4 and #2.

        And another:

        Corporate business plans focused on 'selling the company' or 'an IPO in a few years'.

        Often a result of #3 and #1, but not always in that order.

    • by JaredOfEuropa ( 526365 ) on Friday October 30, 2015 @12:13PM (#50833105) Journal
      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.
      • I would add to that: stakeholder apathy, or failure to generate sufficient buy-in.

        Often falls under #1, Failure to plan ahead, and/or #4, Failure to manage resources properly.

    • This is an older article, but according to the research, 68% of IT projects fail [zdnet.com].
      • by JustAnotherOldGuy ( 4145623 ) on Friday October 30, 2015 @05:43PM (#50835679)

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

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

    • by khallow ( 566160 )
      Here's two more:

      Failure to control the project (changing requirements after the project is well underway).
      Conflict of interest (getting paid more for delaying or hindering a project).
      • Failure to control comes in different flavours: one is scope creep resulting from a failure to control requirements. Another cause is controlling requirements too tightly. I have never seen a large IT project defined correctly and completely from the get-go; during project execution there will be new insights, errors and inconsistencies are uncovered, and external cirumstances will change. Having control of your project means that you are prepared for change, equiped to separate necessary or sensible cha
      • I think a lot of projects aren't terminated early enough. A small failure becomes a medium one becomes a giant one. Egotistical managers insist on "making it work" long past the point of no return.

        It takes real courage to say, "This is failing, let's cut our losses now and not throw good money after bad."

        • It takes real courage to say, "This is failing, let's cut our losses now and not throw good money after bad."

          Yep, the Sunk Cost fallacy: "We've already spent so much on this, we can't quit now!"

      • Failure to control the project (changing requirements after the project is well underway).

        Conflict of interest (getting paid more for delaying or hindering a project).

        The first one usually falls under #2, Failure to adapt to changing circumstances*, and the second one often falls under #4, Failure to manage resources properly.

        * in this case "scope creep" and maybe also #1, Failure to plan ahead.

        • by khallow ( 566160 )
          There's of course some mild overlap between the 8 or so categories that have been discussed so far. And I wouldn't call scope creep a case of failure to adapt. There are some things you just can't adapt to. Getting dumped out of an airplane at a few thousand meters without a parachute is an example of such failure to adapt.
  • The list of failures [ieee.org] from TFA proves that software cannot be created and then not maintained, not constantly observed, not updated. Complex software that interacts with real life systems cannot be treated as if it is a 'fire and forget' thing. It is not.

    The "disappearing warehouse" case is perfect, nobody was keeping an eye on the system, nobody at all was actually personally invested, personally responsible. I have created a lot of software over my life, I built and own a retail chain management system,

  • * Poor Management - people, time, money, hardware
    * Poor Code -- either assumptions, or sloppy code
    * Lack of Quality Assurance

    Usually one or more.

    • I've seen "poor code" that was clearly good code, hacked together to get something done. It worked for what it was designed. It was "poor" in the long run because the system needed to evolve, but never did. The code didn't change, and it looked like garbage down the road a bit. It wasn't garbage, it just needed improvements, that were too costly to implement.

      That kind of code isn't really "poor code" when it was writtten. It was a quick hack that was forgotten. Hind Sight is always 20/20.

      • Agree, I've come across plenty of beautifully written code that in the end worked well, but totally missed the mark on what the user needed. Also came across buggy and cumbersome code that was of value to the user because despite all the shortcomings it did generate value. As far as point #3 goes, lack of quality assurance is often due to QA being a 2nd class citizen on a dev team....if there is QA to begin with. Lack of QA in my view is for a good part caused by sloppy code. Quality is the responsibility o
  • Dock the severance pay of the old IT guys that failed to train the HB1's right.

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

    • by tomhath ( 637240 ) on Friday October 30, 2015 @12:30PM (#50833283)

      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.

      • by jacobsm ( 661831 )

        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.

        But not before they receive their $$$$$ and moved on to their next opportunity.

    • Someone once told me I would be an excellent candidate for "root cause analysis" expert at RIM/Blackberry. I never looked after that career path and I'm sure glad I didn't. Now that I have 15 years more experience, I've come to realize that must've continue to be boring job ever.

      Hmm, which off the shelf answer applies to this scenario? I have like 2 to choose from.

  • It all comes down to the time, money, quality triangle. The more you focus on one aspect the more you lose on the other two. And because in the end projects are always focused on time and money, quality is almost always neglected. Especially in highly political environments where the ideas have to be implemented with low cost and this year projects are bound to fail.
  • by Anonymous Coward

    There was a saying that if builders built buildings the way programmers write programs, the first woodpecker that came along would destroy civilization. Having spent a few decades of my life writing compilers, dbms internals and similar I tend to agree. But I think that at the root of the problem is the issue of the invisibility of it all to those folks in expensive suits that control our resources and direct requirements and delivery dates. With a building, the construction is a matter that all can look at

    • "It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures come from the working engineers, and the very low figures from management. What are the causes and consequences of this lack of
      agreement?...

      Appendix F - Personal observations on the reliability of the Shuttle by R. P. Feynman
      http://science.ksc.nasa.gov/sh... [nasa.gov]

  • Existing organisations in developed countries have years of IT failure and legacy cruft to deal with... It's very difficult to make significant improvements because replacing existing systems is expensive, time consuming and often meets resistance. People dislike change, and most people are simply unwilling to challenge the status quo and/or don't understand the improvements that change could bring.
    IT in most places is horrendously insecure, buggy and unreliable. Things don't work well, and businesses end u

  • by ErichTheRed ( 39327 ) on Friday October 30, 2015 @01:52PM (#50834035)

    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.

    • by swb ( 14022 )

      All those things strike me as problem transference, not problem solving.

      Rather than fix the WAN problems (lack of capacity, bad architecture, etc), even if the original "problem" goes away, we've just adopted a *different* set of problems (complex architecture, lack of transparency, etc).

      The same is true for whatever personnel issues are associated with IT personnel and hardware/cloud. No real problem was solved, it was just transferred elsewhere.

    • by Tom ( 822 )

      - 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!

      This. Hiring Accenture because you think your in-house IT is too expensive. It's a bit like burning dollar bills because you want to save on heating expenses.

    • by Bengie ( 1121981 )
      I've noticed some common issues myself.
      1) Reinventing the wheel when there is a better solution already, and many times free.
      2) Thinking everything is a black box and will magically fix their situation. Everyone else is using it, so it must be good.
      3) Not making a new wheel because they think their problem is the same as one that has been solved. Many modern solutions have minor differences that become major differences when pushed to the extremes.
  • by DarthVain ( 724186 ) on Friday October 30, 2015 @02:45PM (#50834515)

    You can't have mismanagement without "management".

    Anyway there are plenty of reasons, much of them boring like budgets and staff resources.

    One however that isn't talked about much, is the ability to say "No" when talking about requirements analysis. Usually this is where nobody wants to say no to a manager who has seen things like the internets and iphones.

    Typically an application is created to solve a business problem. There is a tendency to want to throw everything and the kitchen sink into the project, more less because you can. I think if a lot of projects concentrated on producing a simple product that solves the core business problem in a very stable way without a lot of bells and whistles increasing the complexity of the project they would be a lot more successful. Nothing wrong with collecting the bells and whistles as requirements, that might be added at a later date, once the core business requirements have been met, deployed, and proven. If more time was dedicated to core than on fluff towards something that is functional, I think it would pretty much eliminate project failure, at least in that there would be some usable results, and not just a huge pile of code and documentation that is non-functional. Big healthcare systems come to mind.

  • by sethstorm ( 512897 ) on Friday October 30, 2015 @03:17PM (#50834775) Homepage

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

  • Just out of curiosity, how does this list differ from similar lists made 10 and 20 years ago? Are we learning?
    • by jacobsm ( 661831 )

      Just out of curiosity, how does this list differ from similar lists made 10 and 20 years ago?

      Are we learning?

      RFC1925 #11 - Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. So no, we're not.

  • by tomhath ( 637240 ) on Friday October 30, 2015 @06:39PM (#50836001)
    TFA lists a few big failures. But in isolation that list doesn't mean anything. Are we getting better or worse at implementing big projects? How many multi-million dollar projects were completed successfully versus failed? Humans are not perfect so there will always be failed projects, but there have also been many, many successful ones in the past decade.
  • Whenever a large IT project succeeds, some piece of bureaucratic process can and thus will become more complex.

    Consider the Australian tax office (or IRS). It costs the same proportion of GDP as it did 60 years ago, before any automation at all. But the tax legislation is several orders of magnitude more complex now. You could simply not support the current mess without a computer, it would have to be kept simple. It is the successful projects that enable the mess to be produced. Fortunately, many tax

  • Revisiting the old article, I notice there is only ONE of the 12 failure categories that DOESN'T apply to the project I'm on now! We are so fucked!
  • Would that be the lessons learned from the first decade with major IT failures (say, the 1950s)? Or lessons learned from the second decade of IT failures (the 1960s)? Or lessons learned from the third decade of IT failures (the 1970s), when big failures were getting bigger and more profound as failures)? Or lessons learned from the fourth decade of IT failures (the 1980s)? Or lessons learned from the fifth decade of IT failures (the 1990s - some absolute doozies)? Or lessons learned from the sixth decade of

Unix: Some say the learning curve is steep, but you only have to climb it once. -- Karl Lehenbauer

Working...