7 Steps to Rescue Runaway Projects

A Contributed Article By Joseph Zucchero

You know that classic scene in western movies: Four horses are galloping at top speed, pulling a driverless stagecoach occupied by a damsel in distress. The hero saves the damsel by jumping from his horse to the stagecoach and reining the horses in before the stagecoach plunges off the cliff.

Rescuing a runaway project is a lot like rescuing that runaway stagecoach; you have to rein the project in before it goes plunging over a cliff.

If you don't rescue your runaway IT project, two things could happen - and both are like falling off that cliff. First, because of the accumulation of time, cost, and aggravation, the project could reach its breaking point and collapse under its own weight; you have no choice but to stop. The only thing that could delay the project from imploding is your threshold of pain.

Second, if you don't rescue the project, someone else (usually your comptroller or CFO) could come in and tell you enough is enough and that it is time to stop the hemorrhaging of cash. At that point, all the money you invested in the project becomes expense. This could be very embarrassing if you work for a public company; no one wants to say, "We are going to take a $10, $50 or $100 million charge because of a failed IT project."

However, like the stagecoach in the westerns, your project can be saved. Half the consulting projects my team has been involved with have been rescue services; rescuing projects that ran away from the sponsors. You, too, can rescue your runaway project if you follow these seven steps.

1. Admit you have a problem. Some IT people are like bad investors: They stick with the dogs (projects that are losing money) instead of cutting their losses. They think they can spend their way out of a bad project, which is like buying more of a stock that is going down the drain. Therefore, the first thing you have to do is admit you have a runaway project. This is difficult because many people say, "I'm this close. I just need one more month." However, that last month never comes.

One reason the last month never comes is that the project gets "last-mile syndrome"; it takes 95 percent of the project time to finish the last 5 percent. If you are still waiting for your last month, look in the mirror and admit you have a problem.

2. Pause the project. Why? By continuing, you are burning more hours and cost against the project and you really don't know where you are going. You don't even know if you are on the path of completion. As with a military operation, pausing the project gives you an opportunity to regroup and create a new plan.

Out of all the steps, pausing is the hardest and the scariest. Some people might think the ship is sinking and want to flee the project. If you're working with a vendor, it may want to pull its team out because you are pausing. However, if you don't stop, the results down the line will be even scarier. (Remember that cliff?) To pause the project, you may need someone with enough vision, clout and security to say, "This project is not on the right course."

3. Conduct a project audit. The purpose of the project audit is to find the root cause for why things are going wrong. From my experience, the primary reason projects runaway is that the project manager is relatively inexperienced. The project manager may have only worked on smaller projects and the runaway project was beyond the person's capabilities. In addition, there may not have been a support system in place to help the project manager overcome this lack of relative experience.

Another common cause of runaway projects is a deficient project charter (statement of work). In some cases, the team does not have a project charter. Without a project charter, the project is not truly defined.

4. Assess the effort to complete the project. You need to know what it is going to realistically take to finish the project and how much you are going to spend. Unfortunately, when initially estimating projects, most people use intuitive estimating; they estimate from the gut instead of from experience. Intuitive estimating may work with small projects, however, large projects in which you are dealing with more than one business organization (such as manufacturing and sales) require experienced-based estimating.

To realistically assess the effort to complete the project, review the project and see how long it really took to complete tasks. Don't assume you are going to do things so much better or that tasks will take less time. If necessary, bring in someone who has done the particular task to get a realistic estimate.

5. Validate the ROI (return on investment). Today, "ROI" is seen as a bad word with IT. However, someone must have had justification for implementing the project in the first place. Ask yourself, does the ROI still make sense? Do the business benefits make the project worth continuing?

It is possible that the project's importance has decreased over time. Or, the ROI perception may have changed based on external market conditions, such as alternative solutions. For example, one company was building an enormous multiyear project in the late 1990s using client/server technology. Fortunately, it stopped the client/server project and used Web-based technology. If the company had continued using client/server, it would have had problems maintaining the project.

6. Put the project back into the IT-governance hopper. You must determine if it still makes sense (from a business perspective) to pursue this project at this time and if this is the best use of your company's cash. Look at the value of the project and compare it to other IT alternatives and initiatives. Maybe two years ago the project was a priority, but now something else (like a self-serve application that will dramatically reduce cost) is better because you have cash-flow problems. My team recently met with a company that had a billion-dollar IT budget. IT was asked to cut the budget by 15 percent. We asked, "How do you know that $1 billion is not the right number?" They didn't know. It's possible that once the project goes back into the IT-governance hopper and is determined to be the best use of the company's cash, the actual budget should be $1.5 billion.

7. Restart the project. Now that you have a new project plan and new estimates, re-launch the project. Beware of roadblocks - things that can get in the way of your rescued project. For example, the project could be tainted. With one company, even after we relaunched the project, we had a hard time getting user cooperation because they no longer believed the project would be successfully completed. However, 45 days after the relaunch, the users realized that the project was going to work and submitted a barrage of change requests.

To combat apathy and disbelief; the executive sponsor must tell people that the project is important and act like the project is important. People take their cues from the leader. In the above case, the executive sponsor supported the project, which convinced the users that the project was going to work.

Like the hero in the westerns, you can rescue your runaway IT projects by following the steps outlined above. And, once you rescue your project and get it on track, you'll find that others will want to jump on board, too.

---

ABOUT THE AUTHOR

Joseph Zucchero, Executive Vice President, The Casey Group

Zucchero has extensive experience in program and project management and the execution of highly sophisticated IT contracts. Previously, he worked for Keane, Inc., where he was a director of Service Delivery and the Florida e-Solutions Practice director.

---

SIGNS THAT YOU HAVE A RUNAWAY PROJECT - Deadlines are being missed. - People don't know what tasks they are working on. - People keep coming back for more and more budget. - A lack of or irregular status reporting. - "Creative" status reporting; people make things up. - Project plans have not been maintained. - Tasks are big blobs of time, like one month, instead of smaller time frames, like 80 hours.