Sink or swim: 10 steps to rescue a foundering project

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.