Have you been committed to a project that should FAIL?

Question

Some projects shouldn't exist in the first place. They have no useful purpose, or have no possibility of succeeding. Or if they did succeed, the consequences would be negative for the stakeholders. Have you worked on such a project, and what did you do? What should you have done?

Answer 1

I have seen those projects before. Generally, I get out as fast as possible. I have found that it's bound to go badly, and the devs are the ones who generally take the blame in the end. I try my hardest not to be associated with them.

Answer 2

I have worked on a few projects that had no possibility of being successful as originally defined. The usual recipe for disaster was unrealistic time lines and new technology in a corporate IT environment.

In my experience trying to reset expectations in the early stage of the project never worked. People don't listen until you miss a few milestones. Then you can start discussing cutting scope or extending the time line.

Up until that point you should be tracking actuals against estimates to give you some metrics to help you build a more realistic plan. And make sure you don't have too much of a gap between the milestones/phases in the original project plan. SCRUM has served me well on the more recent projects.

These projects can be pretty stressful. On the last project of this type I was so exhausted at times that I once accidentally parked my car in the middle of field of cows. But the new technology aspect of the project suckered me in.

Answer 3

A few clients have come to me with product ideas that seemed preposterous. At first blush I thought they were likely to fail due to impracticality and generally being flawed ideas.

However: they weren't terribly expensive projects (~10k? small change in the business world), and the fact is that the biggest success stories out there are from visionaries who saw something that everyone else missed.

So, I opened my mind, offered what guidance I could (with the knowledge that I don't know everything), and did everything in my power to build something great.

Now, from time to time I am also asked to do things that are unethical, and that is a different story.

The first time I was in this situation, I asked my old man for advice. He explained to me that there are a lot of scumbags out there, and if I don't want to be one of them I can just turn them down and deal with the consequences, which are never as severe as diminishing myself by compromising my values.

I decided that I don't want to be just another scumbag. Since then it has been really easy.

Answer 4

I agree with bmatthews68. I've worked with several projects that destined to fail, right from the start, and the recipe is always the same, unrealistic timeline, over excitement on new technology without clear understanding, corporate IT environment, and in my case, typical pointy haired manager that doesn't even know what he wants.

I don't know what's the best way to handle your situation, but here's what I've done.

1. No, I did not quit. Too afraid. Too many loved ones depending on me. It's also possible that I'm a coward. And I was young at that time, and I've got too many bills to pay, and the money was good.

2. I warned my direct supervisor immediately about the unrealistic timeline. It helps when the one supervising you also knows detailed technical aspects.

3. I sets up an intermediate targets, that doesn't comply with all the specs, but realistic and usable enough to be implemented, given the timeline and resources.

4. We release it as a V1.0 system, with the promise of V2 will come next. My manager was happy. He got something to show off to his boss, and as far as he's concerned, progress has been made. Of course the V2 never actually happens. We somehow able to weasel out of that project, using another project with higher priorities as a scapegoat.

The situation maybe different from yours, but hopefully you will learn something from my experience.

Answer 5

Oh yes.

As a project manager, I was asked to build a system that more-or-less duplicated another system that we new was soon to be launched, the major difference being the other system had hundreds of thousands (millions?) of development dollars and massive institutional support. I had one mangers say-so, some related code I could re-use, and maybe $20-40K for contractors.

I did not think this project was a good use of our resources (specifically, my time, our admin's time, and our dev's time). However, I have been wrong before...

I set the project up in three stages (we were using PRINCE2, or something similar) where the first stage was setup & API, the second stage was prototype development & evaluation, and third stage was productionisation. I made sure that stage 3 required EITHER signoff from the CEO with a very clear deadline OR decommissioning the prootype (luckily, the manager thought the idea could not fail, so was happy with this).

We hit the development targets for the first two stages, and the manager (and CEO) had something to demo to colleagues and to talk about. It was time for signoff for productionisation (and commitment of some further money) or for the shutdown.

Then nothing happened for months, and the signoff deadline target got extended again and again. Every so often the prototype would be discussed, but no decision would be made.

After about nine months the CEO regretfully canned the project (on the advice of our then Director, I think).

The manager then sent an email asking for a reprieve to make the case for producitonisation. He was asked to write a memo/business case. More delay. He asked me for more ingformation, and I think he wrote something up, but I have not seen it.

We got restructured. Our new director has given me a month to write up a statement of position/business case outlining the costs and benefits of full productionisation so that she can discuss it with the CEO, the manager, my new manager, and myself.

I will of course do my best to represent the pros and cons of the project as fairly as possible, but I still think it is not a good project for us to persue.

Anyway, thought you might like the story. If I learned anything, it is that putting a very explicit commitment Vs shutdown decision point in the plan from the beginning proved to be a good strategy, as I was very worried that I would be asked to move a half-baked prototype into production without the necessary resources.

Answer 6

Back in 2000, I was in a startup that planned to develop a huge distributed media management platform. Thinking back, we actually planned to build "the cloud" many years in advance :) However we learnt the hard way that :

1. people buy applications and not platforms; so we lost a couple of years trying in vain to sell what nobody would ever buy. Google and other "cloud" vendors sold applications, and built the platform from there, then added applications afterwards. We started at the platform level, with only "example applications" but no actual ready-to-go product.

2. when you present a platform that would actually externalize a huge part of an information system, IS management is very pissed off and want to throw you out of the window quick. Top management can't enforce their choice against those in charge.

3. when you want to build a huge platform, you need big money, fast. Not a paltry 15 millions. So we bleed slowly money until death.

4. machine power, network bandwidth, storage size were all a bit too limited for our requirements at the time. We spent millions to buy hardware and software that would hardly do the job.

So the project was doomed from the very start, but I'm not sure we could know it before trying.