Cancelling a project without cancelling your career: white paper

This white paper is part of our "From the trenches" collection. It describes best practices for recognizing when a project should be stopped, the benefits of doing so, and considerations you need to take into account when cancelling the project.

To download the Word version of this white paper, see Cancelling a project (without cancelling your career): white paper (Project Server 2010).

To see more white papers, see "From the Trenches" white papers.

Cancelling a project (without cancelling your career)

As project managers, we're hard-wired not to quit. People who quit something easily don't find the role of project manager to be at all attractive. Project managers are, by nature, optimistic. We are the results-oriented, challenge-motivated, never-say-die, make-it-happen, see-the-glass-half-full sort of people. After all, when the project is in its infancy, where there is nothing at all to show for it but a good idea, the project manager carries the vision of the completed project with them. She is the evangelist for the project's completion.

Even now, aren't you reading this very article and thinking, "I hope he's going to tell me how to save that project that I really don't want to cancel"?

You wouldn't be alone.

As a culture, project managers are natural cheerleaders. I don't know about you, but when I watched the movie The Perfect Storm, when the ship was going straight up the wall of water, I was silently cheering, "C'mon. You're gonna make it." Surprised? (Spoiler alert: The boat didn't make it, and I knew that before the movie started. It didn't stop me from cheering).

Sometimes, it's just time to stop

The Dakota Indians have a saying, "If the horse dies, dismount." Project managers would prefer to do anything but. Rather than getting off a dead horse… er, project, project managers are more likely to change riders (project managers), put two dead horses (projects) together to see if they pull the cart faster as a team. We'd prefer to rename the horse, send the rider for more training, add funding to the horse or just wait quietly on top of it hoping that no one notices that it's not breathing and avoiding a declaration of what everyone already knows. The horse isn't going any further forward.

Yet, in a modern project management world, our focus is likely to extend beyond a single project and into portfolio management, and when projects must compete for the same resources, there may come a time when cancelling a project is the best path forward for the entire organization.

Stopping a project begins with identifying the fact that it would be inappropriate to continue. That may not be obvious. Some organizations have adopted stage-gating processes as part of their project portfolio management environment. Stage gating sets up formal reviews between each phase of the project and ensures that the project is ready and worthy of moving forward. Yet, even in this structure, there is resistance to stopping a project. It is not at all unusual to find a stage-gating environment defined and implemented but also to find that there is no political will to stop a project once it is started. There is stage-gating, but all the gates are open.

If you can't slow, pause, or cancel a project, then stage-gating has little value.

The reason the project shouldn't go forward may not be anyone's fault. There are a limitless number of possible reasons. Perhaps the economics of the project have changed. The expected return on investment is now clearly not going to happen because the price we thought we'd get for the finished product is no longer viable. Perhaps the economy itself has changed. A project of luxury goods perhaps has no place in a region where luxury is no longer sellable. Perhaps a competitor has changed the landscape by releasing a competing product before you expected and before you're ready. Perhaps you've lost some key personnel with critical knowledge and expertise that are required for the project's success; or perhaps the project has exceeded a budget, schedule, risk, quality, or complexity threshold that makes continuing with it questionable.

The project has already started, so how do we stop it?

Whether you use a formal stage-gating process or an ad-hoc business review process, there are a number of methods to determine that a project should not go forward.

The first and most obvious is to do a business case "refresh". Whatever business driver metrics you used when the project started should get reviewed. Does the project still have the chance to deliver the expected return on investment? Is the deliverable from the project still desirable? Using the same structure you used to evaluate the project before it started allows you to compare what the current situation is.

Another possible method is to use the 10 knowledge areas of the Project Management Institutes PM Body of Knowledge: Evaluate the status of the project from each of these areas and compare that evaluation against your expectations at the beginning of the project:

1. Project Integration Management

2. Project Scope Management

3. Project Time Management

4. Project Cost Management

5. Project Quality Management

6. Project Human Resource Management

7. Project Communications Management

8. Project Risk Management

9. Project Procurement Management

10. Project Stakeholder Management

Let's take number 8, Risk Management, as an example. The project should have the most risk on its first day. That's when you have the most "unknowns". On the last day, the risk should be zero because you've just delivered the project. You now know how it turned out. You'd naturally expect, then, that as the project progresses, the amount of risk would diminish. Is that so? If the risk is continuing to increase, that may be a sign that the scope of the project needs to be revisited.

If you do a Return on Investment (ROI) analysis (always a good thing to think about when you pause a project for a business review), don't forget that the "I" in Investment is not zero. You've already spent some of that money, so the investment you have to consider is the remaining resources and money it would cost to complete the project. If you cancel the project, the "R", as in Return, may be zero but at least the "I" will not get any bigger.

As you are doing your business review, it's also a good thing to think of the opportunity cost. If you weren't spending any more on this project and your resources weren't tied up on this project, could they be doing something on another project that would be so valuable, that the lost investment here would be overcome?

End it right

If you do have to cancel a project, make sure you do so consciously. Just ending a project in an emotional tirade can cause more damage than keeping it going.

Make sure you take care of the team members who are on the project that is about to be cancelled. Over-communicate and make sure the staff have an opportunity to give feedback during the business review. Perhaps they have a perspective that you haven't considered and all input at this time is probably welcome.

Adopt some key end-of-project best practices and make sure you apply them in this situation. They might include:

• Meeting the staff to review what can be salvaged from the work in progress. There might be some big benefits you don't even know you have.

• Staying away from blame is a great idea here. Blame is generally useless anyway but focusing on who to blame instead of what to do can rob you of any opportunity to get positive results out of this otherwise unhappy result.

  Do a wrap-up meeting to close off the project and thank all the team members for their participation. Make sure that any lessons learned and other project documentation is recorded and archived along with any work-product.

• Make sure there is a final accounting of the project so the true cost vs. benefit can be calculated. Also make sure not to forget your sub-contractors. Make sure all outstanding invoices are resolved and that there is nothing outstanding with your vendors such as long-term subscriptions. After all, you may be working with them again on the next project soon.

The benefits of stopping the project now

It isn't all bad news. As part of your business review, there may be some returns on the project's investment to date that are worth pointing out.

The first and most obvious benefit is the newfound availability of the project-team members. If they aren't working on this project, they will immediately become available for other projects.

Next is salvage. It is often surprising to people how much work-in-progress can be adapted to other purposes. In some cases, this can be a complete (but more modest) product. In other situations there may be recoverable modules that are immediately valuable on other projects. Throwing out everything that has been accomplished is often a big mistake. Include in your salvage thinking things like hardware, software, subscriptions and services that have been pre-paid for. Perhaps another part of the organization could use those licenses for something productive.

A soft benefit is almost always improved morale. Almost everyone working on a project that needs to be stopped knows it should be stopped before it happens. There is almost always a sense of relief that the issue is out in the open rather than something feared, and the knowledge that the end of the project doesn't mean the end of their employment is usually great news for those staff who can now work on something more productive.

What about my career? Am I now associated with a failure?

In 2005 KPMG did a Global IT Management Survey. In it they discussed projects that had to be stopped, and one commentator said, "Cancelling a project unlikely to deliver expected benefits should not be seen as a failure — failing to cancel such a project should be." It makes perfect sense. If you are a cheerleader for a project that should not continue, then you've just become part of the problem, not the solution.

A side benefit of going through this unexpected end-of-project process is that you become an "honest broker". You've been willing to stand up and share the bad news and your credibility with management as a result will almost certainly increase. If you've done a good job of closing out the project you've also got a lot of data and benefits to offer. There is the accounting of what was salvaged and a true accounting of both the investment and the return. The benefits to the rest of the organization should also be pointed out as you'd like management to know that cancelling a project isn't always a catastrophe. After all, freeing up the availability of your team members has made the success of other projects more likely.

No project manager wants to quit on a project. It's not in our nature. But it's a natural part of being a project manager and something every project manager needs to be ready to face.

About the Author

Chris Vandersluis is the president and founder of Montreal, Canada–based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (http://www.epmguidance.com/?page_id=39).