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."
LESSON NUMBER #1 (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
Agile is the death of quality!
Not necessarily. In my hands, I guarantee you that Agile can deliver Quality.
However, I had worked in a Quality Control team before, and after, in a Quality Assurance one. So I know what must be done and why, so I know when some tests can be postponed, and what tests would be useless in a given moment.
The fallacy on the Agile movement is believing that all you need is coders. Worst, they think that TWO Quality ignorant developers together will compensate for the lack of formal testing. You can't give what y
Re:LESSON NUMBER #1 (Score:5, Funny)
Re: (Score:2)
Experience comes from bad judgment.
Projects are much much more than code (Score:3)
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.
Natural Selection (Score:3)
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.
Re: (Score:3)
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
Re: (Score:2)
In civil engineering the problems and needs are well understood, you also either build something or you don't.
Being the reason I don't think that Management is the key problem on I.T.
In IT the problems and needs are NOT well understood. Even when you do a ton of requirements gathering there will pop up edge cases or the legislative requirements change and you need to change your scope.
Yes. Somehow, some guys decided that it would be a good idea to start Projects without a well bounded requirements set in advance. And then the very same guys insisted in using management practices that works only on projects where that requirements set is well known, bounded and established.
You get what you design.
We are wrapping up a 4 year health records system implementation (successfully, not my credit though, I was just a SME on it) and we have the big brown paper sheets the original workflow and process needs were mapped out on, they are laughably out of date. A big part of the success is the platform we are using is custom but its a framework so some areas were able to be their own subprojects.
Good design.
Most of the big failed projects that I have seen the common complaint is the scope creep and changing scope made it impossible to actually deliver. Coders can only code what they are asked to, yes there may be bad code in there along with the good code but that code does not matter if the scope changed and its no longer valid.
Agreed. And the most successful projects I have seen are the ones that can be break in small enough parts wher
Re: (Score:2)
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.
Re: (Score:1)
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
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
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.
not impossible to say (Score:2)
Reasons things fail (Score:5, Insightful)
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."
Re: (Score:3)
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.
Re: (Score:2)
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.
Re:Reasons things fail (Score:5, Interesting)
Re:Reasons things fail (Score:4, Insightful)
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: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
Not in government myself, but I'd like the people who rag on the government to start showing proof of their work.
And no, you don't get to say X government project failed, so all government projects fail.
How about for starters the complete failure of US federal and state governments to price a project so that the actual spending more or less is in line with the original estimate of spending?
Re: (Score:1)
Re: (Score:2)
You need to look at the failure much earlier in the chain.
I agree. The point though is that government contract pricing in the US is way out of control with actual costs having little to do with the original low ball estimates. This leads to disastrous future uncertainty, including both higher risk of way higher costs (well above double the initial costing) and increased likelihood of program cancellation.
Re: (Score:2)
To add to your point, the procurement process is such that it takes almost two years to draft an RFP, get it approved, set it out for the six months, evaluate the bids, submit to board approval, have the board approve it (a month later) and then send if off only to have none of the original components from the original RFP be unavailable, draw up a substitution list, have that go through a quick (two month) review process and finally start the project.
Yes, it can take two years from Project go-ahead to when
Re: (Score:2)
Re: (Score:2)
Then you are making the mistake that NASA's function is only to build rockets and send things into space.
And you base this on what? The thing to remember here is that we have a public goal and costing which are obviously not being met. The previous AC demanded systematic evidence of government projects failing. Not meeting publicly forecast costs is one obvious way that this happens as I mentioned in my other repl. But having ridiculously inflated costing in the first place is another way this fails though without the appearance of failure.
Re: (Score:1)
Re:Reasons things fail (Score:5, Informative)
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: (Score:2)
Most people I know are more responsible with other people's money than with their own, because they feel responsibility for it.
Please send me all of your money; I promise not to spend it on you.
~Loyal
Re: (Score:2)
Most people I know are more responsible with other people's money than with their own, because they feel responsibility for it.
And I bet most people you know don't have access to a lot of other peoples' money and thus, don't have a lot to feel responsible about.
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:3)
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.
Re: (Score:3)
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)
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
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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.
Re: Reasons things fail (Score:1)
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)
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: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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.
Re:Reasons things fail (Score:4, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
Re:Reasons things fail (Score:5, Insightful)
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).
Re: (Score:2)
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).
Re: (Score:3)
Re: (Score:2)
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."
Re: (Score:2)
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!"
Re: (Score:2)
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.
Re: (Score:2)
Software is not 'fire and forget' (Score:2)
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,
Re: (Score:1)
That is the wrong approach that I am talking about. You should be thinking longer term, build a relationship with a small firm like mine or whatever. The difference is we have tons of experience, tons of working code, tons of components and our prices are globally competitive (the team is in different countries), we can truly control our costs. Beyond that we know how to get a project from 0 to production and to support it, our entire business model is enterprise level software and support for small and
TL:DR (Score:2)
* Poor Management - people, time, money, hardware
* Poor Code -- either assumptions, or sloppy code
* Lack of Quality Assurance
Usually one or more.
Re: (Score:2)
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.
Re: (Score:1)
Dock the severance pay of the old IT guys / HB1 (Score:2)
Dock the severance pay of the old IT guys that failed to train the HB1's right.
Re:Dock the severance pay of the old IT guys / HB1 (Score:4, Informative)
Re: (Score:2)
Hey, it's only a stereotype that visa workers are skinny.
Re: (Score:2)
H with increasing numbers makes a lighter, thinner line. B with increasing numbers makes a darker, thicker line.
HB is basically the middle[1]. Assigning a number to it makes as much sense as saying something is very zero.
(an actual oldtimer, with a preference for 2H)
[1] apart from F, which is stupid, and stands for "fuck off".
Root cause analysis (Score:2)
Suggests that management hubris plays a big part in IT Failures.
Re:Root cause analysis (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 is all about project management (Score:2)
Woodpeckers (Score:1)
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
Re: (Score:2)
"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]
Learning from our mistakes (Score:2)
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
Reason 1: Magical Thinking (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
- 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.
Re: (Score:2)
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.
Mismanagement (Score:3)
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.
Failures 1A and 1B: Offshoring and Outsourcing (Score:4, Insightful)
They overpromise, underdeliver, and screw everyone when all is said and done.
Are these different than the past decade? (Score:1)
Re: (Score:2)
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.
Failure rate? (Score:3)
It is good that projects fail (Score:2)
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
Shit! (Score:2)
Which decade of IT failures? (Score:2)