10 ways to deal with a project gone wrong

Sometimes projects go downhill. And sometimes they crash. Savvy managers recognize the signs, step up and take necessary action, learn from the experience -- and help the team learn from it too.


Even an IT department with a stellar project record can launch a project that just doesn't work. When you see this happening, what do you do? Here are 10 strategies.

1: Communicate!

For any project, it is important to set the stage for open and cooperative communications up front -- and then to practice open communications. When you see a project that is going to fail, having open communications channels is an absolute necessity. You're going to find yourself in your stakeholders' offices, explaining why the project didn't work. Delivering the news about a failing project is never easy, but it's easier if you already have good communications established.

2: Don't make excuses

I have seen failing projects where everyone runs for cover and no one is left to explain how or why a project failed. If you are responsible for the project and it is your call to end it, assume the responsibility and don't make excuses -- such as, "The purchasing department was never available to verify and sign off on the application specs."

3: Look for early warning signs

On the surface, many projects can appear to be running smoothly, but a little drilldown reveals otherwise. Astute project managers sense when projects start to fail. They look for signs of stress from staff or early delays on project tasks that shouldn't be occurring. When they see these signs, they immediately step in. Often, you can turn a project around -- but sometimes you can't. The earlier you recognize a project is not likely to succeed and the sooner you take action, the more successful you will be in mitigating a project failure.

4: Have the courage to pull the plug early

Most project managers are optimists and creative problem solvers who can find ways to make almost any project work. But there's a flip side: It's easy for these same project managers to go into denial when faced with a failing project. Their can-do DNA doesn't readily equip them to see when a project isn't going to make it. Failure calls should never be made lightly, but once you know a project is going to fail, have the courage to pull the plug quickly so further waste can be avoided.

5: Do a post mortem

Just why did this particular project fail? There is a human tendency to want to walk away from failed projects and to forget about them. Resist that instinct -- and insist that your staff do the same. Perform a project post mortem as close to the cancellation of the project as you can so that everyone can discuss it when it's still fresh in their minds. It is equally important to create a supportive, relaxing and nonthreatening environment in the meeting room when you get together with your team to do this.

6: Salvage

Every bad project has something good come out of it. It might be a piece of business rule object code that was part of the project and that can now be repurposed for future work or the display of extraordinary aptitude by a staff member in a new role that can be utilized in the future. As part of your post mortem, it is a useful exercise to identify these "good parts" with your team so they can see the value that the project delivered, even though it failed in its principle mission.

7: Review the players

Project managers should evaluate their own (and others') performance on the project. Although the focus has been on objective parts of the project, most project managers also know that politics can play a role. If the user was uncooperative, or if there was infighting or non-cooperation among the IT staff, or if an outside vendor didn't do its job -- all can affect a project to the point of failure. For these reasons, all project managers should review the players and the politics (on their own and not with the team).

8: Set your exit points

Dealing with a failing project is a little like combat flying. You should always know where the exit doors are on the project and have your parachute with you. These exits should be pre-identified checkpoints you set up with your team and your stakeholders before a project is launched. They usually come in the form of evaluation points defined at times during the project's lifecycle that give the project team and stakeholders the opportunity to stop a project if they feel it is warranted. Setting these checkpoints in the project also ensures open communications and participation in project evaluation and reduces the potential for unpleasant surprises.

9: Have alternatives standing by

No one likes to discard a project feeling that there are no other alternatives. It's good to have Plan B alternatives waiting in the wings so you can continue the momentum of the project in another form. For example, if your idea was to build a private cloud and the project somehow fell short, perhaps there is an IaaS (information-as-a-service) provider that can set up your cloud environment instead.

10: Phase your project and your budget

Developing a project and its accompanying budget in phases goes along with establishing regular project checkpoints. If you break a project into smaller, more manageable phases and budget allocations, it is much easier to pull the plug than if you've invested millions of dollars and more than a year of staff time.

Also read...

Other suggestions?

What additional strategies do you recommend for coping with an imminent project failure? Share your advice with fellow TechRepublic members.

Automatically sign up for TechRepublic's Five Apps newsletter!


Mary E. Shacklett is president of Transworld Data, a technology research and market development firm. Prior to founding the company, Mary was Senior Vice President of Marketing and Technology at TCCU, Inc., a financial services firm; Vice President o...


If project gone wrong problem is frequently hidden project scheduling. Not always!.. Here are some project scheduling tips:

- get clear view of tasks, some might be overlooked and then arise later when you don’t have time to fit them in.

- get enough resources, you might by burning your team out or using them ineffectively.

- add structure to your project schedule, tasks might be all over the place, and no one knows what’s coming up.

- get a realistic view of outstanding work, you might have an overly optimistic project plan.

See more details in Elizabeth Harrin's insightful article -
Evoke IT
Evoke IT

I think it is really difficult in a business situation for people to accept failure, and must be exceptionally difficult for the first person to stand up and say 'this is not working'. No one wants to be that person and sometimes this is an major issue. With the aspect of communication that you have mentioned above it's not just about talking about a project it is also about being able to discuss negative feedback without concern about reprisals.


I wonder, how many failing technical projects are managed by MBAs rather than technical folks. How many projects fail because the project scope crept, and crept, until it was an unmanageable mess? How many projects fail because the project was faulty from the get-go? How many fail(ed) due to the original plan providing insufficient  resources such as time, money or personnel?


Is Iaas Infrastructure as a service or Information as a service? I thought it is the former when used in the context of cloud.

Editor's Picks