June 27, 2012 at 4:25 pm #165094
June 27, 2012 at 9:42 pm #165128
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.
June 28, 2012 at 1:52 pm #165126
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!
June 28, 2012 at 2:26 pm #165124
June 28, 2012 at 2:28 pm #165122
June 29, 2012 at 2:22 pm #165120
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.
July 1, 2012 at 9:44 pm #165118
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:
- You weren’t building the right thing from the start
- 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.
July 6, 2012 at 4:40 pm #165116
July 31, 2012 at 1:17 pm #165114
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.
July 31, 2012 at 1:18 pm #165112
I love this response. Thank you.
July 31, 2012 at 1:58 pm #165110
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
July 31, 2012 at 4:50 pm #165108
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.
July 31, 2012 at 5:02 pm #165106
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.
July 31, 2012 at 5:08 pm #165104
Donald – so true. And tied to #1 – what are realistic expectations?
July 31, 2012 at 5:15 pm #165102
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.
July 31, 2012 at 6:02 pm #165100
@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?
August 1, 2012 at 12:46 am #165098
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!
August 1, 2012 at 1:00 pm #165096
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.