Why have your software development projects failed?

Question

I am looking for war stories about why software projects you were personally involved with failed. The more disasterous, costly, or instructive, the better.

Good responses should include the size of the project (size of team, length of time, etc) and an answer more specific than 'insufficient planning'.

Bonus points for a well-thought out idea on what could have been done differently to save the project.

EDIT: Some people have asked me to define "failure", which is admittedly very open-ended.

While it is conventional to define it as an inability to meet deadlines and budget goals, that's actually short-sighted in my opinion.

To me, a project fails when the stakeholders end up dissatisfied. For instance, sometimes it may be possible to blow your timeline and still provide an amazing business success. Conversely, you can meet your budget and timeline goals but deliver the wrong product because the stakeholders weren't involved enough, or you misunderstood their priorities, or you didn't create a good enough spec, or you made a technology choice that didn't work out and was bad enough to be visible to the stakeholders, etc.

Deadlines and budgets do matter and are often vital, but I'm saying is that the artificial seperation of IT concerns and business concerns is destructive and rediculous. As people who are ultimately servering the strategy of the business, we should be tuned into the larger picture instead of trying to abstract that big picture out to a handful of narrow metrics.

Anyway, enough of my idealism. :) I'm more interested here in the spectacular failures than the ones we might be inclined to debate about. If you've seen one, you know what I'm talking about!

Answer 1

Generally, any project I have ever been involved with that failed, failed because the project did not have the initial requirements correctly identified in sufficient detail, which led to the project schedule being incorrectly short/agressive.

When the project went long because the amount of work was larger than anticipated, including gathering the correct requirements, the project ran over budget and was ultimately pushed behind other projects where were ultimately of higher priority.

I believe this case happens often in organizations which do not properly gather requirements.

Answer 2

I was a programmer on the Kodak Cineon project. It failed because Kodak failed to realize that you can't have 20+ people developing a project that's designed to be sold to post production houses, when there are only a few dozen post production houses in the world. Plus if you give your product away free to a post production house that belongs to your company, their competitors aren't going to be too happy about paying for your product.

Kodak should have either kept the project going until more post production was being done digitally, or they should have invested the money to make it into something that could be used for desktop movie production. Instead they cancelled it.

Answer 3

I have worked on lots of failed projects. Many of these were technically successful but ultimately a failures. Some reasons were:

1. The project was a pet project of the owner so the requirements changed weekly. Although released the project never gained a foothold in market before it morphed again.
2. The project was released and had initial teething problems but was fairly good overall, but that was nothing compared to the infighting and legal action among the founders. Company went broke soon after.
3. The project worked really well, but there was just not a big enough market for the price point it was in. If we release internationally (not just Australia) it still has some chance of success.

Answer 4

Identifying the key stakeholders earlier and explaining their roles in the entire project. I would also say that not taking into consideration the time necessary for completing the project, which took my time away from my other normal duties.

Last but not least, developing testing procedures for end users would have gone a long way to ensure a successful project.

Answer 5

A project that I inherited was already in its death throes. I was the newest developer on a team of four. There were multiple problems:

• Too many cooks in the kitchen. Everyone had their own way of doing something and would continually go in and change other people's code to make it look and work like their own without telling anyone. Not only is this bad for morale, but it introduced so many bugs in code that was already tested.
• Too many egos. Code reviews were a pissing match and very rarely were on task and never produced anything valuable. It was to the point that people were calling in sick on code review meeting days.
• No cycles for maintenance. Every release was about adding features and fixing bugs as fast as possible. If a larger underlying cause was at play, working around it was the status quo, with the promise of "fix it later" becoming the mantra from above.
• Roles are meaningless. Jr. Developers needed guidance and couldn't get it. Sr. Developers clammed up and couldn't help the Jr. Developer because they "were way too busy and working on complex code".

Ultimately, it was a combination of methodology and work ethic. The free-for-all approach allowed the rapid production of code, and quality was not terribly important. After a few changes, the team is now my team and inside and outside our department, the importance of planning and methodology are the new war-cries. Giving everyone an opportunity to voice their opinions without exercising them at the code's expense helps as well. This was accomplished through developer workshops where we share ideas and proof of concept work. Tandem refactoring has helped both the code quality and the developer relationships.

There is still a long way to go, and the learning process is painful, but we are already seeing the product improve iteration over iteration. It puts us in a much better position for new projects, as well.

Answer 6

We were hired to create a web-based process plan software for a manufacturing component. The requirements were well defined, and the stakeholders seemingly were identified. We designed and constructed the software in about 6 months. It was a slick piece of software and did exactly what they needed it to do!

We were ready to roll the project out into to production when everything fell apart. Certain stakeholders bailed out, some terminated, some wanting no part in the upcoming change ... it was a nightmare. What was the problem ... the real problem is we had no customer champion! We should have had someone on the executive management to champion the project!

Thankfully we did get paid, but we felt like we had still failed because we had created a great piece of software that never went into production.

Answer 7

OK, a war story. I came into a project in the middle (a year long project, they'd already been working on it about a year, and work continued for at least another year).

Dysfunctional points, in no particular order:

-When I came in, there was no source control. There were several different versions on different servers, no one was quite clear which one was definitive.

-Developers were hired by managers without any discussion with tech leads and assigned to jsp pages (without any guidance - fresh out of school!)leading to a nice mix of data presentation technologies, all of the "queries mixed into the jsp pages somewhere" variety.

-our client controlled the development process, and had their own onsite developers. We developed for them, they "owned" the oracle database. When we had to make changes, since it was a multi-day process to add a field, developers would just shoehorn values into an existing one. Like, there's an unused varchar field called "newsletter" so we put a list of delimited ids in it. Of course we don't document what's in the field or what it means.At one point I asked several members of the dev team (who'd been working on this part of the application) how a particular kind of record was saved, and where it was saved to. Nobody could even agree on what the developed componets actually did.

-The client had developed a system they were very proud of. The good part was an http caching system. The bad part was that they'd somehow decided that their cacheing system had to be a CVS front end. What this meant was that all development was done on eclipse using a plug-in that made all code edits actually function through a soap interface to their CVS server (imagine looking for a line of code when there's no search, you have no local copy of the code, and you can only look at one file at a time over a slow interface). There was a running appserver instance connected to this monstrosity, and when you "saved", your code was sent over a SOAP service which automatically compiled and loaded your code on the SINGLE running server (since you never had all the code you couldn't create your own local instance). Where you could preview your changes (assuming that none of the other 20 developers working remotely from 3 sites hadn't recently changed anything that might also reset the server. This was distinct from committing, which would then overwrite ALL the running code with the repository version. All developers shared the same server. Which often went down.

As an added bonus,as the server compiled the class files but didn't commit them to CVS, and deployments were made by copying the classfiles to production, there was no way to know what versions of the code were actually running, or even if they corresponded to versions that existed in the repository. They were very, very proud of this system.

-The project manager would often agree to changes with the client, but kept no written records. Many, many changes. One day he left at 3AM, ran a bulk eraser on his drive, and disappeared to start his own business (with, as it was rumored, poached clients).

The client eventually sued.

Answer 8

I worked on a $40M project for an insurance giant in the late nineties. The biggest problem was mismanagement of the project by a leading consulting company.

I can't give you names because telling this kind of tale out of school gets you in deep legal trouble, so we'll have to call them A (the insurance company) and B (the consulting company).

B got the job because a newly promoted manager at B was a daughter of a director of A. It is entirely possible that said daughter was promoted in order to secure the contract. I don't know but it wouldn't surprise me.

Anyway, B was a Microsoft shop and appeared determined to use every Microsoft technology possible. In particular they were using MTS, as far as I could tell on the basis that "transactions are good".

As a result, they were also trying to use VB to produce COM objects (for use with MTS).

Both of these products were pretty raw for the use to which they were being put, and VB programmers wouldn't know a memory leak if it bit them on the arse, because such things are outside their protected little realm.

Ironically another nascent MS product would have been much better suited to solving the problem at hand. They should have written an ASP application. The transactional behaviour they wanted never eventuated for reasons that are long and complicated.

Eventually the project was killed by something else entirely. The mainframe people told us our results were wrong because they disagreed with the results produced by the mainframe software. We checked and rechecked our code, and checked the math behind it, and ultimately proved that our results were correct. Not long after this the project was abandoned. I strongly suspect this was because we proved they'd been incorrectly billing insurance premiums for twenty years.

Answer 9

Probably the most instructive one was a project I did for a client; it was a primordial agile project, planned, spec-ed and developed in a conference room with stories, domain model and design information maintained on flip chart pages around the room.

We worked for the services branch of a major hardware manufacturer, and the customer's standard desktop machines came from another manufacturer. First debacle: we planned to start on Monday on a 10 week schedule (3 3-week iterations and a final week of demos etc.) Only we didn't have hardware: our manager had announced that we MUST use our branded hardware, not the customer's standard. He SWORE it would arrive by Thursday. He didn't specify which Thursday. We didn't have hardware for three weeks, at which point the customer finally told OUR manager to get stuffed and provided their own hardware after all.

Second debacle: we had planned for "high speed" Internet connections, ie, 9600 baud. (It was a long time ago.) After three weeks, we learned we could only use 2400.

Third debacle: Our manager (NOT the customer) kept adding requirements that would make it look fancier. Time wasn't added. In fact...

Fourth debacle: with 2 weeks left on the schedule, OUR manager (not the customer) announced we needed to deliver a week early in order to be able to announce the project at a trade show. About then, one of the four developers had a car crash and broke a collarbone.

Needless to say, pretty well none of the demos etc worked out; our manager was, um, reassigned; our customer sponsor retired.

Oh, and on more or less a dare, two of us proceeded to implement the whole system in a week's work.

Answer 10

Since "Failure" is undefined, lots of things are failures.

A project is scoped and planned: find and integrate a new retail planning application. The analysis starts, proceeds on time, and on budget. We get to architecture and technology selection exactly when expected.

We review a number of products and select one that delights the customer. On time and on budget. Totally based on the original scope.

The project is then cancelled.

Is this failure?

• Yes. It didn't accomplish the stated scope of integrating the selected product.
• No. The stated scope turned out to be crazy, no product could correct the existing problems in legacy systems.

While it's clearly a failure, the customer was delighted.

So what does "failure" mean?

• Failure means to meet originally stated scope. Consequence: All learning -- all changes based on learning something new -- is a failure.
• Failure must mean something else. But what?

Answer 11

Most of the projects I have worked on have not technically failed because of one thing. They forgot to define what success is, so there was no way to tell when we failed. You keep plugging along, like rowing in an ocean of jell-o. Feels like you are working hard, but you are not getting anywhere fast.

I think part of the reason they fail is rooted in that very issue, they do not know what they want so they cannot define success. I actually think that would be ok as long as everyone would agree up front that we do not know what we want. It would change the way development is done completely (and we shall call it Agile).

Answer 12

How do you define failure?

All the late projects I've been on (which is a large percentage of all the projects) were late due to combinations of the following:

• Adding features without extending timelines or removing something else
• Optimistic estimates

While I've never been on any "killed" or "cancelled" projects, I've been on many abandoned ones, which all work like this:

• Management decides we need to build X
• Developers begin building X
• Something else more important or newer or shiner looking comes along
• Developers shelve X, everyone intends to finish it "someday"
• Years later, "someday" still hasn't arrived, and the half-written code for X gets thrown away.

The last step is optional. Often the half-written code to support feature-X just hangs around crufting everything up, but nobody can remove it because we still plan to use it one day. sigh

Answer 13

I don't have a long story, but i want to get this off my chest.

Build a call center system where you can import client info and make a project to call these clients. Then ask a series of questions (generated by an admin in the backend) and then when the caller is done with the questions he submits the info and gets a new client to call.

They wanted statistical graphs about everything and the specs changed with every meeting.

The failure point....

Delivery Time: 6 months Development Team: 1 person (not full time)

Answer 14

Failed because of an ORM framework period!!

It was supposed to solve all our problems. But in the end the performance was deplorable and with the number of tables we had the configuration and maintenance nightmare caused it be a dead end. We tried all the tricks and even got experts involved but it was too late. The queries were all over the system with thousands of lines of code mapping ORM objects to real Business Objects..

I don't know why they even choose an ORM for an enterprise application! I will not name the actual technology but it is safe to say the technology would not have mattered, all the ORM layer technologies would have behaved the same.

Answer 15

Most of the projects I've been a part of could easily fix most of their problems by following the Lego Process which you can read about here

Answer 16

The company I worked for at the time had about 20 developers working for a few months on this simple order processing transition from one system to another as the company bought a company that ran 3 sites and everything had to get migrated for the first phase of this process. I got started on this project my 3rd or 4th week on the job as we had just finished a similar migration for another 3 sites that the company had acquired earlier. I remember 3 weeks before the deadline of April 15th there being a department meeting where if anyone had concerns about meeting the deadline to bring them up immediately but I had just started doing my part on this project which was creating an XML API in classic ASP to take an order or look up basic information in the system. The initial launch happened May 25, which was more than a little late and the director of IT that was there when I started had left by then I believe.