Project Management Institute

The road to recovery




No one wants to talk about it. But every project manager has been there—that moment when you realize a project is in trouble, serious trouble. Now comes the true test, whether you can find a way to get back in the game. Fear not. Here is a step-by-step guide.

Step 1: Admit there's a problem.

Sounds pretty basic, right? But if there's one thing failing projects have in common, it's some level of denial. It might be the project manager. Or perhaps executives or clients turn a blind eye to what's happening, says Michael Krigsman, CEO of Asuret Inc., an IT consulting firm based in Brookline, Massachusetts, USA.

Unfortunately, that very reluctance to address what's going on usually serves to only exacerbate the problem.

“By the time any serious project problems come to light, it's often a catastrophic, difficult and urgent situation,” he says. “When a project continues to spiral out of control, with team members forced to work long hours in an extreme pressure-cooker type of environment, you start to see attrition. Everybody wants to run for cover, fearing that if they continue, they'll bear the stigma of the failed project. Once you're in that type of scenario, it's difficult to get out of it.”

But you can—if you're willing to face reality.

Step 2: Find the root cause of the problem. (This could take some digging.)

So you've broken through the layers of denial. Now it's time to make a brutally honest appraisal of the situation. “Both management and project participants need to actually acknowledge the issue, take stock of possible causes and address them in a reasonable and realistic way,” Mr. Krigsman says.

By the time any serious project problems come to light, it's often a catastrophic, difficult and urgent situation.

—Michael Krigsman, Asuret Inc., Brookline, Massachusetts, USA



When Peter Birley, PMP, came on to the scene at Eversheds, things were not looking so good for the law firm's mission to upgrade 4,000 desktops to Microsoft Windows XP.

“The project had been established,” says Mr. Birley, now IT director at Browne Jacobson LLP, Nottingham, England. “The operating system was built, tested and had been successfully piloted. Rollout had commenced on a region-by-region basis. But when it had been completed for 750 users, the performance of the system had degraded to such an extent that it had to be stopped.”

The IT project executive was out sick and the rest of the project team was struggling to come to terms with the problem. That's when Mr. Birley was dispatched “to correct the project and get it back on track.”

Right away, he discovered the senior executives were in a grim mood and needed a lot of attention. And Mr. Birley wasn't so sure the team—which had been on the project since the beginning—was going to take kindly to some stranger coming in and taking over.

“Both parties required a lot of one-to-one and team meetings to establish a command structure and methodology to find and fix the issues,” he says. “It was important that a communications plan was put in place and that we actively remove the rumor mill that was circulating within the teams. From this listening phase, it was also evident that not all the right people were involved and some expertise had been sidelined. So another fundamental was to identify the skills base and make sure the right people were in the right place.”

Having tackled the people, communications and methodology issues, Mr. Birley created a detailed analysis of existing data, including project plans and issue logs. As these were not all complete and up-to-date, interviews and system data had to be collected to paint a true picture of the situation at hand. From that, some culprits emerged: a lack of change management, multiple vendors that were poorly managed and blaming each others' products, poor version control and inadequate testing.

Mr. Birley worked with the team to establish change control, take charge of vendors, manage version control, and set up quality standards and comprehensive test plans.

In the end, he traced the problem to the integration of certain software elements. Once those were corrected, the rollout across the company was completed successfully.

“Listening, restructuring and bringing the right people together helped the majority of the team feel more involved. They could see that there was a logical structure to the problem-solving,” Mr. Birley says. “This helped improve morale because the ship now had a captain, crew and a rudder that was pointing in the right direction.”


Once a project is on the troubled list, it only makes sense to look at the project manager in charge. If indeed a change is necessary, the powers on high should take care in how they handle the extraction.

“If the project manager has been removed for a good reason, there's a good chance morale might increase or improve,” says Michael Krigsman, Asuret Inc. “But if a popular and effective project manager is being removed for what is perceived by the team as unfair political reasons or retribution, then the change could seriously damage morale.”

Whether or not the change is welcome, management must treat the situation with sensitivity to enable the team to move on. “Any time a person is removed, it needs to be handled with respect and delicacy,” Mr. Krigsman says.

Sometimes, though, getting to the core of the problem can be a stumbling block in and of itself.

“You might have a hunch that a project isn't moving the way it ought to, but it can be very amorphous to get your hands around,” says Brian Sommer, CEO of TechVentive, a strategy consultancy in Batavia, Illinois, USA. “Usually the issues are not about something technical going wrong. More often, it's a people issue—something political about the budget or funding.”

Even problems that exhibit themselves as technology failures can be the result of underlying business or management decisions. “It's very easy to point the finger at the technology when in fact the roots of the problem are often buried in business, organizational and cultural issues lying at the heart of the project's foundation,” Mr. Krigsman says.

Project leaders need to develop a plan to get the team member back on track—or determine when it's time to cut that person loose.

Early in his career, Alex Brown, PMP, president of Real-Life Projects Inc. in Belle Mead, New Jersey, USA, inherited a problem project. At the time, he was working in the brokerage services division at Automatic Data Processing.

The project involved cleaning up a database that contained several million securities transactions to meet a regulatory requirement. It had been started and stopped at least four times by project team leaders who came before him. When the assignment was passed to him, Mr. Brown was told by more than one customer that they thought it was technically impossible. By assembling a small team, securing key stakeholder involvement, practicing diligent quality control and creating a realistic timeframe, Mr. Brown and his colleagues successfully completed the project—proving the perceived problems were less technical than managerial.

Step 3: Go straight to the source.

Sometimes the problem can be traced to one person, otherwise known as “The Bottleneck.” If that's the case, project leaders need to develop a plan to get the team member back on track—or determine when it's time to cut that person loose.

First, document the problem, says Ad Blankestein, PMP, managing director, Advalue Management Services Ltd., Orewa, New Zealand. Then, meet with the person to develop a plan for improving performance, for example, through training or tools.

Be sure to create a record of the conversation, work out a timeline with specific tasks outlined for each juncture and make sure the team member signs off on it.

“If this doesn't solve the problem, then there's only one corrective action left and that's to remove the bottleneck person from the project,” he says.

Recognize, too, that attitude can make all the difference. Working on a software development project plagued by delays, Mr. Blankestein identified the lead developer and solutions architect as the bottleneck. “When confronted, he admitted that he was not delivering to plan, [but he said that] he didn't need any support or training, and he was not going to change his behavior,” he says. “The end result was that he was replaced by someone who was more of a team player. We saw a dramatic improvement of project performance despite the fact that the new lead developer had less technical knowledge than the person he replaced.”


On a failing project, emotions inevitably run high. Here are some prescriptions for dealing with ill feelings on a team:

“If frustration exists, it will ultimately find an outlet. The trick is to find ways to allow people to channel that frustration constructively. Free and open discussion can be healthy. But if you take the pulse of the team and discover that having a group session is likely to deteriorate into anger, name-calling and backstabbing, that may not be the best course of action. You're not talking about a database. These are shades of gray and the human factor is always complicated.”—Michael Krigsman, Asuret Inc.

“You might take the group off site, even if it's to a local restaurant at lunch, and allow team members to talk about the stuff that doesn't show up in status reports. Some people prefer one-on-one discussion, and some prefer a small-group setting. Either way, that interaction has to happen at the person's level.”—Brian Sommer, TechVentive

“One of the first things I do when analyzing the true status of a project is meet with team members and stakeholders individually. If it turns out that the problems are of a technical and/or procedural nature, I will have a team meeting to brainstorm how we should address the issues. If the problems are caused by personality clashes, I will meet only with the team members concerned, in the presence of a mediator, and explore the reasons behind the clashes and if there is a way out.”—Ad Blankestein, PMP, Advalue Management Services Ltd.

Step 4: Develop a plan for recovering the project—or not.

As denial makes way for acceptance and a realistic confrontation of the issues at hand, a project manager must figure out how to move forward.

Often, this is a matter of deciding whether to adjust the project or put it out of its misery. “Because of escalating costs, you might determine that the best thing is to gracefully package it up and prepare for a mercy kill,” Mr. Sommer says.

But because project managers usually don't have the authority to eliminate a project, the burden is on them to investigate and analyze the problems. That means weighing the results against the business case for the project, says Mr. Blankestein.

He suggests creating a viability report that includes:

  • Overview of the stakeholders interviewed, documents reviewed, and the issues identified and their underlying causes
  • Outline of the options explored, with pros and cons of each
  • Recommendation and justification of the way to move forward.

If continuation is advised, the report should state the conditions that need to be met for the project to be successful and a list of recommended corrective actions.

If scrapping the project is seen as the way to go, the report should offer alternatives for meeting the need that initially sparked the project. For example, if the project involves building an IT system in-house, suggest purchasing one off the shelf.

Step 5: Rally the troops.

In the case of a salvageable project, moving ahead swiftly and decisively is the best way to boost team morale and prepare for a new project phase, Mr. Blankestein says. First, restore confidence and credibility by communicating to the team that a project recovery is in the works.


Listen to team members and take their concerns, remarks and suggestions seriously. Brainstorm some alternative solutions with the team and break the usual line of thinking that may have prevented the project from moving forward

Ad Blankestein, PMP, Advalue Management Services Ltd., Orewa, New Zealand

“Listen to team members and take their concerns, remarks and suggestions seriously. Brainstorm some alternative solutions with the team and break the usual line of thinking that may have prevented the project from moving forward,” he says. “Involve the team heavily in replanning the project and estimating project tasks. The objective here is to come up with a plan that's realistic and not dictated by wishful thinking by senior managers.”

Additional steps might include implementing better project management structures and controls, or requesting additional support and backup from senior management.

Whatever the brilliant plan turns out to be, all key stakeholders must agree on the project's new direction and buy into the recovery process.

Sometimes that means renegotiating the scope, timelines and costs of the project with the client—but that may not be as hard as it sounds.

“In most cases, it is cheaper for the client to renegotiate the project than to kill the project, write off their investment and start all over again with a new project,” Mr. Blankestein explains. “But, having said that, the client is only willing to do this if they have the confidence that the project organization is committed to addressing the issues and is serious about the project recovery operation.”

Once everyone has signed on to the plan, project managers should hold daily team meetings to discuss progress, problems and targets.

And when things do start to turn around, give the team some credit. “Celebrate successes, even small ones, to reinforce with the team that the project is heading in the right direction,” Mr. Blankestein says. PM

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.




Related Content