By Lonnie Pacelli

Project managers focus on bringing a project to a successful conclusion. But what about a project that shouldn't be completed? Knowing when to pull the plug on a project is an important skill to build — a skill that can cement your reputation as a project manager who is objective, credible, and rational. I've always greatly respect project managers who, for example, put the customers' interests ahead of their own by ending a project because it would not meet the customers' needs.

Why stop a project?

These are some key reasons to consider calling off a project:

• Lack of benefit   The anticipated benefit of the project will not be realized.
• High cost   The anticipated costs of the project will greatly exceed budget, making it cost prohibitive.
• Priority issues   Other projects have taken a higher priority because of a business environment change, resulting in diversion of resources from your project to the other higher-priority projects.
• Design problems   The project's proposed design will not meet the customers' needs.
• Execution problems   Execution of the project is going poorly, and the project is unable to recover.
• Change management problems   The change management issues are too large to overcome.

It's important that the entire project management team, led by the project manager, makes the decision to stop a project — and that everyone agrees that stopping the project is the best business decision. Whenever I stop a project, I carefully review the rationale behind the decision with the project team. I make sure that the team has an opportunity to give feedback on the soundness of the decision. After the team members agree to stop the project, the steering committee and project sponsor review the recommendation for approval.

At one time, I was the project sponsor on a project where the objective was to put in place volume discount pricing for a key commodity that my group purchased. We were unsuccessful at getting more than a 1%–2% discount during negotiations with our key vendors, because we were unwilling to guarantee specific volumes of business to the vendor. In addition, we were concerned that our relationship with those vendors might erode because we were expecting them to give us a concession without us giving them a similar concession. So, the project stopped because it just didn't make business sense to continue. Even though I passionately pushed for the volume discount structure, my team and I finally agreed that stopping the project was the right decision.

Factors that can contribute to project failure

• No specific checkpoints are established   At the end of each phase in your project, the team should assess whether the customers' needs can still be met and the cost/benefit of the project is still intact. For example, on some projects I have midphase checkpoint assessments to review what my team has learned so far. This information could affect the customers' needs or the cost/benefit. Define logical checkpoints in your project so that you can determine whether it's best to proceed.
• The team loses objectivity   In order to deliver successful results, getting the project team to "gel" and work well together is a key goal of project managers. However, I've seen projects where the team gelled so well that they wanted the project to continue because they really enjoyed working together and were tied to "the cause." It's great when project teams work well together; but when they lose business objectivity, they're less willing to stop the project because they're having too much fun. I'm not advocating that the project team avoid solidarity or enjoyment. Just be sure that objectivity and sound business logic prevails.
• The team relies on a "silver bullet" to save a sick project   On one of my projects, the product being developed suffered from horrendously slow performance because of technical issues. The team (at my direction) slogged away trying to bring the response time within acceptable limits, but we were unable to make things work. I brought in some additional technical experts to help on the project, but they told me that I was never going to have acceptable response time with the current technical architecture. After excessive searching for a silver bullet solution, I finally succumbed to pressure and stopped the project. Trying to rectify problems with due diligence is great, but don't let those problems linger too long while you search for an unlikely solution.

Warning signs of potential project failure

• The customer or project sponsor loses interest   If scheduling time with your customers or project sponsors becomes increasingly difficult, they may be losing interest. They may have more important priorities or may lack the faith that their projects will be completed successfully. Get clarity from your customers or project sponsors on the relative importance they place on your project.
• The project sponsor changes   At any time the project sponsor changes, questions will arise about the project, its business case, and its priority relative to other projects. The new project sponsor may have different ideas about the project and its importance relative to other ongoing or potential projects. Understanding the new project sponsor's expectations lets you know whether your project is on his or her radar.
• Major issues are unresolved   Major issues that go unresolved, despite efforts to address them, are a strong signal that the project may be in jeopardy. Clarifying the true consequences of the issues and creating resolutions to the potential problems are good guideposts in determining whether the issues have the potential to truly stop the project.
• Skepticism exists about the viability of the project's business case   Questions about the business case could just be an issue of educating a customer, sponsor, or stakeholder. Conversely, questions could mean that the project isn't as important as it once was or that the original benefit statement is unattainable. Reconfirming the project's business case is important in determining whether the original business case still holds water. You may need to decide whether there are projects that more important than yours.

Turning it around

• Define checkpoint milestones   Establish project milestones with your sponsor at logical review points to determine whether it makes sense to continue the project. At your review points, go through your project continuation criteria and verify that continuing the project is still the right answer.
• Assess the outstanding major issues   Get a clear understanding of the issues, of the potential alternatives to dealing with each issue, and of the course of action that you will take under each alternative. Some of the alternatives may or may not include stopping the project.
• Stop the project   If it doesn't make sense to continue the project, be deliberate with your project sponsor about driving a stop decision. Stopping a project is not a fun thing to do, but it might be the best business decision.

Project managers need to demonstrate that they are business managers who are willing to make difficult decisions, even if it means killing a pet project. When you make the right business decision, your credibility with management can skyrocket.

About the author   Lonnie Pacelli is a business owner, consultant, and author with more than 20 years of experience as an executive, project manager, developer, tester, analyst, trainer, and business owner. He is author of The Project Management Advisor: 18 Major Project Screw-ups, and How to Cut Them Off at the Pass (Prentice Hall, 2004).