Fog Creek Software
Discussion Board

How to manage a doomed project

Calling all software development veterans and seasoned project managers:
Suppose you are hired to manage a project that is in deep trouble. It is already behind schedule, has serious quality and performance issues and high staff turnover. It shows all the signs of classic mistakes (no requirements management, inadequate architecture, insufficient testing, etc.). The previous manager has just been sacked by upper management.
Now, the first thing you'd probably want to do is draw a baseline, and start over, beginning with consolidating requirements and architecture reviews. Problem is, there isn't enough time left. With already missed deadlines, neither the customer nor your bosses will allow you to invest that much time , they tell you "just finish the job".

So, what do you do?

Just a few considerations:
- throwing away the existing architecture could cause resistance among the senior developers who designed the system in the first place
- to stick with the current system approach and processes is likely to result in even more delays and ultimate failure
- if the customer doesn't agree to a new schedule, the project could be canceled and you lose your job

Tuesday, May 6, 2003

What upper management wants to hear is: "Yes, boss, we shall finish the job, it will be ready on time".

If you give in to this, and the situation is as you described, you will anyway lose your job because the project is impossible to complete.

Make a detalied report about the current state of the project, about the mistakes made, and propose a workable solution.

Also, gather the rest of the developers, and convince them to back up your report (so if the upper management asks about it, they will say that the report is fully corrent, that you are 110% right, etc).

If, after presenting the report, they seem to want to fire you, say something like: "You may find someone who will say <<Yes, boss, we shall finish the job>>, but a disaster will still happen because of the facts I described in the report."

Unfortunately the situation you have is very tough.

Please forgive my poor English. It is not my native language. :-(

Michael K.
Tuesday, May 6, 2003

Manny, did you get my job?


Tuesday, May 6, 2003

Its almost impossible without knowing a lot more detail which probably isn't a good thing to disclose on here. But to generalise.

Doomed projects have something in common.  Everyone knows they are doomed.

Often they gain their own life over and above whatever it is they are supposed to be about.  Project X becomes the purpose of Project X rather than what it was originally intended to do.

It tends to be true that those more willing to maintain this are those that belong to higher management because they feel they have to have something for all the money they've thrown away.

The people actually working within it (other than a few who haven't noticed), have probably been walking around with a sense of doom for a while.

This means that there will be a sense of relief if someone stands up and shows some leadership.  That leadership has to be firm and motivating.  It has to tell the truth, it has to own up.  That may mean redundancies, it need not mean complete collapse.  Not doing anything at all will ensure complete collapse.

One of those truths may well be that whatever drop dead shipping/go live date exists is now itself dead because the asteroid just landed.  So the question is not, 'there is a milestone we have to hit and its all a mess and and and'.

The question is 'what are you trying to achieve?'.
Then you start again.

You might use work already done, you might not.  You might use designs already done, you might not.  You might have to bring in people, you might not. 

You'll certainly have to rebuild their morale and self worth.

So the short answer is you kill the doomed project and do something sane.  If you can't kill it, you might as well shut down the operation that's running it because its poisoned.

My mentoring rates are reasonable :-)

Simon Lucy
Tuesday, May 6, 2003

Brings to mind the sad old software saying:

There's never time to do it right, but there's always time to do it over.

Bruce Perry
Tuesday, May 6, 2003

Things not worth doing are not worth doing well.

Tuesday, May 6, 2003


You almost exactly described a job I took about two years ago.

I came in with high hopes and a truckload of optimism, but there is only so much you can do when a project is horribly flawed, late and you are experiencing incredible staff turnover.

I spent 6 months fighting management before I finally threw in the towel. Given that experience, here is some advice you might consider:

1. Put together a list of recommendations of changes that need to be made *immediately*. When you find yourself in a hole, the first thing to do is stop digging. I'm talking about things that you simply must have or must be changed. Every situation is different.

2. Present that list to management. If they balk or give you the "Yeah, yeah we'll do that later. But for now, just deliver." speech then bail because you will never succeed. If management doesn't have enough wisdom to recognize that something different must be done to save a project, then don't waste your time.

I guess in a nutshell, make certain that management supports you and provides proof of that, not just lip service. In my project, because the project was failing, nobody wanted to get near it and management wouldn't allocate any additional funding or resources, although we were over 100% behind schedule. I was expected to take a demoralized team with a piece of crap product and turn it around with less resources than what the original project manager started with. All we could do was just put out fires as quick as they started, all the while the project continued to slip further and further.

Oh, and yeah...Good luck!

Mark Hoffman
Tuesday, May 6, 2003

"Suppose you are hired to manage a project that is in deep trouble. "

Strangely, this is where I make most of my living.  I rescue failing projects.  Presumptuous?  Perhaps, but my success rate is fairly high.    You have asked the equivalent of "Help, I am on a 747 and the pilots are in a coma.  How do I land?"

Here is the 30,000 foot view...

First, assess the situation. Get everyone together and tell them to continue with what they are doing.  Then for the first two or three days, do absolutely nothing but ask questions.  Interview everyone from the developers to the secretary to the project sponsor.  Everyone has a perspective, but remember it is a perspective.  The truth is a strange thing, everyone believes what they are telling you.  It is true, it does not make it accurate.

-Ignore the original project plan.  Would you follow directions that got someone else lost?    You will get back to the plan later. Today other issues are more important.

-Determine, is the date or the budget  most important and to whom? (Both is not an acceptable answer, everyone will choose one when given no other choice).  Again, ask everyone.  As communication is usually the first project failure, this will tell you what everyone is marching toward.  Which is often different than what management thinks they think.

- Determine who knows what is going on.  Forget about architects, senior developers and consultants.  Look for who is producing results and who people are going to for information, expertise and advise.  You can ask this as part of phase one, but keep an eye open too.

Second - Bring in the people that others look to.  This is going to offend the people who thought they were in charge or should be leading the project. 

Tell this new group what is important Date/Budget and ask what can be done.  What has to happen.  Who has to do it and when it could be pulled off.  Prioritize into phases.  What can be delivered in what order and when.  Create a project plan, even if it is a spreadsheet with dates and major items, estimates and percent done.  Don't get bogged down in detail. 

Get everyone to agree about what is required.  You now have the plan. 

If the project had a project plan, go off and compare the two.  Is the original plan fiction?  If so, you may as well face it now.  Or is it that certain aspects were terribly employed?  Example:  Order Hardware: 1 day.  forgetting that it takes six weeks to arrive.

So now you have a plan, and a reasonable comparison to what they originally thought.  Time to go in and break the good or bad news to the leadership team.  No sugar, no spice.  If the people there don't think they can do something in three months, who are you to say otherwise?

After meeting with leadership, meet with the development team.  This is everyone from the technical leaders to the testers.  Explain the new marching orders.  Explain the new schedule. Hand out the new plan and go over every single item.  Don't get bogged into details.  Just say "We will take this up outside the meeting."  Confidence is 80% of this battle.  These people were beat up.  They want someone who appears reasoned and capable.

Explain to every developer the golden rule:  No one has the authority to agree to anything that changes scope except you. If they choose to, they will be coding it on their time, off hours.  Then explain your role:  You are the street sweeper.  If anything is slowing down their progress they need to let you know as soon as they see it.  You then make it disappear.

Project management is like a sewer worker.  People only notice when you do a bad job.  That does not make it a bad job, but it does require a special type of personality to do it well.  I am still working on it.

Good luck.
Suggested Reading:"Rapid Development Taming Wild Software Schedules" By Steve McConnell.

Mike Gamerland
Tuesday, May 6, 2003

Mike, you just described the last 4 years of my life. 

My former employer would always bring me in as a technical lead for projects that appeared doomed.  And I managed to turn them around most of the time.

Pay attention to what Mike just posted, you all...I've been there and I can tell you, what Mike's written is good, solid thinking.  I've done the same thing many a time.  It works.

P.S.  There's a copy of Rapid Development on my desk as I write this.  ;)

Tuesday, May 6, 2003

I've got to agree with Mike too - you need to present as clear an accurate picture to senior management of the state of the project, and offer a highly reliable and concrete plan out of there.

The problem you mentioned is that management may pull the plug on the project based on your assessment.  This is part of your job - give enough information for so that management can make a reasoned decision.  Because of this, the plan you present needs to be very reliable in terms of risks and completion times.

Colin Evans
Tuesday, May 6, 2003

"Time to go in and break the good or bad news to the leadership team.  No sugar, no spice.  If the people there don't think they can do something in three months, who are you to say otherwise?"

Sorry, a little confused on this point. Is the leadership team your group of hand picked "Alpha Nerds" (AN), or is it the management team you report to? Is the point of this meeting to run by the new plan with your ANs to get their feedback and adjust accordingly?

Tuesday, May 6, 2003

If you haven't already, read Dynamics of Software Developemnt by Jim McCarthy. It might motivate you and give you lots of ideas. And it's thin too.

Big B
Tuesday, May 6, 2003

People always seem to believe that somehow a miracle is going to bring a runaway project under control and get it done on time and within budget.  It sounds like you are being viewed as the "miracle" for this project.  Here are a few options I see:

1. Tell them "I will get the project done on time."  If you can actually do this, you are very, very good and I want to come work for you.  If you can't, I suppose suicide is always an option.  (Just kidding.)

2. Tell them "This project is fubared.  We don't understand the requirements, our architecture is weak, and we have a host of other issues.  However, if you give me _____, I can give you _____."  Management won't like hearing this.  They want to hear how you're going to deliver on schedule.  Here's where you tell them why that's impossible -- the facts of the current situation.  Don't place blame on people or processes or other causes.  Just lay out the current facts.  Depending on what kind of people you're talking to, at this point you'll either be asked to take a hike or they will start talking about what you need.  Be prepared to negotiate, but don't promise what you can't deliver.

3. Walk.

Upper management have a personal stake in the project.  They want it to look good so they look good.  If it looks bad (goes over budget or over schedule) they look bad.  No one wants to be near a "failed" project.  If you can find a way to present them with a "win", they will help you because it helps them.

Good luck and let us know what you decide and how it goes.


Tuesday, May 6, 2003

The project is only behind schedule or over budget because the customer (be that management or an outside customer) has decided on a particular schedule and/or budget.

So, the customer is the crucial individual or group here.

If the project is behind schedule or over budget, we can reasonably assume that the customer has lost confidence in the project.  The customer must be made confident in the project.

So, you have to be absolutely honest with the customer about what will be delivered.  Tell them exactly what you know of the status of the system.  Report back often.  Keep them informed.

The engineers aren't going to slow down development, so assuming you don't make any colossal mistakes with the developers (and attempt to rectify any colossal mistakes made in the past), they should be fine.

It's the customer that needs to be made happy.  They'll only be happy if they know what's going on and what they'll receive, and if they actually receive it.

Brent P. Newhall
Tuesday, May 6, 2003

Jibber - I was referring to breaking the news to Management.  The alpha-team (it may include Subject matter experts, qa testers, etc.) have discussed and agreed they can live with the plan. 

Also, it is often good news.  Especially, when compared to the guy just tossed out the door.  They had no hope until you arrived.  Now they see light at the end of the tunnel and it is not another train.

Mike Gamerland
Tuesday, May 6, 2003

"Debugging the Development Process" by Steve Maguire is also, IMO, a good book for someone in this position.

In chapter 8 "That Sinking Feeling", Maguire points out that if a ship is sinking, hiring more people to man pumps is actually a pretty bad idea.  What you need to do is find and fix the leaks so that the people spending 80 hour weeks pumping can go back to steering the ship in the right direction.

You have a great opportunity here to be famous as the guy who saved the sinking ship.  The risk of course is that you might go down with it.  Good luck!


Eric Lippert
Tuesday, May 6, 2003

Explain that as a magician and/or scapegoat, you want $/hr*3 and will work on an hourly basis only.

Some people make a killing as professional scapegoats.

Tuesday, May 6, 2003

DOn't forget there is one more dimension to time vs. budget and that is features

Daniel Shchyokin
Tuesday, May 6, 2003

Thank you for sharing your thoughts.
It seems like this situation is not so uncommon.
I agree that it is absolutely necessary to communicate openly to upper management, provide accurate information and show alternatives, and to regain trust among team members and the customer.
I've read and enjoyed McConnells book as well as most others on Joel's list, and it makes perfect sense. However, people resist change, making it hard to improve the status quo.
Another book I found helpful is Ed Yourdons "Death March".

Eric , good analogy, but the question is not so much whether you can fix the leak, but whether you can convince the captain/admiral that there is a leak that needs to be fixed first and you can't survive by pumping some more.

Tuesday, May 6, 2003

This thread reminds me of my last job (developer). I walked.

I'm out of work at this point in time, but I don't regret leaving the last place for one second.

If you don't want your developers to walk, make sure you start putting proper (realistic) project management into place. Developers do their job (or at least should be), expecting them to accomplish the impossible because some previous project manager didn't do their job properly is completely unreasonable.

Not Telling
Tuesday, May 6, 2003

"Some people make a killing as professional scapegoats."

Interesting. I always felt every project should have one person whose job it was solelely to take the blame for everything that goes wrong.
Tuesday, May 6, 2003

I have fixed several projects in situations like this. In one, the engineers had the answers but nobody would listen to them. I changed that and we actually made a deadline after being three months behind schedule.

In another, a web company that had grown to a big size without any planning mechanisms finally reached the stage where it was doing complex development, and its methodologies just couldn't cope.

Lots of work, and establishing the importance of requirements planning to the young business managers, got that one achieving deadline too. Most importantly, I taught the developers they were allowed to say no, and that failure to achieve deadlines was a scheduling failure, not their problem.

The msot important thing, when starting such projects, is demanding complete commitment all the way to the top. Most of these disasters occur because inexperienced managers are in charge. They have been accustomed to their underlings being obedient. The first thing I do is walk into the MD's office and make it clear that he is not the person that knows best on these things.

Tuesday, May 6, 2003

Some impressive advice here, not much to add really.

The one tip I think is most important throughout all of this is to face the reality of the situation, identify realistic alternatives for going forward and ensure that everyone in the team and senior management also understand the reality.

Once everyone has faced up to what is going on, then decision making becomes much easier and clearer.

Wednesday, May 7, 2003

Make sure you have somebody to dump the blame on when the inevitable happens.

Work on your sense of humour, hone it to a fine point, you'll need it.

Wednesday, May 7, 2003

I bet this sounds very familiar to most of us. It is only natural. According to this (see session 4), no less then 94% of all non-trivial software projects require a complete restart.

Just me (Sir to you)
Wednesday, May 7, 2003

All sounds familiar, I guess we've all been involved in, or heard about, projects like these over the years.

One short, but useful, phrase I have heard used when discussing these issues with management is this:

"You can have Good, Quick or Cheap, choose Two".

Obviously, everyone wants all three options, but in the real-world this is often not possible.

Any two are generally achieveable, as long as things haven't already been messed up too much.

Steve Jones (UK)
Wednesday, May 7, 2003


Do as Mike suggests - he is right: find and focus on the real problems and expect results at the end of the day. Get the real problem solvers 100% invloved.

A tactical advice, every morning, before you start,  get the key people around the table for 15 minutes and plan the day together.


Wednesday, May 7, 2003

Most of the advice here is good... with one exception.

Don't consider yourself directly responsible for the self-worth (notice it does have the word self in it) or morale of the project team.  Anything you directly do in an attempt to improve these will keep you in the failure muck because you won't be focusing on the important causes of failure.

I'm not suggesting to ignore these, just keep in mind that they are the result... the effect of project management and doing a good job - not the cause of success, but the result of it.

Joe AA
Wednesday, May 7, 2003

Ummm unless you do take responsibility for morale as well as everything else then no one will trust you.

I've also had more than the occasional experience doing this.

Simon Lucy
Wednesday, May 7, 2003

>I'm not suggesting to ignore these,
>just keep in mind that they are the result

I think that what Joe is trying to say is that managers who try to "improve morale" will ALLWAYS fail if bad management is the cause of the low morale.

Fix the problem, not the symtom.  Of course MGT is responsible for morale - but they fix it by FIXING THE PROBLEM, not working on the symtom.  (I've worked at some places with problems.  Would taking me out to lunch have helped?  Well, yes ... for a day.  Taking me out to lunch and really listening to what was hurting the organization, then acting on that information to improve things - THAT would have helped the morale problem ...)


Matt H.
Wednesday, May 7, 2003

A software manager is brought into a doomed project. She's replacing the previous manager, who was fired. When she gets to her new ofice, her predecessor is clearing out her desk.

"I'll only be a minute. By the way, I left you something."

After the predecessor leaves, the new manager has a look around, and discovers two envelopes. The first one says "open when in trouble." The second says "open when in even more trouble."

Well, she follow the advice on this thread, has a look around, talks to everyone, identifies the key players, and goes to management with a clear explanation of what the problems are, what's realistic to achieve, and what needs to be done.

To her surprise, management seems to go along with things and tells her to make whatever changes she needs. She institutes daily builds, stand up meetings, rapid iterations, and starts tracking velocity.

Two months later, at the quarterly review, she presents her progress. The team is producing at 200% of the previous rate, morale is up, and they're going to get 80% of the previous functionality done with less than 90 days of slip off the impossible schedule.

There is silence, then management tells her that this is unacceptable. Sure, they agreed she could institute change. That's her job. However they did not approve any compromise in scope or delivery date. This is a competitive business, and there are thousands of qualified managers looking for a job who can come in and get things done. Does  she want to admit she can't do her job?

She goes back to her office in a quandry, then remembers the envelope. Wordlesly, she opens it, and inside is three by five card inscibed: "blame me."

She goes back to management a day later with a powerpoint emphasizing how the project was way off track, how the architecture was fubar, how morale was poor, and how requirements were incorrectly documented. she doesn't blame the previous manager directly, but the implication is clear. After some huffing and pufing, management buys off on delivering 80% with a 45 day slip.

Well, things go along quite well until two weeks before the original due date. Management calls her in and asks her to sit on the release planning board, with release scheduled in two weeks. She reminds them of the 45 day slip they negotiated.

"No," they tell her baldly, "we agreed on delivering 80% on the original date and the remaining 20% 45 days later in release 1.1. Is there a probem?"

Well, it's back to her office and she opens the second envelope. This time, the advice reads "Prepare two envelopes."


Moral of the story:

Do they very best you can. Do so because YOU want to do so, regardless of whether you will suceed or not. Regardless of how dysfunctional your organization is, give them at least two chances to change. Do what you can to help them change. But if they do not change, move on.

This story is often told about baseball manager Billy Martin. He managed the Yankees five different times, because he was prepared to be fired when things didn't work out.

Reginald Braithwaite-Lee
Wednesday, May 7, 2003


>get the key people around the table for 15 minutes and
>plan the day together.

This works fine in theory, but in my experience, when you are working on a doomed project that is overdue even those seemingly short 15 minute meetings will probably come across as an annoyance. It takes 15 minutes for everyone to get their coffee cups, so in reality you will waste an hour/day.

In my experience, when you need things done quickly, minimize the meetings. I've seen people that are very very meeting happy, and they do constant status-report meetings. Daily is too often.

There is often not that many key players on a project; I've seen from 1 to 4. Most of the time they can take care of the quick descision making without the formal daily meetings.

The key descision here I think is if its OK to deliver a shaky system, and babysit it a month and fix things when stuff happens after delivery, or if its worth it to take another delay of the delivery.

Wednesday, May 7, 2003

Those daily 15 min meetings can work.

Hold them as stand up meetings (no fetching coffee) etc. If you are all working in an open plan office in the same area then just have the meeting in that area.

Have a fixed agenda, dont deviate from it. Dont let anyone waste any time pr wander off track.

15 minute meetings are possible.

Not Telling
Wednesday, May 7, 2003

Not Telling,

OK. 15 mins meetings can work. Maybe I've just seen it poorly executed. There is another drawback with daily meetings, and that is the fact that everybody needs to be in at a given presumably early time in the morgning. Most project managers I've seen doing this simply says: "OK, people 9am it is. We need daily 15 mins meetings."

If half of the key developer crew decided to put in a graveyard shift working late to finish something, they will not be making the 9am meeting, so then it will be held after lunch instead, when everyone is present.

Wednesday, May 7, 2003

I'd agree, 15 minute meetings.

To check status, have standing appointments: Spend all of monday morning meeting with your people one-on-one.

So joe doesn't have to listen for an hour to everyone else's status.

This might be good on TIGHTLY COUPLED projects, but it's been my experience that those are rare.

IF everyone else needs to hear it, bring it up in the daily standup ...

Matt H.
Wednesday, May 7, 2003

It's better to have 70% of the project 100% complete than it is to have 100% of the project 70% complete.

Christopher Wells
Wednesday, May 7, 2003

Patrik - I hear you about the time thing. In fact this is precisely what happened at the place we had the daily meetings. The new VP of tech (just joined) decided to get hardassed about the time. 9am sharp daily meetings. This when some of the key developers often came in later and left later. Needless to say this didnt go down well.

In the end, the time of the meetings "mysteriously" shifted to 10am. A large part of this was due to the fact that a team leader emerged from within the development team to run these meetings.

The daily meetings are important. Being sensible about when they are held is as important as not wasting time during the meeting. It can work, and it can work well. You've just got to make sure you do The Right Things to make it work.

Not Telling
Wednesday, May 7, 2003

Managing morale is not about socialising or taking someone out to lunch.

Its about delivering on your promises to the workforce.

Its about telling the truth to both sides, and getting both sides to admit the truth, whatever that truth is.

Management isn't hard, nor is it antagonistic to those that 'do the work'.  By the way, management works too.

If a project is felt to be doomed, it hasn't just happened once, usually a number of cycles of plugging leaks has already happened and failed and the whole thing is only afloat because if everyone admitted it was sunk the game would be up.

A project that is doomed (and its irrelevant whether its about software or anything else), is largely doomed because of the failure in communication in the organisation.  A manager coming in to turn around such a project is unlikely to have any kind of technical wand to fix it.

They may be able to see the schism, the fault line where the project is going wrong and fixing it may include shifting technology.  But if no one believes in the process it won't happen.

That's why morale matters.

Simon Lucy
Wednesday, May 7, 2003

Read 'The lunatics are running the asylum" by what's his name.

Wednesday, May 7, 2003

Leading the horse on even if time is pressing may lead to the doom being even more - and if there are clear changes that can be done - might be a week or so of real hard work but if you can get everyone in agreement (this is the fist stepping stone - whether everyone agrees) it might be owrthwhile to do those changes - so that all concerned would have a brighter future to look forwards to.
Incidently changing off 100% would be a bit too ambitious !!

Saturday, May 10, 2003

*  Recent Topics

*  Fog Creek Home