How do I survive a failed project?

Question

There is a great question on programmers that dealt specifically with the programmer aspects.

Many of us end up on projects that we can tell are doomed for failure long before they are cancelled. Many times failed projects will take down the careers of the people who were involved with the project even if they were not the reason for the failure.
Projects sometimes fail because of management, sometimes the projects are just bad ideas, or sometimes the decisions made make the project results less that hoped for. In the end, the project fails despite the best efforts of the people on the team.

What can a team member do to protect themselves from the failure fallout without getting a new job or abandoning the project?

Sometimes abandoning/quitting is not an option that is available. Mostly, I am not looking for answers that say abandon the project or quit your job. Of course those are the "easy" options. I am looking to survive despite the failure of the project.

Answer 1

While I don't think HLGEM's answer is incorrect, I think that "playing politics" requires a bit more guidance.

Executive Summary

Here is a three-step process to minimize the damage to your own career.

1. Push to make the project succeed
2. Suggest solutions rather than harp on problems
3. Turn the failure in to a selling point

Push to make the project succeed

Most projects are not doomed to failure at the start. They start off well and then take an unfortunate turn. Your job, above anything else, is to do your darnedest to make sure the project doesn't go south.

Success or failure, nobody likes a Negative Nancy, so pushing to make the project succeed from day one will give you a leg up as someone who was doing the right thing (even if the result ended up wrong).

Someone in management decided that this project was worth assigning resources to, and your job isn't to question their decision (that is usually above your pay grade), but rather to find a way to make that decision work. If you can't do that, you should do your best not to be assigned to it in the first place.

If you can't push to make the project work, you are a very easy target to get thrown under the bus when it doesn't.

Suggest solutions rather than harp on problems

Caveat: The below section assumes that the failure of the project is not due to ethical or legal missteps. If the project is going to fail because someone is doing something seriously unethical or clearly illegal, then I would argue you have a moral obligation to blow the whistle (anonymously or otherwise). If the stars are just aligned against the project, then I suggest the below course of action

So you're giving it your all, but you are having nagging doubts that it is possible to succeed. You can see the writing on the wall that this could go south, and you can create a list of reasons it is going to fail.

The rookie mistake is to see an issue and cry it from the mountain. Right or wrong, the issue with being outspoken is two-fold:

1. You are being openly negative which kills team morale
2. You aren't giving management the chance to save face/fix it themselves

Instead of speaking your mind and attracting attention, use tact and make people feel good about your role to improve your chances if things can't be turned around.

Trust in the Project Manager

If there are issues that need to be dealt with, bring them up to the project manager -- don't go above his/her head, or spread it around the team first.

This will make sure he/she is less likely to throw you under the bus.

Bring Up Solutions, Not Problems

If the project is going south, the project manager probably knows it better than anyone. Giving them solutions rather than stating problems they already know will give them a better impression.

Instead of saying, "You know the cog we're making will be obsolete by the time we finish with this project" you could say, "Parts X and Y of the cog we're working on would be great in our current widget for reasons A, B, and C."

This gives your project manager a way to pivot the project and save some face. It also gives them ownership of the idea which will lessen the chance of getting thrown under a bus.

If the Project Manager Doesn't See the Problem...

In the rare case that the project manager is really blind to the writing on the wall, and you do need to inform them that there is an issue threatening the success of the project, be tactful.

Don't say, "Hey project manager, this cog will never work because of reasons A, B, and C. It's obvious that the project will fail unless we do X, Y, and Z." This will serve to paint you as a Negative Nancy and could turn the project manager defensive. Instead try something like, "Hey project manager, I'm sure you already noticed, but A, B, and C may cause some problems down the line."

I'd recommend writing a casual e-mail to have a nice record showing that you informed the project manager about A, B, and C, especially if they actually do cause the project to fail. Using this e-mail is a last resort, as blame games never end well for anyone, but it does cover your arse if the project manager points his finger.

Turn the failure in to a selling point

So you worked hard, did your best, but the project failed anyway. While your company may do some form of a post-mortem (and perhaps assign blame), I'd use the opportunity to show the company that:

1. You learn from failure
2. You take failure in stride
3. You have the self-confidence/maturity to admit faults

My personal style would be to give a presentation to my group/team, or send an e-mail that included a bit of self-deprecating humor with some serious lessons learned.

As the quote attributed to Edison goes:

I have not failed. I've just found 10,000 ways that won't work.

The point is to give some serious thought to what you could have done better, and deliver it to the people around you in a way that shows that some good came of the failure, and you're a better employee for it. The "stench of failure" is the inability to learn from mistakes. As the story goes:

A promising young executive at IBM was involved in a risky venture that lost $10 million for the company. When Tom Watson Sr., the founder and CEO of IBM, called the executive to his office, the executive tendered his resignation. Watson is reported to have said, "You can't be serious. We've just spent $10 million dollars educating you!"

Don't look at this as something you need to run from, embrace it. Everyone makes mistakes, the people that rise learn from them.

Answer 2

Excellent question. I think those of us who have been in the workplace for a long time have run into at least a few of these projects. We have seen people fail after one and people rise above and go on to better things.

The first thing you need to understand is that when a project is failing, it even more important than usual for you to play the office politics game. Yes I know you didn't want to hear that! However, while on a failing project, the only thing managers are hearing about you is your name in association with something bad. It is up to you to find small successes and other good things for them to hear about you to mitigate the stink of failure. Every single person I have seen whose career got permanently derailed at a company due to a failed project was someone who refused to play the political game. This made them even more of a target for the blame because they didn't even try to counteract it. This is not the time to sit on the sidelines and think office politics are bad. Office politics are what will save your career. In this situation they are a really good thing.

Now mind you, you will probably at least have a temporary derailment. You are going to have to prove yourself on the next few projects before the smell of failure fades completely away. It simply takes several successes (or one amazing success) to overcome a failure in other people's perceptions. You should make sure to put in the extra effort on the next project, too.

You will want to look around to find the next project you want to get assigned to. Something that is likely to succeed and something where you will have a chance to do well. Then once you identify that project, you need to lobby (oh no back to those pesky office politics again) to get assigned to it. You need to talk to the manager, you need to show them what skills you have that the project could benefit from and you need to give them assurance that the failure you are currently involved in not going to happen again if they take you on.

When you do go on to the next project, you will want to sit down with your manager and talk honestly about the problems you saw on the other project and how we can make sure this one doesn't derail on the same points. Remember it is a lot easier to make changes to broken processes at the beginning of a project than in the middle. Two big failures in a row is not going to help rehabilitate your reputation. Plus honestly assessing the mistakes you made and how you are going to do things differently will help give the new manager confidence that you learned something from the failure.

Now for another hard truth. Your own actions (or lack of actions) contributed to the failure. Until you recognize how you personally could have made better choices early on and done things differently, you have a good chance of going from failed project to failed project - always blaming something or someone else. Yes there are factors outside your control but not as many of them as you think. So use every failed project as a learning experience. What could you have done differently?

Another thing to think about while the failure is happening is that the people who manage to fix the problem are going to get a lot of political credit and look really good. The best way to mitigate a failure is to find a way to turn the project around (Not always possible I admit, but definitely not possible if you don't try.) So stop whining about how bad things are and start thinking of how things can be salvaged. Recently I was involved in a project that was a disaster from day one, but several of us managed to get the people who caused the problems out of the way and turned around a multimillion dollar account that we were about to lose. The client now sings our praises and all of us involved in turning the project around got awards and cash bonuses.

But to do that we had to make some major changes in how the client relationships were handled and how we did our project planning and development. We had to start with telling the client the truth about the problems and how we planned to fix them. It wasn't pleasant and it wasn't easy, but it was personally and professionally satisfying.

Answer 3

1. Work hard; but not at the expense of your family or your health.
2. Keep a record of all critical design decisions; especially as they pertain to your work.
3. Keep networking, and keep your options open if the situation becomes too difficult or you become a victim of a mass layoff.

More on #2:

• Addressing jmac's comment // Try not to think of your project as a "failed project". Like Joe Strazzere said, "Everyone likes people who stay positive and fight hard in the face of adversity." So for as long as possible, try to be that person. A positive outlook, grit, and determination are always good for the workplace.
• Having said that, if you're anticipating a failed project, then you're anticipating a post-mortem meeting. At the post-mortem meeting, everyone will be held to account.
• If you have email or design document proof that you finished what was assigned to you, then you should be well equipped to survive the doomed project.
• But at that post-mortem meeting, try to stay positive; and only present your email and design document evidence if your judgement, effort, or workmanship is called into question.

Answer 4

What can a team member do to protect themselves from the failure fallout without getting a new job or abandoning the project?

The short answer is to avoid being seen as the scapegoat when the blamestorming starts. Slacking off sets you up so that folks can point to you and claim that you're the reason the project failed.

A lot of projects "fail" for one reason or another. One quote to keep in mind is one from one of my favorite authors, Robert Ringer:

In real estate, for example, a deal can blow up over any one of a seemingly infinite number of unforeseen obstacles... Consequently, I ultimately concluded that the only way to guard against having my self-confidence and belief shattered was to acknowledge the reality that, like it or not, most deals do not close. I reasoned that the only way I could sustain a true positive mental attitude was to come to grips with this reality and make certain that I was always mentally prepared to move on to the next deal.

Source, To Be Or Not To Be Intimidated.

The author calls this his "Theory of Sustenance of a Positive Attitude Through the Assumption of a Negative Result". His point is that you should always be professional. You aren't going to win them all. You aren't going to lose them all. In Star Trek, this was the point of the Kobayashi Maru test - be professional even when you're doomed.

This book is one of the list of books I recommend.

Many times failed projects will take down the careers of the people who were involved with the project even if they were not the reason for the failure.

This happens in politically charged environments. If you are in such an environment, studying office politics is your number 1 survival skill. I've been in such places and they are very much "not nice". You will end up going into meetings where you know for absolute certain that someone is getting fired at the end of that meeting. For those, you need to have done your homework and be prepared. Maybe it is you. Maybe it is the teflon coated wonder. Be professional, the Kobayashi Maru just sent out a distress signal, please report to the large conference room.

Answer 5

Failed projects often incubate novel approaches or push into regions few involved in the project understand in advance. Therefore one is often building up skills on technologies they would not have otherwise touched. This makes one more marketable, perhaps significantly so, as others are deciding how to use those that have exited the 'failed' project. Often such 'failures' contain elements that worked nicely, all one has to do is focus on those, and simply be prepared to explain the 'lessons learned' from the wider failure.

I can describe, in vague terms, a project I worked on that was doomed. Suffice to say that it was a migration from mainframe to client/server, it was for a federal government agency, and public service unions made up the core user community. The entire thing was a bad idea, but it had some interesting quirks.

One of them was that we successfully created a 3270 presentation layer in JavaScript and AJAX. In short, we recreated the old mainframe 'green screen' using Internet Explorer as the front end. Another is that we created the ER diagram for the new system using SQL Server and Visio, a project the customer had attempted to do by hand over a span of two years and had never completed. We could point out some interesting accomplishments, even though the project shouldn't have been done in the first place.