Evaluating When to Kill a Project: What Criteria Do You Use?

Apr 15, 2014
14 Min Read

It happens to all of us. Sometimes, the right way to fix a project is to cancel it. Making the decision to do so, though, has to be more than a gut response.

Perhaps the project team thought this was a good idea, sure to take off… but, well, it didn’t work out that way. Or someone in Management “suggested” your group take this on – but nobody took a critical item into account. Or the project seems to be stalled at “80% done” forever.

Whatever the reason – at some point, you have to decide whether to keep plugging along, or to pull the plug.

You might make that decision on your own (especially if the project was wholly your idea), or it might be addressed in a team meeting. However it’s done, it rarely is an easy call. You’re invested in the work that’s already been accomplished, which means it’s tempting to make a kill-or-not call on emotional grounds rather than business terms.

I’m not speaking here about the point where you know a project should be killed, or describing the signs that your project is in trouble (such as when a third-party agency responsible for implementation starts overusing the word “perhaps” in e-mail messages). In that case, you already know that the project should be shut down… even if you don’t have the political power or authority to turn off its lights.

Rather, I aim to help you calibrate the issues to consider in the “Go/No-Go” decision process.

First, do your best to look at the situation objectively. “This can be a
challenge, especially if you were personally involved in its creation,” points out David Bakke, financial expert at Money Crashers. “Once
 you take emotion out of the equation, it becomes a lot easier to know when
to kill one. For that reason, I've never had any regrets about killing a
 project. I always knew that it was time for the project to go.”

If you cannot set aside your own biases, or you suspect that others have too much emotional involvement (It’s my babyyyyyy!), bring in a dispassionate outsider to moderate the discussion and to ensure that each viewpoint is considered. That’s how management consultants make a living.

Can the project be done at all?

Many of the people I spoke with said something like this: “I evaluate whether my original project statement will ever be achievable. If I determine that the project cannot meet my goals and objectives, we stop it.”

That’s all well and good as a general guideline, but it’s not always easy to determine if those goals can be achieved. Here’s some of the questions you can ask:

Do you lack the technology to get the work done? For example, if the hardware you build on is too slow to meet performance requirements, that can be a deal-killer even if everything else is hunky-dory.

Have you missed an important event? For example, if a competitor releases a new product that’s better than yours, while your project is still in development, you need confidence that it’s worthwhile to continue.

Do you lack the know-how? Sometimes, your team can acquire the knowledge it needs, such as hiring a subject matter expert (SME), or simply send staff to training. But if your SME leaves the company, or himself is a barrier to success, it may sound the project’s death knell.

Have the project goals gotten away from you? If your project suffers from scope creep – more and more features keep being added – then at some point you have to say, “Can I get this done by the due date? For the dollar amount we agreed to?” If the answer is No, then you need to revisit what can be accomplished within reasonable parameters, and decide if that’s enough.

If the project scope, objective, and goals were never clearly defined at the outset, that's a good reason
to scrap it and start over. Or look at the exit clause in the contract (you do have one?) or chalk it up to “Yet Another Learning Experience.”

Are you dependent upon resources that are outside your control? If so, can you get them under control? One person told me about a failed project where the system relied on third parties providing data, but they weren't particularly interested in providing it. The project went from “We've got time to discuss the data format with them” through “We can still launch on target if they provide the data in this format” to “We are ignoring the Terms and Conditions and trying to scrape the data from their websites” before it was canned.

Is it just the wrong time? Occasionally the project idea is a good one, but you lack the skill or wherewithal to do the job right… for the moment. Some projects do have urgency (do it now, or don’t bother) but others can be put on the back burner or postponed. “Sometimes you just shove it in a drawer and wait for inspiration to breathe new life into it,” says SF author C.J. Cherryh, who’s won multiple Hugo awards.

But, she cautions: “Never destroy it – for fear it will achieve holy sanctity of 'might-have-been' in your memory. Being able to look at it and say, ‘Nope, there was no hope for this one’ is healthy.”

How far behind are you on money and deadlines? As Money Crashers’ Bakke says, “A project can be behind schedule or over budget, but if it's both, that's a
 good sign it needs to be killed.” If there's no tracking system in place to
 monitor progress and key performance indicators, you might want to go back
to the drawing board as well. If there's no support from superiors (or there no longer is), it should also be killed.

Beware distractions.

One common decision criterion is “How much have we invested in this turkey, already?” Naturally, you want to balance the cost of project completion with the benefits you expect the project to yield. It’s tempting to look at the money already spent, and consider what it means to write off all sunk costs.

But, says consultant Scott Ambler, sunk costs shouldn't be an issue. “Once they're sunk they're sunk,” he says. “The real issue, from a financial point of view, is whether the total value that you'll get from continuing is greater than the total cost of doing so.”

For most businesses, the “Should we kill this project?” decision is very political. That’s not necessarily a bad thing. “They relate more to whether the key participants in the project are trusted by the senior executives of the company,” says Harwell Thrasher, author of the book Boiling the IT Frog: How to Make Your Business Information Technology Wildly Successful Without Having to Learn Anything Technical. Certainly you yourself want to earn trust, and have Management believe in you. But then the real world sets in: “Projects done by trusted people are almost never killed, until finally the senior executives themselves are replaced, and their replacements don’t have the trust in the project participants that the previous executives had,” says Thrasher.

“In theory, of course, the trust comes from previous project success, but it’s usually more complicated than that,” Thrasher adds. “And it’s too easy to trust someone in a new project based on previous success in projects that aren’t similar enough to warrant the trust.”

Lay the cards on the table. Or the wall.

So how do you put all this together in one critical meeting? Marliese Bartz, an Operations Black Belt, has a useful process that helps everyone see the situation – literally. “I first collect pertinent facts about the project like how much it's costing, how many people/groups are impacted, and the expected time needed to finish it. Then, I either collect or create solid (not overstated) analyses of what and how much the project is expected to save/improve. With these data, I lead stakeholders through the simplest of analyses: a Benefit versus Effort Matrix.”

Bartz uses a two-axis graph to rank the remaining items to be implemented based on the benefits they'll achieve (e.g. dollars saved, time saved, or customer satisfaction) and the efforts required to achieve them (money, time, or risk). “Inversely, a benefit could be risk avoidance and an effort could be the loss of work already invested in the project;  the definition of axes depends on the goals of the stakeholders,” she adds. Making a matrix like this is quick and dirty, but factual – and it helps people focus on the non-emotional.

Then, using a whiteboard and/or Sticky Notes, Bartz visually ranks the remaining implementation items into four quadrants: Low Benefit/Low Effort, Low Benefit/High Effort, High Benefit/Low Effort, or High Benefit/High Effort. Starting in the High Benefit/Low Effort quadrant and ending in the Low Benefit/High Effort quadrant, she and her clients re-prioritize the items needed to get the project over the finish line.

“With this new visual analysis of the project, stakeholders will many times choose to scale back parts of the project rather than scrap it all together,” Bartz says. “In my experience, starting a project implementation with a Benefit verses Effort Matrix is the most beneficial. But, as I use it with nearly every single client, it proves to be a useful analysis tool anytime a major decision is needed.”

Don’t see yourself or your team as a failure if you’re tempted to even ask, “Should we kill this project?” In fact, it may be a good sign of project health, because it means you’re paying attention to warning signs. Ambler says, “In Disciplined Agile Delivery we recommend that you make a go-forward strategy decision every so often. Choices include continuing on with the current strategy, pivoting in a different direction, and cancelling the project. Each option has advantages and disadvantages. My 2007 project success survey found that only 41% of people believed that cancelling a troubled project is a sign of success.”



Recomended Posts