How many projects have you worked on that tanked?

Question

There's a common conception in software that x% of projects never get finished... but to be honest, I'm not sure at all if it's the case - and it's hard to know because most projects that don't get finished, rarely get talked about.

So I pose the question to a bunch of other developers: How many projects have you worked on that tanked/didn't get finished?

EDIT> Maybe I should clarify; when I mean 'tanked' I mean, the project didn't get finished - as in, not functional according to the agreed upon spec (formal or informal spec).

Answer 1

I've never worked on one that failed to complete, but I have worked on 1 that failed to take off as well as it could / should have.

Edit: Wasn't our fault either, we fulfilled the requirements almost entirely on schedule :)

Answer 2

If I'm only counting my professional career, they have all finished. If I'm counting my personal projects, they have all tanked.

Answer 3

I have 2 sites that have been completed but the client has then failed to publish content on. I guess this could be considered 'tanked'.

Answer 4

I've participated in two such projects One remains (as of this writing, as far as I know) as a one man operation with absolutely no hope for success, the other only exists as a destination for the wayback machine. The former was due mostly to totally inept management, the latter just bit off way more than it could chew right before the bubble burst.

Answer 5

Sometimes when the idea is raised that X% of projects fail, the measurement of 'failure' is taken from the 'deadline' or the 'cost' aspects. The question in my head, when hearing this kind of number is:

• how was this project judged,
• where did the metrics come from?

It all goes back to the 'accepted' project plan and the potential misunderstanding of the iron triangle (cost & features & time). Sure, we'll accept a project plan, but always there are incidents where the time or cost budget is blown. Even the features/quality measurement may cause a project to 'fail'. Scope creep is another cause of the supposed failure as well.

It's all about the measurement of what a 'failure' is, and how accurate or reasonable the project plan was.

Answer 6

To be honest, I'd have to think really hard to find any project that is 'finished'. Even after we've delivered to the client, there is always more that could have been done, more features to add, more performance tweaks, etc.

I guess it really depends on what 'finished' is though - is it finished if you stop working on it? If you decide that you've done enough and that it is time for a new project? Do proof-of-concept things count? Are they finished if the concept is proven, or after the concept is transformed into an app? Is your project still finished if the arena changes, or would it revert to 'unfinished'?

In the end, it all depends on if the person working on the project is satisfied with what they've built. If you're too much of a perfectionist, I doubt you have any project you can call 'finished'.

Answer 7

I can think of 12 major efforts and 3 of them failed to make it to market. Of those three, only one of them truly failed. The other 2 were delivered and just never made sense in market. I guess that gives me about an 8% tank rate.

Edit - I guess I should be more specific here. I only consider one of them an out-and-out failure even though we delivered the first pass of the technology. The failure was that no one noticed that there wasn't a viable market and our solution was way over the cost point of the miniscule market that did exist. Overall, I could this as a project failure since engineering could of ended the effort much earlier instead of bullishly pushing ahead.

Answer 8

As a consultant, I only work on huge, enterprise-scale things where consultants are being brought in.

Sometimes, these enterprise-level projects over-sold. In order to "create enough value", a presentation is put together that makes the project bigger and more complex than necessary to solve the actual underlying business problem.

Consequently, the entire vision -- as stated in the initial presentation -- is rarely achieved.

Is that tanking?

Or is that wise management of investment by cutting off funding when "enough" has been done?

• If you are an Agile proponent, it's wisdom to stop spending.

• If you are waterfall proponent, the project tanked and was cancelled early.

Which do you mean by "tanked"?

Answer 9

I've worked on one that tanked and one that was tanking when I left (I'm afraid to call and ask if it's tanked yet).

The first was a major re-write of a website that was shredded by shifting requirements of the marketing dept. Not only did that one tank but it took our bonuses with it :( One whole year down the drain.

The one I left is tanking due to bad project management. I wrote a custom ORM framework based on the activerecord pattern. My "customer", a shitty developer that I hope falls into a volcano, complained to my manager that it was "too hard to use". He couldn't figure out how to bind business objects to a datagrid, even after I showed him over and over again. So, management believed him and threw out three months' worth of what I think was the best work of my career so far. Lesson learned: even if your customer is a moron, he's always right. Just bite your tongue and write the ToDataSet() method he keeps asking for instead of explaining that it's the same as an array of business objects.

Answer 10

Had one project with over 1000 hours put in personally. Client decided not to pay. Well now I own a lot of very useful enterprise CRM code, but I would have liked that paycheck. It was a lesson; I now require escrow on every project.

Answer 11

I guess there are three scenario's for project failures:

1. the project never gets completed

2. a project that is failing is not stopped

3. the project never takes off after completion

What I noticed with projects that don't get completed is because of content issues, design problems or too much complexity. With projects that don't get stopped because there is already a huge investment gone in.

Most unsuccesfull projects get completed but never take off and starv a silent death.

Answer 12

To my mind there are a few different scenarios that I've seen:

1) Company goes under. If the company stops paying you, does the project really get done if noone is working on it?

2) Abandoned line of development. Suppose there is a project to integrate some new Widget into an application suite but after some initial work, the application company decides not to go forward. There was some work done but the project didn't finish in a satisfactory manner.

3) Scope change/resource change/technology change. In this case the project doesn't finish successfully because something, either the timeline, financial cost, or initial scope, changed and thus the project doesn't finish as expected. This is where a lot of IT projects end up and in some ways this isn't that surprising if one understands how adaptive human beings are and how the requirements are often not properly known in the beginning.

Answer 13

It's a little difficult to say, because there are some projects which I would consider having tanked, but are salvaged by replanning. I worked on a project where I researched and practiced implementing an agentX subagent only to later reach a decision (with support from above) that a different monitoring scheme would be better. On paper, I'm on the same project, but in reality, I'm on a different project and the last one tanked.

I've also worked on a project, which was completed, met requirements, but got held up in deployment for so long that by the time it was obsolete before anyone got to use it. On the other hand, I was the one who obsoleted it, with a webapp that was much easier to deploy. (By easier, I mean fewer IT-imposed barriers.)

Answer 14

I remember once where we simply transferred the contents of a branch over to the head, discarding everything we'd done on the head. Since at that point we were a single-product company, does that count as tanking a project?

Answer 15

Thus far in my career, every project I have worked on has been a "long term" or ongoing project. If you are counting the project as a whole, none that I have been part of have gone through to a stage that could be considered completion. If you are talking about the individual segments of those overall projects then many, if not most, have reached completion, though virtually none were what you might consider matching the original specs. It seems that on every project, things change along the way. Sometimes the are necessary changes due to unanticipated issues and sometimes they are scope creep. In fact, thinking back, I don't think I've ever had a single phase where where the finished product matched exactly to the original spec.