“When things go wrong, don’t go with them.” — Elvis Presley, American singer.

“Don’t throw good money after bad.” — American folk saying.

As much as it goes against the grain for most of us, sometimes the most productive thing a manager can do is give up on a project.

Now, I’m not suggesting you throw in the towel as soon as the going gets a little tough; productive people never give up without a fight. But there may come a time when you hit a point of diminishing returns, when investing further resources in the product would just be wasteful. Remember Microsoft Bob, or Gerber’s attempt to create adult entrees? Both companies wisely dropped those products when they flopped.

Little Clues

As a manager, canceling failing projects may be one of your most important secondary responsibilities. But this begs the question: how do you recognize when a project hasn’t got a chance? After all, a project’s failure may still produce an unexpected success. Alexander Fleming discovered penicillin after a failed experiment with staphylococcus bacteria. 3M rejected the adhesive used on Post-It notes for general use because it wasn’t sticky enough.

But you need a benchmark to measure against, so for a standard business context, let’s define failure as something that:

a) Doesn’t work as intended;
b) Goes too far over-budget; and
c) Won’t (or can’t) be delivered on time.

Watch for these common indicators:

1. Poorly defined requirements. If you can’t get the project sponsors to take enough interest to clarify their requirements, then you’re in trouble from the start. A one-line requirements document that says something like, “We want an easy-to-use scoreboarding system” won’t cut it. You should prod the leaders or clients to tell you precisely what they need and keep asking until they do. If they never do, you might as well shut it down before the word Go, because you can’t guarantee you’ll ever hit the mark.

2. Unrealistic scheduling/budgeting. I know a professional editor who occasionally receives bid requests with requirements like, “I need my 400-page novel edited within two weeks for $500.” A decent edit for a 400-page novel takes at least three times that long and four times the proffered rate. Someone somewhere may take the project, but the writer won’t get quality work in return. Conversely, schedules that seem ridiculously long and lack deadlines risk the project falling by the wayside in favor of the urgent, while a budget that burns through money may doom a project to failure as well. Projects need realistic, well-defined schedules and budgets, with milestones for each.

3. Scope creep. When you receive a project, it should state clearly what you need to deliver and when. If the client keeps saying things like, “Hey, while you’re in there, can you add this too?” then you may suffer from scope creep. The project gets bigger and bigger, often without a corresponding budget or schedule increase. While we all want to accommodate the client and deliver more than they asked for, you can easily take this too far.

4. Bad attitude. Does your team think the project is a waste of time? Do you have trouble pinning down the client or your own manager because they don’t seem to care? Do the intended users seem uncommitted to the project, or actively hostile? Are you curiously ambivalent? If so, red alert!

5. High churn rate. You may think this one’s an offshoot of #4, but it ain’t necessarily so. Yes, sometimes people abandon ship because they hate a project, but whether that’s true or not, the real problem is that people who leave take their skills and knowledge with them. You then have to train someone new or redistribute the load to others. Either way, the project loses momentum and speed; up goes the cost, down goes the value.

6. Failures. You may discover that your creation doesn’t work for some reason, or just doesn’t work well enough. Suppose the accounting department has tasked your team to build a new database. Beta and acceptance testing might reveal problems you can’t reliably or economically repair. Or, you may discover halfway in that XYZ Corp’s brand new database works better for a lower cost. Or, technology may simply advance so fast in the interim that the project becomes out-of-date before its release. Tech companies like Research in Motion, Apple, and Android constantly duke it out in the courts over “patent infringements” that may simply have occurred because of parallel and uncorrelated product development.

The Sunk Cost Fallacy

Just because you’ve sunk a lot of time, effort, and cash into a project doesn’t mean you can’t unplug and walk away. In some cases you must, if only to avoid throwing good money after bad. So end it gracefully. Once I invested a couple thousand bucks with a web designer a colleague recommended. I found the company to be slow and unreliable, and I wasn’t impressed with the minimal work, so I cut my losses. Coordinate with the client or sponsors to determine the proper procedure for project cancellation. Then let the project team and other stakeholders know; return or release any remaining budget; wrap up basic tasks; and document the closure. Someday, someone may learn from your failure—and may even salvage something useful from it.