Fear No Project Blog – Focusing on the Management Side of Projects

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.