Sink or swim: 10 steps to rescue a foundering project

Computerworld, September 04, 2006 -- Slipping schedules and budget-busting costs were the primary warning signs that prompted Pete Gibson to halt a project that was under way in 1998 when the U.S. Navy was updating its Tomahawk missile program.

In the first phase of this multiphase software development initiative, various vendors were replacing a proprietary onboard missile-launch control application with a commercial, off-the-shelf system. According to Gibson, then program manager at the U.S. Department of Defense's Naval Surface Warfare Center in Dahlgren, Va., the vendors had run so far over budget that he had to dip into funds that had been allocated for the initiative's second phase. Moreover, the delays caused by the vendors had put the entire project a year behind schedule.

To stop the bleeding, Gibson's team helped the companies solve integration problems by developing a new interface for the launch control application. With the clock ticking, the team's priority was to get it done quickly.

"It was not as robust an interface, and the system was less integrated, but it still met functional specs," Gibson recalls. "It saved us a lot of development hours so that we could complete the second phase of the project and roll out the entire system to the fleet.

"If it wasn't for that solution, some people speculate that the DOD would have canceled the entire project," says Gibson, who is now vice president of IT and systems development at Phoenix-based Wyndham Hotel Group.

When a project is sinking, how do you decide whether it's better to save it or let it die? And if it is worth saving, how do you get it back on track?

The first thing to do is step back. "When a project is in trouble, you need to look at the strategic vital signs. You need a higher-level view," says Gopal Kapur, president of the Center for Project Management in San Ramon, Calif.

Although the project manager might be the first to spot signs of serious trouble, he may not take appropriate action.

"Usually, project managers will believe that they can resolve the problem themselves, or they may even be oblivious to the severity of the problem," says E.M. Bennatan, author of Catastrophe Disentanglement: Getting Software Projects Back on Track (Addison-Wesley Professional, 2006) and president of Advanced Project Solutions Inc. in Northfield, Ill.

Denial can also come into play. "You don't want to admit it, so you don't go into the stage of reassessing the project," says Dan Demeter, CIO at Los Angeles-based Korn/Ferry International.

It's often up to the project sponsor to decide whether a project is stumbling enough to warrant a reassessment. Once he does, there are many ways to approach this process, but Bennatan suggests 10 steps that pretty much cover the bases. He says that the entire reassessment process shouldn't take more than two weeks to complete for midsize to large projects.

1 Stop the Project
The sponsor, project manager or key stakeholders can call a halt. That stops the damage from continuing and grabs everyone's attention. "You need everyone's total cooperation. If they're scrambling to develop the project in parallel with trying to save it, you're not going to get their attention," Bennatan says.

But some experts discourage this tactic. Stopping the work "forces people to multitask if you take them off the project for two weeks for something else and then bring them back to the original project," says Johanna Rothman, president of Rothman Consulting Group Inc. in Arlington, Mass. She suggests that you reduce wear and tear on the team by evaluating the project before deciding whether to halt the work.

Whatever you do, keep your team informed. "Communicating with your team is fundamental," says Gibson. "The team needs to be made aware of why the project is stopped. If they understand what's going on and they're empowered to make the right decisions, they normally do well. When they're kept in the dark, they get frustrated."

2 Assign a Project Assessor to Determine How Bad the Trouble Is
Bring in someone who has no stake in the outcome. That could be a consultant or a senior manager from another division of the company. Large projects might require an evaluation team.

Choose someone who is politically sensitive, because he will need to work closely with the project manager without making him feel threatened, even though he may determine that the project manager is part of the problem.

3 Assess Project Status
To get a handle on where the project stands, the evaluator should meet with the project's sponsors, stakeholders and team members. He also must review project documents and assess the product under development.

"You have to re-evaluate the strategic importance of the project," Demeter says. "The chances are that it's floundering because it doesn't have the support that carries a project forward. That's probably because its value is not recognized yet, or it's not there."

Projects sometimes start and flop repeatedly because those with insight into the root of the problem stay quiet rather than risk getting caught in a political firestorm. Therefore, it's imperative that the evaluator probe for bad news. "The project auditor should encourage the team to help him identify where the defects are," says Bill Ingersoll, vice president at The Casey Group Inc. in Parsippany, N.J., whose services include IT project management.

4 Evaluate the Team
The evaluator should examine the team's dynamics and skills and the project manager's ability to lead. A common finding, Rothman says, is that the project manager is inexperienced in managing technical projects. Barbara Kunkel recalls a project in which the manager didn't have sufficient technical background. Rather than remove him, Kunkel, who is CIO at law firm Nixon Peabody LLP in Boston, appointed a co-manager who had more experience. "The original manager agreed that was exactly what he needed," she says.

5 Redefine Minimum Goals
"Most projects go bad because they've been overcomplicated," says Jim Lester, senior vice president of global technology strategy at Aflac Inc. in Columbus, Ga. "You get caught up in 'requirement rush.' You continue to add requirements, and it gets so complicated, it's like a duck-billed platypus. The project team can't figure out what they're building. They can't see it in their mind's eye."

The evaluator works with stakeholders to establish a new set of minimum project requirements. Bennatan suggests dividing the requirements into three groups: essential, very important and "spit and polish." Then "throw out the last two groups," he says.

If stakeholders balk at relinquishing their favorite requirements, say you'll try to revisit those. Tell the customer, "Let's cut back. Let's deliver some of the key value-driven requirements and get this implemented. Then we'll come back and take care of some of these other things later," says Lester.

6 Determine Whether the Minimum Goals Can Be Achieved
The evaluator should follow a formal project-feasibility process to see if the minimum goals can be met, ensure that the key stakeholders agree to the new goals, develop preliminary time and budget estimates for meeting the goals, re-evaluate whether the project is technically feasible, and gauge the team's confidence. If he uncovers serious roadblocks, he can suggest that the project be killed.

7 Rebuild the Team
If the project is still alive, the evaluator should consider the new requirements against the team's performance, skills and interpersonal dynamics. He should spend time with every team member to get a feel for what goes on behind the scenes. "You can have a [project] manager who writes a great plan, but if he's not communicating it right and providing guidance, he's not managing the project right. The only way you'll find that out is to talk to the team members," says Ingersoll.

If the project manager is deemed competent, he may be asked to lead the new effort, says Rothman. "Typically, once people know they should do something differently and they know what that different thing is, they're very good at going in and doing it," she says.

Ingersoll warns against training project members during the turnaround, though. Put together a team that has the skills you need to get the job done.

Once the team is ready, the project manager needs to do whatever is necessary to revitalize it. "You have to build the relationships again," says Kunkel.

When Kunkel revamped a failed portal project at Nixon Peabody, getting key stakeholders and the project team pumped up again was a major key to the turnaround. "You have to go back and be the cheerleader to get people back on board with you," she says.

8 Perform a Risk Analysis
The evaluator, project manager, key team members and stakeholders should list potential problems, estimate the likelihood that each could occur and determine its potential effect. Then they must develop a plan for mitigating each risk. They should focus on serious potential problems, leaving analysis of less-serious risks for after the project starts, Bennatan says.

9 Develop a Plan
Before the project is revived, the evaluator, along with the project manager and project team, needs to create a formal plan for moving forward, says Bennatan. The plan should serve as a vehicle for getting formal approval to start the project rescue, explain in some detail how the project will be cost-effective and provide a foundation for the detailed project plan that will be developed once the rescued project is officially under way.

10 Implement an Early-warning System
"Put in place all the hooks necessary to make sure that the project doesn't slip back into catastrophe mode again," says Bennatan. Collect metrics, periodically review project status, define red flags, and create procedures for corrective action and follow-up.