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 US 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 US Department of Defense's Naval Surface Warfare Centre, 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 California.
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 EM Bennatan, author of Catastrophe Disentanglement: Getting Software Projects Back on Track(Addison- Wesley Professional, 2006) and president of Advanced Project Solutions.
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 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. 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 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.