Quitting the Project
“You’ve got to know when to hold ’em
Know when to fold ’em
Know when to walk away
And know when to run.”
Kenny Rogers – “The Gambler”
“The Gambler” reminds us that in poker, folding is part of the game. It allows us to take risks, knowing that if things don’t take a positive turn, we can always abandon the pursuit, although as in poker our project might be seduced by sunk costs – irreversible expenditure.
In 1996 there was a fatal attempt to climb Everest, when five people died on the mountain unwilling to heed the mandatory turnaround time and pull the plug on an expedition that faced deteriorating conditions. How do projects continue in the face of evidence that the plug should have been pulled? How can we make sense of this compulsion to continue? While there’s no single root cause, some factors include executive pressure, lack of contingency planning, organisational reward and no quitters culture, and the sunk cost trap.
There are two main reasons for closing a project. The first, and most common, is that all project work has been completed and our project sponsor and client have confirmed that the final product meets their requirements. The second reason for closing our project is when the decision has been made to halt the project prematurely – project extinction. Not every project makes its way to the finish line, and not every project should. As PMs we may find ourselves, at some point in our career, running a project that has little or no chance of success.
In this situation we might arrange a workshop for those involved at which we highlight the positives from the project so far, learn from our mistakes, get everyone on-board with PM plan version 2 and move forward with renewed confidence. However, without re-writing the business case, slimming down the requirements’ list, extending the time frame or increasing the budget, sometimes it might be better to stop our project or recommend it be stopped.
Nobody usually thinks about stopping a project at the time of its conception when big ideas are being thrown around and plans are being made for success. There is often unbounded enthusiasm. However, since too few unsatisfactory projects aren’t cancelled, this short chapter devoted to early closure is much warranted. Some sponsors may believe that it’s a lot easier to let the project just roll on and have someone else take the blame if, in the event, adequate benefits fail to materialise. My view is that organisations need to get much tougher about terminating unrecoverable projects as early as possible in order to free-up resources, rather than prop up failures.
We might legitimately abandon our project mid-course for a variety of reasons – the product is no longer needed or has become obsolete, the completion date can’t now be achieved, costs are excessive, withdrawal of funding and other resources, benefits are now unachievable, the needed expertise is unavailable, scope creep is rampant, project priorities have changed, the project doesn’t comply with new legislation, market circumstances have changed, or someone else has produced a better solution or more competitive product. We shouldn’t expect all our projects to succeed. However, when we encounter these sorts of scenarios, our emotional response is often to feel that we must continue because of how much we’ve already put into the project. It’s about throwing good money after bad. In the financial world it’s called “the sunk-cost fallacy.”
When project sponsors consider aborting a project, they may view the past investment in the project as wasted resources and this aversion to waste leads them to continue investment in the project in the hope of using rather than losing the investment to date. Therefore, sponsors may pursue unsuccessful project investments, throwing good money after bad. Also, project sponsors have been known to continue a losing project in order to avoid or delay their own or their organisation’s reputation loss. Sending a message that project termination threatens careers may tempt sponsors and PMs to continue projects that should die. However, failure to stop death-march projects is a failure of governance.
Most organisations value persistence and perseverance. We may hear business leaders exhort their PMs to demonstrate a “can-do, never give up” attitude. This “no one likes a quitter” rhetoric means that individuals are discouraged from admitting their mistakes. People may not report or cut their losses out of fear of being blamed for the failure. But, perhaps we should strive to create an organisational culture that makes admitting and learning from mistakes as valued as persistence and perseverance.
Sponsors and PMs launching a project might do well to consult with a skeptic along with the believers from the outset, paying particular attention to those who will be directly involved in making decisions. De Bono suggests that every project team would benefit from a “black hat” – a devil’s advocate who identifies project investment difficulties and dangers.
The original true believer is the project champion, who often holds an unyielding conviction, based, often as not, on a hunch rather than on strong evidence that the project will succeed. While the importance of project champions is well documented, the value of an exit champion or someone who recommends pulling the plug on a project before it becomes a money sink, hasn’t generally been appreciated. Exit champions would need to be fearless people, willing to put their reputations on the line, and even face the likelihood of exclusion from the camaraderie of the project team.
The difference in return between a chosen project and one that is passed up is opportunity cost. Say we invest in a project and it returns a paltry 2% over the year and in making this investment we gave up the same risk opportunity for another investment yielding 6%, our opportunity cost is then 4% (ie, 6% – 2%). By sticking to the current project, we forsake other possible uses of the time, material, money and human resources. Imagine what we could do with the money and other resources freed up earlier from failed projects. However, sunk costs should not be considered when making the decision to continue investing in an on-going project, since we cannot recover sunk costs.
Of course, a strongly held conviction and the refusal to let inevitable setbacks undermine our project are often just what we need to get a project up and running. But as our project moves forward, faith can blind us to increasingly negative results. Fortunately, catastrophic trouble rarely happens all at once and usually develops over time. This provides us with ample opportunity to act, but we have to be paying attention. It’s very easy, and all too common, for us busy PMs to get too close to our project and not see the signs of trouble such as:
- Insufficient planning.
- No formal PM methodology.
- Progress is not going as planned.
- Major milestones are being missed on a frequent basis.
- Interim products are not performing as expected.
- Scope creep is rampant.
- Our project team is under-performing and their morale is low.
- Lack of effective engagement with project stakeholders.
- Senior management interest in the project has diminished.
- The project’s priority has been downgraded.
- Status reports are continually negative, reporting excessive variances.
- The project schedule and completion date changes every day.
- Project resources are insufficient, under-skilled and constantly changing.
- No one can find the sponsor, business case or requirements document.
- Few of the project team show up for status meetings.
- Poor communications and no formal communication plan is in place.
- Market conditions have changed, such that the ROI will not now be met.
- The competition has launched a better product.
- The final product will become obsolete earlier than expected.
- We may not be able to provide on-going support for the product.
- There are technical difficulties beyond our abilities to rectify.
- Key resources have left the project.
- The project is experiencing a significant cash flow problem.
- Stakeholders’ attitudes are poor, with persistent conflicts and disagreements.
If our project is stopped prematurely, best we adopt some key end-of-project best practices that include:
- Meeting with stakeholders to review what can be salvaged from the work in progress. There may be some benefits we don’t know about.
- Staying away from blame is a good idea. Blame is generally useless and focusing on who to blame instead of what to do can rob us of any opportunity to get some positive result out of this otherwise unhappy event.
- Having a wrap-up meeting to close off the project and thank all the team members for their participation. Make sure that any lessons learned are communicated. Some useful questions might be:
- – What if the requirements had been right when planning started?
- – What if the schedule had been created before the end date was decided?
- – What if risks had been mitigated instead of ignored or accepted?
- Making sure there is a final accounting of the project so the true cost can be calculated. And don’t forget sub-contractors. Make sure all their outstanding invoices are promptly resolved.
- Rewarding the team, perhaps with a dinner or a least a letter of thanks, even when our project closes on a sour note, will show that even though the project may have failed, their efforts were recognised.
Yet, early closure isn’t all bad news. As part of our review, there may be some returns on the project’s investment to date that are worth recognition:
- The first and most obvious benefit is the new-found availability of the project-team members. If they aren’t now working on our project, they will immediately become available for other work.
- Next is salvage. It’s sometimes surprising how much work-in-progress can be adapted to other purposes. In some cases, there can be a useful product or recoverable stuff that is immediately available for other projects. Throwing out everything that has been accomplished is usually a mistake.
- A soft benefit is 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 to be feared. Also, the knowledge that the end of the project doesn’t mean the end of their employment is usually welcome news for those staff that can now work on something more productive.
We must periodically re-evaluate the anticipated ROI on our project. All our projects must have a business case that argues the rationale for the investment. However, the business case must be regarded as a “living document” that is reviewed and updated periodically as new data comes to hand and circumstances change. If the rationale for the project has diminished, it might be time to stop work for a comprehensive review, but to do so is not usually our call as PMs. This is the project sponsor’s and senior management’s decision, although it might be our recommendation. Often the reasons for a failed project can be traced back to an overly optimistic or outdated business case.
This “kill” decision needs good information, careful analysis, clear thinking and courage to act on the available data. Unfortunately, this type of decision is not always based on rational thinking – emotions and innate biases may have a major effect. There is no magic bullet that makes it easy to decide when to stop a project. It takes courage to admit that mistakes were made and that lessons can be learned so the same mistakes are not repeated. Stopping projects early may be a hard decision, but when we are sure that the project is failing, stopping sooner rather than later is always the better answer.
PMs are usually the primary whistleblowers on projects that will no longer achieve their promised intentions, regardless of the money, resources, and time that have been invested to date. But when is the point reached that it’s better to stop a project than to continue? What are the criteria we should use to assess and weigh against continuing? Who are the decision-makers? I suggest that these factors should be decided before our project commences. It’s important to set limits on how far a project is able to go before it’s recognised as a lost cause. The inability to admit defeat has the potential to create a lot of headaches.
Having to close our project earlier than planned can be a big disappointment and source of concern for PMs. On the other hand, premature closure might be considered as a learning opportunity and perhaps a chance to salvage some work. Perhaps the only real failures are projects from which nothing is learned. Of course, learning doesn’t happen from failure itself, but rather from analysing the failure, and making changes where appropriate to avoid future failures.