When and how to kill a project?

Home Forums Program and Project Management When and how to kill a project?

This topic contains 17 replies, has 11 voices, and was last updated by  Josh Nankivel 9 years, 1 month ago.

  • Author
  • #165094

    Bill Brantley

    How do you know when it is time to kill a project? What performance measures do you use to make the decision? Or do you go with your instincts? What is the process you use to put a project out of everyone’s misery?

  • #165128

    Josh Nankivel

    I think it’s about ROI and trying to not get hung up by sunk costs when making the decision.

    Return in ROI can be dollars, but it can also be KPIs of how much value you are producing.

    If people and resources can produce twice the ROI on a different project, why keep them working on one that has a lesser or even negative ROI? You do have to consider the fact that you’ll never get any ROI at all if you never finish anything.

    Going with your ‘gut’ is a really bad idea in my opinion. You’d better have a damn good reason and be able to justify it.

  • #165126

    Vanessa Vogel

    For me as a graphic designer there’s always more that can be done. I can easily look back at existing projects and think of minor details I would have changed or added. I find myself wanting to fine tune projects weeks after their deadline. But there are deadlines for a reason and projects have to be done on a timed fashion. So while I could work on a project weeks after its deadline, I have to tell myself it’s finished, it’s good and now onto the next one!

  • #165124

    Bill Brantley

    @Josh: Thanks for your response. I feel obligated to ask how my questions would apply to agile projects.

  • #165122

    Bill Brantley

    @Vanessa: Your response reminds me of Steve Jobs observation that great artists ship.

  • #165120

    Corey McCarren

    When the data says it’s not working. There is some gut instinct involved also, it’s easy to try and think “but maybe it’ll start gaining traction tomorrow,” but it gets to a point where your gut tells you that isn’t the case.

  • #165118

    Josh Nankivel

    The same as a waterfall project I think, although I think the nature of doing Agile (Or APF 🙂 makes it less likely that you’ll need to kill a project, because your direction should be changing over time as the customer needs change. The 2 biggest reasons projects SHOULD be killed in my opinion:

    1. You weren’t building the right thing from the start
    2. You didn’t change with the customer needs and end up building the wrong thing

    In other words, I think it has almost everything to do with how engaged you are with the customer and how well you understand their needs.

    With any method being used to execute a project though, things can go wrong and regardless of the methodology it can come time to kill it. Just because a project is “Agile” doesn’t mean it’s being run well either, there are no silver bullets.

  • #165116

    Allison Primack

    Here is a response we received on GovLoop’s Facebook:

    Enterprise Content Management Systems – OPIN We compare the current project to the original schedule, budget, resources to determine its current state. Allows you to quickly find problems and solve before a project goes beyond repair.

  • #165114

    Priscilla Estes

    This is a good question. I would like to know the answers, as I have 2 projects that I am working on and they were given by my supervisor. I would like to know the answer as my supervisor seems to have no interest in the project being completed. It saddens me that the hard work I am putting into the project bears no interest to the one who gave it. I was promised a finished product, presented one and not there is silence.

  • #165112

    Priscilla Estes

    I love this response. Thank you.

  • #165110

    Bill Brantley

    I would recommend Yourdon’s book on Death March projects. He is the expert on surviving a bad project. http://www.zdnet.com/blog/projectfailures/managing-death-march-projects/7401

  • #165108

    Brian Dowling

    This seems to be one of the biggest obstacles, particularly for smaller local governments because often so much has been invested in terms of both money and egos. It is also often lower level staff that sees the problems first and needs to tell the higher ups, hey guys you goofed. If a politician has skin in the game, all the worse.

  • #165106

    Donald Bauer

    Now, and as usual, the “elephant in the room” is being ignored. The PRIMARY reason most every project fails is due to communication.

    1. Failure to communicate expectations (technical communication)

    2. Failure to communicate to the organization the benefits of the outcome (marketing communication)

    3. Failure to be brutally honest with those above and below (management/leadership communication)

    4. Failure to seek assistance when issues arise from 1,2 & 3 above.(SOS communication)

    Couple that with the lack of investment by stakeholders (e.g. failing to monitor progress but act surprised when the end product fails to meet their “invisible” expectations) and Generic PMs with no domain expertise (you know who you are, PMP and here we go!) lead to predictable outcomes.

    Project management is give and take, yet in most cases, it is a “take” scenario with no quarter given for the myriad of unexpected issues that arise. If anyone builds in realistic management reserve, they are accused of “padding” the schedule.

  • #165104

    Steve Ressler

    Donald – so true. And tied to #1 – what are realistic expectations?

  • #165102

    Priscilla Estes


    Your 4 points is exactly what is happening with this project. Getting management to see it while it is important to the projects success is the struggle in my office. Management waiting for the need to display it to get brownie points is 2 months too late.

  • #165100

    Bill Brantley

    @Donald – I agree that poor communication is the reason projects fail. What this discussion is about is what to do when the project has failed and you, as the project manager, need to extricate yourself from the dead project without damaging your organization and your career. Do you have any thoughts on that topic?

  • #165098

    Jo Youngblood

    Well.. I work in the research arena so there is not always a clear map of what should be done to accomplish the objective. It’s not uncommon that we’re told by a sponsor “I’d like to accomplish X” and X has never been done before. It’s our job to put together a strategic plan for attempting to accomplish X. So my point about all this is that you need to distinguish between a project that results in a failure – as in this methodology does not accomplish X- and a failed project. Failure to reject the null hypothesis still answers the research question.

    So given that when do you kill a project? When you can no longer anticipate being able to respond to the directive of the project or the resources consumed to answer that directive are more than the sponsor is willing to bear. Otherwise keep going. If they’re willing to float the boat and you still think you can chart a course then by all means sail on!

  • #165096

    Lindsey Tepe

    In addition to looking at the sunk costs, I’ve always found it helpful to consider the opportunity costs of continuing with a project that clearly isn’t working or gaining traction.

    When I take a step back and look at not only what I’m doing, but what I could be doing if I freed up some resources by cutting a project, it gives me a clearer idea as to where I should be directing my efforts.

You must be logged in to reply to this topic.