“When things go wrong, don’t go with them.” — Elvis Presley, American singer
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 baby food-maker Gerber’s attempt to create adult entrees? Both companies wisely dropped those products when they flopped.
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. And 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:
Watch for these common indicators:
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.
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.
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.
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!
You may think this one’s an offshoot of No. 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.
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.
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.
I once 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 maybe they may even salvage something useful from it.
This was originally published on Laura Stack’s The Productivity Pro blog.
