Fog Creek Software
Discussion Board

Experience with projects that failed?

Have you ever been on a project that failed to deliver on reasonable requirements?

I mean a project in which the customer asked for a technically feasible product, and the team tried to deliver it but failed.  I want to ignore projects with patently ridiculous deadlines, since the fault of those is obvious.

What happened?

What specifically caused the team to fail?

Brent P. Newhall
Thursday, May 22, 2003

I have yet to encounter a project that failed for a reason not covered in "Rapid Development" section 3.3 "Classic Mistakes Enumerated".

For example, I was on a project that failed because we decided to use a new technology that didn't work as well as advertised, which is mistake number 34 "Overestimated savings from new tools or methods".

P.S. Does everyone hate it when I refer to books in the "canon" rather than directly answer a question?

Bill Tomlinson
Thursday, May 22, 2003

Bill: It is mildly frustrating, especially if one doesn't happen to have that text.  I don't, for example.  (No adverts from anyone, please; I do want to buy it.)

In this case, it's helpful to know that all the mistakes you've experienced were "classic" mistakes.  But that doesn't advance the discussion.

Brent P. Newhall
Thursday, May 22, 2003

The only spectacular failure I've ever experienced was when a small company acquired a bunch of funding, and thus, a bunch of engineers in a very short amount of time.

What we ended up with was a handful (4 or 5) of really high quality engineers, and a bunch of people (35 or so) who didn't have the requisite skill level to do the work (a lesson that "no hire" should really mean "no hire", and shouldn't be overriden by anybody, including the VP of R&D, just because we need headcount to make the investors happy).

Aside from being just plainly not skilled enough to do the job, those 35 people stopped the 4 or 5 skilled people from being productive, because of the required process that had to be put in place to stop the 35 from destroying the product. What little that did get done was of such terrible quality that it was virtually impossible to integrate and get running. To this day, I have no idea how we managed to deliver anything to anybody. (When we first ran our product through BoundsChecker, it had to run overnight, and eventually crashed the machine because it sucked dry multiple gigabytes of drive space for the error log.)

We went from a highly functional, highly productive engineering department to one that destroyed tens of millions of dollars and the livelihood of more than 100 people.

Never again. I would rather interview 1000 people and turn down a hundred "maybes" and hire nobody, then to end up hiring someone who sucks the productivity out of a small and nimble group.

Brad Wilson (
Thursday, May 22, 2003

Brent: fair enough. It is, after all, a variant on the RTFM answer; which is always annoying.

For another failed project example: we had contracted out the development of a subsystem to another company. But the contract wasn't well written (mainly, didn't have sufficient penalties for lateness). So the sub-contractors didn't deliver to the schedule which caused lots of follow on problems. It wasn't really a scheduling problem, we still felt that they should have been able to complete the work and they had a good spec. They were just lazy and greedy.

No specific lesson to learn though. Just that contractor management is hard.

Bill Tomlinson
Thursday, May 22, 2003

I like it when people post about books that have cannonical answers to questions... It makes me reconsider buying those books.
Thursday, May 22, 2003

When I was just starting out, I was tangentially involved with one project that failed. 

The main reasons were that most of the hard architecture questions were put off until the last possible minute, with the arrogant assumption that "once we get a prototype up and stumbling, we'll refactor and get it right."

I remember an e-mail from one of the client's project leads to everyone which read:

"I remember that when we decided to create the WeaselGraphics class, we made a concious and deliberate decision to not extend java.awt.Graphics. And there were a lot of really good and compelling reasons not to.

If anyone happens to remember what those good reasons were, please beep me immediately. I am in the process of refactoring WeaselGraphics to extend java.awt.Graphics."

I guess that *could* be considered design review...

There were a bunch of other very similar problems, involving what happens on the client and what happens on the server.

All the code everyone depended on was in constant flux and  everyone was spending their days fixing the damage caused by the shared code team. A whole bunch of applications never got past the "really buggy alpha that we're calling a beta and unleashing onto lots of poor unsuspecting users" stage.

(At this point, I'd like to point out that I was entirely blameless in this fiasco...)

Gustavo W.
Thursday, May 22, 2003

Lack of communication.

No one feeling responsible.

No concept at all.

New ideas all the time.

Here Th. ere (e-Very where)
Thursday, May 22, 2003

In a job long ago...

We sub-contracted a piece of work out, with no penalties for lateness, or lack of correctness.

Ugh.  What a fiasco.  The sub-contractor delivered a non-functional product late, with no penalties.  In the meantime, we had penalties assigned to us.

Happy to be working
Thursday, May 22, 2003

This question strikes me as being a bit odd. If you assemble good developers and give them the resources they need, they will deliver good software.

Most interest is thus on defining what resources they need, and, for management, reconciling this with conflicting needs to obtain products faster and more cheaply.

By definition, a project that fails has failure points.

Thursday, May 22, 2003

I was on a huge mainframe to ERP/CRM project that has been going on for at least 4 years (and still is). I guess it's not a failure unless it's finished or cancelled.

Solution Provider
Thursday, May 22, 2003

Sometimes, we just cut a few two many corners.

I had a project fail, and I explain why it failed in the follwing artcile:

My article:
Working slower can = more work

I wrote the above before I read the book people ware, but that book also has a few hints that working too fast can hurt the project. The real point (I will save you the chore of reading my above article)  is one needs time to think and reflect. This think time is the most powerful tool we developers have, and it is often one of the first causalities of a project when it starts to get behind.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Thursday, May 22, 2003

Nearly all projects fail because they

a) don't satisfy the business objectives
b) are over budget and time

an over budget/time application that does satify the business requirement will probably fly in the end. Projects get dumped when they won't meet the business requirement, in my experience companies will pay through the nose if they are going to get what they want.

I would say requirement capturing and design mistakes sentance a project to doom way before the coding starts.

Friday, May 23, 2003

Brent: You can find the classic mistakes and other excerpts from the book at , select the 'books', then 'Rapid Development' links.

Marktaw: Ditto. Just go and buy the damn book. You know its makes sense ;)

I recently read The Software Project Survival guide. That's good, but different. For my money, Rapid Development is the better book if you have to choose between them. Better laid out, better examples, more complete, however SPSG comes with templates for processes which may prove useful. Some disagree though, notably Joel who was uncharacteristically dismissive of the template for specifications.

Friday, May 23, 2003

> Marktaw: Ditto. Just go and buy the damn book.
> You know its makes sense ;)

Alright... I'll bump it from my 200+ item Wish List into the Shopping Cart.
Friday, May 23, 2003

I have seen the following quite a few times:
- Tender is written with mostly clear description of the work
- Contract D is assigned to company X not on the basis of qualification or proposal but because of "connections" between the client and the contractor.
- Company X has other jobs running that are more directly followed up and do not fall under "favoritism". As a result only a few junior people ar working on contract D to give minimal compliance.
- Delivery fails completely on contract D, but contract D is declared a success to avoid investigation of favoritism in the assignment.

Just me (Sir to you)
Friday, May 23, 2003

Two projects in which I've been involved failed because of communication problems. The project mgr talked to the client and told us what he wanted. We did what the project mgr said, he reviewed it and approved it. Then, we went to the client, and he said "That's not it". And then the project mgr came to us and said "You didn't follow my spec correctly" :)

Another failed because my 4 weeks estimative got slashed to 1 week. By the end of the I had a product ready, but it had so may flaws (conceptual, not coding bugs), it was unusable (e.g., a workflow component that allowed for you to edit someone else's comments).

Other than these three, I have had several projects late, but not cancelled.

So, another vote for the classic mistakes :)

Paulo Caetano
Friday, May 23, 2003

Thanks for all the replies, folks.  I'd like to read more.

FWIW, I'm not looking for a "top ten" of classic mistakes; I'm interested in specific real experiences of people in this forum.  What have we actually observed of failing projects?

Brent P. Newhall
Friday, May 23, 2003

1) Planning to make it up later

2) Unrealistic schedules

3) Jumping to code

4) Failure to do the work at the fuzzy front end

5) Adding additional requirements without increasing the schedule


jmho ...

Matt H.
Friday, May 23, 2003

I have seen (and at some time or other made myself) almost all of the classic mistakes, which was the main reason I mentioned where you could read them. If I had thought I might influence you purchasing decisions, I'd have included my own Amazon links in the post :)

I think the single biggest problem I have seen is poor communication, which leads people to make other mistakes.

Just to add some good news, the most recent process I learned about (last year sometime) is the "Fagan Inspection". This is basically a code review for conformance to standards. I've been doing this informally for years, but didn't release there was a methodology associated with it [for 'methodology' you could probably substitute 'gravy train for Michael Fagan'].

Friday, May 23, 2003

Brent P. Newhall wrote, "What specifically caused the team to fail?"

FYI: I believe Robert Glass (could be someone else I don't remember) wrote an entire book on large software project failures and what caused them to fail.

Here is a question that you might want to ask sometime in the future,  "What works for project teams or organizations that claim to consistently deliver software on time and on budget?".

Brent P. Newhall wrote, "FWIW, I'm not looking for a "top ten" of classic mistakes; I'm interested in specific real experiences of people in this forum.  What have we actually observed of failing projects?"

Most of us (if we really tried) could come up with a list of reasons why (from our perspective) a particular project failed. What do you think you would learn from these lists? I believe the only way you are going to find some type of pattern (large projects typically fail because ... small projects typically fail because...) is to spend several years gathering lots and lots of data from all types of  projects.

One Programmer's Opinion
Friday, May 23, 2003

OPO, you seem to be assuming that I'm looking for a pattern.

I'm not.

I don't want a list of mistakes.  I want specific situations to chew on.

Brent P. Newhall
Friday, May 23, 2003

Well, in 10 years of doing software, I've only ever shipped a product once (so far - latest job looks promising). And the one thing that I shipped was relatively simple modifications to an existing product.

Here's the list:
EEG Monitor - spec kept changing, new features kept being added, hardware issues, etc, etc. Company eventually went under after something like 6-7 years of muddling through.

Blood pressure monitor - I did some small changes and a lot of test work. Product shipped!

Fish sorter - after about 8 months of work, deemed to be less important than wood project. I move over to wood project, fish sorter dies (wasn't going to make it in the marketplace as we were working on it anyway - it would end up being way too expensive).

Wood project - cool ultrasound gizmo for sawmills. Great idea, but our little company sold itself to a big company, and after we didn't deliver for a while (we let ourselves work to too many sub-projects and we let ourselves get pushed to try to go into the sawmill before we had the science finished). Ultimate finish: The big company (which had money problems when they bought us) killed our little division to try to make their books come out.

Present project - Not a failure yet! Unfortunately, it is an ill-planned port from an 18 year old code base running on a custom os to Linux. The inital port was done so a contractor could work under Linux instead of custom hardware + NT, and somehow ended up as a product. We'll see...

Michael Kohne
Tuesday, May 27, 2003

I've yet to see a project fail because of something that isn't covered in the "Classic mistakes" section of Rapid Development.

Some of the more common ones I've come across are :

* Failing to not hire bozos, even when the company desparately needs the resource. Their damage can last for years and years after they've moved on.

* Failing to plan a product in small increments and milestones. Always ended in chaos towards the end because it felt like we had "bags of time" earlier on.

* Lack of empathy with management and developers.

Better Than Being Unemployed...
Wednesday, May 28, 2003

*  Recent Topics

*  Fog Creek Home