When To Stop a Project

March 2, 2012 | Author: PM Hut | Filed under: Project Management Guides

When To Stop a Project
By Paul Slater

The decision on whether to stop a project before it has time to deliver is an extremely difficult and emotive one for most project professionals. The pressure to keep going because success is “just around the corner” can be really strong yet there are many examples of big projects that were kept alive only to be killed off later than they perhaps ought to have been. Of course in the larger projects and programs such decisions often get taken out of the Project Manager’s hands and become extremely political – sometimes literally so in large scale public sector projects.

So why is it that projects need to be stopped before their time or at least the consideration made to stop them?

  • Outcomes No Longer Required

    It seems strange but there will be occasions on all types of projects when after a period of time it dawns on everyone that whatever the project was meant to deliver, it’s no longer needed. Far better to stop the project at this point with associated sunk costs that letting it drag on to incur even further unnecessary costs.

    But who is to say that the project won’t be able to deliver what was intended? Clearly this has to be a grown-up conversation between Project Manager and Sponsor/Client plus any other interested parties. Remember, for larger (and especially large public sector) projects there will be many interested parties, some of whom may only come out of the woodwork once the project hits difficulties.

  • Timescales Can’t Be Achieved

    Providing a project is being well managed and progress monitored sufficiently well it ought to be straightforward to gauge when a project is likely to over-run. Agreed tolerances aside, questions need to be asked as early as possible as to whether the project can be brought back on-time by looking again at resourcing and scheduling. The question as to whether it really matters whether the project completes later than planned may well be asked. Even if the answer to this is that the delay is not an issue (rare to be honest) accepting a slippage can build in an acceptance of delays into the culture of the team.

  • Cannot Keep Within Budget

    Tracking costs and estimated future costs can often take higher precedence than timescales in projects probably because people more readily relate to money as a way of quantifying success or failure. Just as lack of cash-flow is the biggest killer of companies the worst thing a project can have is a lack of money when it is most needed. Having to ask for more money than was originally anticipated is equally damaging and potentially fatal for any project. Again, provided the mechanisms are in place to keep track of expenditure against the plan, money issues ought to be flagged very quickly allowing informed decisions to be made on whether to increase investment or to stop the project.

  • Technical Requirements Unachievable

    Projects with developmental or research aspects to them carry the risk from the start of not being able to deliver as anticipated. Complex R&D projects and those at the leading edge of technology (many military projects) have this characteristic so they need to have reviews planned in that look at how far they are progressing from a technological perspective as well as against traditional timescales and cost. The judgment call as to whether the technical requirements cannot ultimately be achieved is just that, a judgment call, but one that needs to be informed by the routine schedule and cost parameters.

    More time and more money may well solve the problems but can that be allowed to happen given that there is never a guarantee of success. It’s in these circumstances that alternatives need to be looked if there is still an enduring need to achieve a particular outcome.

  • Lacking Expertise To Deliver

    This has nothing to do with a lack of project management expertize, rather it is about having the requisite domain relevant technical expertize to deliver a successful project. Yes, expertize can be brought in (at an increase in project cost) but there may be an extension to the time taken due to a myriad of difficulties involved in hiring the right people. Of course, once the new people join the team they will take some time to get up-to-speed with what the project is about – even the very best people take some time.

  • Sponsor Changes Their Mind

    Sad but true, this can and does happen. Whether the Sponsor (and ultimate funder) of the project is internal or external to the project organization a change of mind ought not to come as a surprise providing regular contact is kept with the Sponsor. The Sponsor is the project’s key stakeholder so maintaining open communications with them will enable the project to remain aware of subtle changes of emphasis or expectations over time and manage these changes accordingly.

    Should, however, the Sponsor decide to pull-the-plug on the project for whatever reason then they need to be made aware of the implications in doing so. There will be incurred costs which have to be accounted for internally or via contracts and the closing down of the project, depending on what it is, may well be a project in its own right.

So, in summary, the decision to stop a project early can happen for a variety of reasons, but what is important is that the information that is used to make such a decision is as accurate as possible.

Paul Slater owns Mushcado Consulting and is based in Gloucestershire, United Kingdom. He offers consulting services to private and public sector businesses and specialise in facilitating change, reviewing projects and delivering training that really makes a difference.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories