Abandoning vs. Killing Projects

John Cook, wrote a lovely post, Peter Drucker and abandoning projects, explaining how Drucker talks about abandoning projects. (John, thanks, I will definitely be referencing Drucker in the PPM book.)

I haven't been using the word “abandon” when I describe stopping projects. I've been using the word “Kill” and the concepts of permanently stopping projects (killing them) and putting projects on the parking lot (stopping them for now). John actually says the words from a developer's perspective:

It can be a tremendous relief to abandon a project.

He's right. It is a huge relief to stop working on a project.

Here's why I've been using the word “kill” instead of abandon. I want people to make a conscious decision that this project is not worth continuing at all. (The three possible decisions are commit to; kill; or transform a project.) Abandoning feels more like we can just stop the project in whatever state it's in and walk away from it.

But I don't know people who can do that. Every time I've seen managers attempt to abandon projects, the technical staff want to wrap things up, or get them to a state where the project can be shelved and restarted again later. That's why I separate the ideas of stopping a project for now (and putting the project on the parking lot) and killing the project.

Here's an example of why I feel so strongly about this. I was working for a small company as a developer many years ago. We were not making enough money. Management stopped a project “for a while” where the duration was indeterminate. Over lunch, I asked my boss when we would start it back up again. He said, “Never, with any luck.”

But that's not what was communicated to the technical staff. One developer said, “Well, management has abandoned this project. But I'm not. I'm going to save this project.” Ouch, not what management wanted and not what the company needed. The company needed us all on a project that could actually make money, not the money pit. But the other fellow thought that management had abandoned the project, not made a decision to stop it. If our management had considered the killing or parking of projects, maybe my colleague would not have continued working on a project that had no future and was diminishing the ability of the company to make money. We would have been in better shape if we had killed that project.

Maybe kill is too strong a word.  But if we want to stop a project permanently, I do want to kill it. I don't want people doing skunk work on it. I don't want more investigation. I do want it killed. For me, abandon isn't a strong-enough word.

And, if we can't sufficiently fund this project now, I want to put the project on the parking lot, or somewhere in the unstaffed work list.

I hope you chime in with your reaction about abandon vs. kill.

19 thoughts on “Abandoning vs. Killing Projects”

  1. Pingback: Peter Drucker and abandoning projects — The Endeavour

  2. Pingback: Managing Product Development » Abandoning vs. Killing Projects — ana ulin .org

  3. I absolutely agree. I have a number of pet projects that are unhappy affairs. Management says they are good projects, but then doesn’t give me the time or resources to make them successful. I walk away frustrated that their “yes” was really a “no”. No one like their hopes undermined like that.

  4. Probably a good idea for emotional and mental stress reduction, too. “Abandoned” projects pile up and continue to exist. Over time their accumulation adds to the unspoken weight of incompleteness and insecurity and can probably bring a group down. Killed projects clean the mind once and for all and allow a group to focus.

  5. Agree completely. Even from a SysAdmin perspective, I constantly have a list of outstanding requests for investigation of one product or another where Management has no serious intention of actually funding the results. I believe it generally comes back to a miscommunication of actual direction which is poorly handled and clarification by ‘Killing’ a project outright would free up a lot of time.

  6. I would encourage an alternative: put the project up on github.com and release it as open source.

    Committed engineers can work on it after hours, free-software hackers can join in, and the company doesn’t spend another dime on it.

    There are a few cases where you wouldn’t want to do this, but two huge potential gains:

    * When projects are killed, it’s an enormous morale-buster; engineers feel that months (or years!) of their hard work has been for naught

    * You give back to the software “ecosystem” — maybe that project is a dead-end for you, but there is a considerable gap between “not profitable” and “useless”.

    This might sound implausible, but I know of multiple projects at my last job (with a now-defunct company) that meet these criteria.

    These tools (e.g. a messaging framework, a widget syndication platform and a templating system) were killed because they were not profitable. However, all could be a real boon to teams struggling with the same problem.

    Continuing in-house development or halting in-house development is a false dichotomy. Free the code!

  7. This is great food for thought. I tend to agree with you that kill is better than abandon. But sometimes I wonder if it’s good to let things rest a bit. It always amazes me how ideas come out of nowhere. Ideas that put (dead) projects into a different perspective. But new thoughts need time. I’ve heard of so many projects that turned out completely different from what people were originally thinking. Like Flickr. Like Blogger.

  8. You can’t “put it on github” when doing so is theft. And when you’re not the owner, taking it and giving it away is not legal.

    Also, at best, if you persuade the company to give you unpaid overtime witht he promise that they’ll take the fruit of your labor and not pay you for it if it makes them more money, well, that’s fine dedication but probably explains why suits get the money and coders get shafted.

  9. My sentiments are similar. Some times a management really wants to kill a project in the sense of wanting to deny anyone else the possibility of making it succeed. While I might understand that about competitors, even if I disagree with the decision, I don’t understand why the stuff and ideas — and intellectual property — of the project aren’t “deeded” to the employees of the company to do with what they would like, on their own time. (Whether or not there exists “their own time” is another unhealthy matter.) And, failing all else, the stuff of the project — including more than the code — should be placed in the open, so some communal good can come of it.

  10. Wow, I never thought of it this way. Kill sounds ugly but sometimes death is preferable to the endless anguish of the alternative -a vegetative state. It does suck up life support resources however minimal. The whole concept of active death is akin to deciding to not throw good money after bad. I think this analogy is more vivid and likely to make an impact with me and my clients.

    Abandon/death is passive; kill is proactive (we didn’t say murder!). I’m guilty of having abandoned projects without having made a concious decision to do so. Officially killing a project means to actively assume the responsibility of one’s role in its failure.

  11. And the project can be as simple as a blog where you’d rather actively stop production rather than neglect it and let it atrophy. A difficult decision, but a conscious and definitive one. (I like this article ’cause it’s exactly the line of thinking I had when I chose the word “kill” for the last post on my blog).

  12. @Bob
    While agree with you that the shell could live on for someone else to raise from the ashes. It also leads to the sourceforge problem where there is a gigantic graveyard of projects in a dubious state.

    There needs to be a graveyard, so they really can rest in peace.

    On a sidenote a buddy of mine and I were talking that if a project maintainer doesn’t login to their sourceforge site in 1.1 years it goes into purgatory.

  13. You can’t “put it on github” when doing so is theft. And when you’re not the owner, taking it and giving it away is not legal.

    I was not suggesting that some coder go rogue like that. I was speaking to the company’s leadership — i.e. the same ones who’d make the kill/abandon call.

    And who the heck is talking about unpaid overtime? Lots of people work on worthwhile projects like Firefox, Linux and Ruby on Rails, etc. and it’s not because they’re saps. Frankly, they’re some of the smartest people in our industry.

  14. Oh, and it’s worth noting that Ruby on Rails was originally an internal project at 37Signals, before they decided to open-source it.

    This isn’t without precedent — taking software that is integral to a company’s business and “putting it on github”. By doing so, they got the labor of hundreds of really smart coders (who, in turn, benefited by having access to such a useful tool that they were free to improve).

  15. Interesting article.
    But is it worth killing the only project you have before coming up with the idea for a new one, that will supposedly be more fulfilling and profitable?

  16. Johanna, how about using the word ‘abandoned’ for projects that are “finished”?

    “A poem is never finished, only abandoned” – Paul Valery

  17. Hello eveyone, I’m new to the forum
    I look forward to sharing and exchanging information with everyone!
    I have been watching the forum for a while and I just decided to join and participate!
    See ya…

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: