When does a project need to die?
I notice things that are broken. I often see people working on projects that have gone on so long, that the project is invalid. Time and money keeps being poured into the project, but there is no end insight. In the past I had to endure a company working on a project from 2004-2009 that did not launch until 2009, and the software was still based-on a 2004 base. Sad. Annoying. Everyone hated it when it was introduced.
In the last year I witnessed a company selling software to schools based-on Microsoft Silverlight in spite of it being canceled by Microsoft (http://www.neowin.net/news/microsoft-shuts-down-silverlightnet-wont-talk-about-future-updates) . When schools buy solutions like this, they are buying something that is basically dead and frozen in time.
Being personally connected to projects is a mistake many people, including myself. The focus should always be to provide support and opportunities for teaching and learning, not to achieve a personal goal.
Keeping it simple a project needs to die if:
- There is no leadership or people interested in being project leaders.
- The support from the community is not present or they have a negative view of the solution.
- New solutions are available and are going to be more affordable over a 5 year period.
- The original plan used an outdated technology or core resource that has been deprecated.
- Errors and problems are taking more than 30% of the original development time to fix.
The 5th item might not sit well for many people. Consider the math. Ifyou have put one year into a project and the existing problems will take more than 4 months to fix, you need to consider that implementing a new solution might be faster, and cost the same as wasting time and money on something that is plagued with problems.
Conversely if you have only worked 30 days on a project, then putting an extra 9 days into it, is justifiable. Keep the logic reasonable and the 30% ratio will work.
Canceling and/or quitting things has a bad connotation. However remember, projects are made of ideas, and the process of working on a project creates new ideas and experiences for the future. Somethings may seem like an L now but in the future they end up being a W. Play the long game and keep the focus on teaching and learning.
2 thoughts on “When Does a Project Need to Die?”
More of us probably need to go through the process of project management certification. I have considered it a few times, I may look into it more as you seem to be a very sensible person :).
This post is like music to my ears. When I became certified as a project manager (and later when I learned about ITIL) two industry-accepted ideas stuck in my head:
1. Every project needs to have continued business justification. This is from PRINCE2, and speaks directly to your excellent point about when it is time to let a project die. That “continued business justification” is a core principal in PRINCE2 is one of the things that attracted me to it. In my experience, thought, many projects are started without a clear understanding of the benefits.
2. In ITIL, we also talk about retiring services. So there is a catalog of services IT offers for schools, and some are “in development”, some are “operational” and some are in “retirement”. I don’t always do a good job of advertising retired services, but saying to my school community “we no longer support XYZ” is valuable.
Great post and good thoughts again.