How to cancel a failing project gracefully


A couple weeks ago (August 21, 2011 to be exact), I was watching a “60 Minutes” interview on TV about whistle blowing and a NSA employee’s possible trial for espionage. Interesting stuff, I guess. However, what caught my attention was that the charges revolved around a software development project. (Here’s the full story, if you are interested: U.S. v. Whistleblower Tom Drake.)

The gist of the story began when the NSA needed greater capability to sort through the terabytes of data it collected. Internally there was a tool, believed by the whistle blowers, to meet the NSA’s requirements. However, the Director decided to requisition develop of a new tool, called Trailblazer, that did everything they could imagine needing to be done. Millions of cost overrun dollars later, the project failed and the former head of NSA, Lt. Gen. Hayden told congress, “A lot of the failure in the Trailblazer Program was in the fact that we were trying to overachieve. And that a lot of the failure was that we were trying to do too much all at once.”

Been there. Done that. Got the project coffee mug!

Even when you are project manager for less grand goals than saving freedom and democracy, there comes a time in the life of many projects when the failure handwriting is on the wall. How can you tell when it is time and what is the best way to end a failing project?  Back in 2009, I wrote a post on Spotting a Failing project that was a short piece on the subject. In the current economic environment I have once again been asked to re-visit the subject by several of my clients.  I am not sure I have a nice precise answer to either of these questions, but I will share my thoughts on this often overlooked subject. 

Signs of a Project in Failure Mode

Recurrent cost and schedule over-runs may signal that a project is doomed to failure. Disruptive technologies or changes in the business case for a project can (and should) lead to project cancellation. In addition, customers can lose funding, especially in a recession or on government contracts subject to priority changes. All of these situations provide legitimate reasons to stop working on a software project.

I would like to add a few of my own observations – I have borrowed a couple, some tongue in cheek, from Code Squeeze’s “101 Ways to Know Your Software Project Is Doomed.

Bruce’s top ten signs that your project may be a failure:

  1. The schedule changes every day
  2. No one has heard from nor can they find the project sponsor
  3. The weekly status report is always the same – it never changes
  4. Project resources (staff) are constantly changed out without notice
  5. No one can find the actual requirements document
  6. Every bug is prioritized as Critical and every feature is prioritized as Trivial
  7. Project cost estimates magically match the budget – all the time
  8. The phrase ‘It works on my machine’ is heard more than once a day
  9. All code reviews have been moved to a week before product launch
  10. None of the project team leads shows up for the status meetings; they send a proxy

For those of you working on Government projects who want some insightful information on why government software development contracts often fail, I highly recommend the Clutter IT Journal article, “How do the turkey projects get wings …” by Payson Hall. I also wrote a post about how bad estimating on government projects can lead to failures. The hard part is defining that your project is failing – sometimes you have to re-think what success would be.

How to Terminate a Failing Software Project with Grace

Grace means gaining concurrence from the project’s key stakeholders that stopping an irrecoverably failing project is the best action for all concerned. Or, to quote an old saying, “Don’t throw good money after bad.”

As a project manager, you created a risk management plan during initial project development that included trigger conditions to be monitored to indicate when the project’s success was threatened. I recommend contacting your PMO, portfolio manager or supervisor as soon as the trigger condition occurs. Tell them your plans to investigate the problem and give them a deadline to report results and recommendations. As part of your investigation, talk with your lead technologist in an effort to identify any products from the effort that can be salvaged as deliverables. Do not be offended if managers that are more senior suggest calling in a consultant to get a second opinion or to assist in generating options to project cancellation.

When alerting clients to a potential project failure, it is better to have a face-to-face meeting than to send a report or wait for the next scheduled review. I understand that no one likes to be the messenger bringing bad news. However, if you have done your due diligence in assessing the situation, the sooner you gain concurrence and understanding from customers, the sooner you can move on.

When explaining the situation to customers, present the problem in non-technical language, offer your conclusions and recommendations. If you have a recovery plan, present the options along with their associated cost and schedule implications. If you identified salvageable elements from the project, describe how those can be polished and delivered.

Assuming that you are successful in convincing management, clients and sponsors that it is time to pull the plug, you should still push to perform some key tasks.  Before closing the project, create documentation and lessons learned for inclusion in the organization’s knowledge management system.  I am certain that the organization will not want to repeat the same mistakes again!

Please share your thoughts on how to spot and cancel a failing project.

PMBOK: Project Risk Management


Picking up on the series regarding the PMI PMBOK areas (started with “What is the PMBOK all about”), I want to explore the area of Risk Management. I wrote a short post last May (Is Project Management a risky business) but wanted to cover what the PMBOK has to say in more depth.

Racing enthusiasts and fighter plane jocks find taking risks exciting. Businesses and project managers do not!  I think that a project manager has two roles in dealing with risks. One is to identify, analyze and plan to deal with risks to their project’s success in terms of cost, time, scope and quality. The other is to help senior managers and business intelligence analysts identify broader risks to the organization.

Dealing with Project Risks
Chapter 11 of PMBOK is devoted to risk management and offers reasonable process and procedure recommendations for project managers. The risk management tasks listed in PMBOK include:

  • Defining the risk management process – The Plan
  • Identifying risks (see post on “Why identifying software project schedule risks is essential” for some ideas on schedule-based risk analysis)
  • Performing qualitative risk analysis
  • Performing quantitative risk analysis
  • Planning risk responses
  • Monitoring and controlling risks

Because it is not possible to identify or deal with every conceivable risk to project success, I want to focus a bit more on the risk analysis process. The analysis of probable occurrence and the assessment of potential impact provide the deciding factors to select which risks to planned for and which risks to accept.

Qualitative Risk Assessment relies on judgment and experience. New project managers should seek out lessons learned from the organization’s knowledge management system (hint, hint) or ask for input from experienced PMs. You can guide thinking about potential risks by posing theoretical questions to yourself or to a brain storming team working the project such as:

  • What would happen if Sam left or got sick – assuming Sam is a key contributor with unique skills?
  • Have all important decisions on platform, language and process approach been made?
  • Do all stakeholders understand and agree on the project objectives?
  • What if subcontractor X fails?
  • Does the cost and schedule accommodate a learning curve for new hires or new technologies?
  • Do schedule dependencies – see “How to create and use predictive project scheduling” – show any tasks that could bring down the entire effort if unsuccessful?

Quantitative Risk Analysis uses percentages, probabilities and numbers to assess the effect of risks on project success. For some senior management types, quantitative risk analysis is more powerful than qualitative. For example, telling  your boss’s boss that failure to train personnel in the use of project tools might delay the project in meeting milestones is not nearly as persuasive as telling her that the potential schedule delay ranges from six to ten weeks with a cost overrun of $58K at a level of 85% certainty.

Quantitative risk analysis, according to PMBOK, also includes a sensitivity analysis – which risks have the greatest impact – and expected monetary value analysis. Some organizations provide meaningful quantitative risk analysis using simulations and modeling tools to show possible consequences to cost and schedule. 

Organizational Risks
As a project manager, your technical background can help business intelligence professionals and senior managers understand the potential impact of emerging and disruptive technologies. In your interactions with other PM professionals or through tracking events and announcements in trade publications, provide alerts when you see or hear news that affects your organization’s core businesses.

Best Practice
You should approach each project with a checklist of common risks to look for before the project begins.  I have a list I keep handy of the top risk areas that I find need to be addressed on all types of projects.  Then, I get the project team to uncover and identify others as an exercise prior to the kickoff.  If you will capture your risks at the beginning of the project and then continue to identify and update your register, you will find that you have a valuable list of risks to look out for on the next project.  Additionally, you will begin to have good mitigation strategies even before your next project begins.

In the near future, I will dig deeper on this subject and talk about monitoring and controlling risks and creating a risk mitigation plan. Your comments on risk identification and analysis will help other project managers meet their challenge.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site