When to give up

As almost everyone knows by now, I work with Software Projects That Suck and make them not suck.

But then there are the projects that can’t be made to Not Suck.

Most recently, I even made a little info-Episode on preventing your project from sucking by considering whether you need to do it at all before it even starts. The downside of that? By the time you realize your project might be one of those, you’re already fairly far into it. So the advice to not start isn’t useful. As The Smartest Guy I Know likes to say, “That ship has sailed.”

Suppose, as a business person who doesn’t normally deal with these things, you are already hip-deep in a software development project and it’s clearly gone off the rails. How do you get it back on track? That’s a long story. How do you know whether to try getting it back on track? That’s a short story.

The Short Story

A few principles:

• Sunk costs really are sunk. Forget about the money you’ve spent already. It’s gone.
• Be open to the possibility that the developer or development team you hired may not be solely at fault.
• Be willing to scale back or rethink the premises of the project.
• Go for value rather than fulfillment.

It is hard to know about giving up

You have to start by finding out why your project is such a mess, and there’s a good chance that nobody inside or close to the process knows, even if they think they know. It’s like the legend of the blind men describing an elephant; everyone thinks the part they immediately apprehend is a fair image of the whole, and it’s just not.

So the accounting people see costs out of control. Your production manager see that the line keeps getting shut down for reboots. Your lawyer sees that deadlines in the contract aren’t being met. The software contractors talk about something to do with interfaces and patterns before using words you don’t even know.

A few guidelines

Long story short, before doing anything else, you want to know whether the right choice is to try to finish the project, put it on hold, or kill it. Here are some guidelines.

• If your side has made open legal threats against the contractors, the relationship is shot. You really can’t continue with those contractors.
• If the contractors have made legal threats against your company, the relationship is probably shot but maybe recoverable. If they’re just complaining about not being paid, for heaven’s sake just pay them. This applies especially if the contract calls for “time and materials” billing. At the very least, send a non-aggressive letter listing the reasons why you’re withholding payment.
• If the contractors have been repeatedly recommending a certain approach or repeatedly telling you some part of the project is unrealistic, don’t be an idiot. Try it their way before giving up.
• If you are thinking about adding developers to the team at this late stage, I am here to tell you that never works. (I’m lying. It works so rarely and under such specific circumstances that… as far as you’re concerned, it never works.)
• Is there a way to tie the project off and call it done–as well as usable–with two thirds or half or even a quarter of the deliverable value in hand? Then do it. This outcome is available far more often than people seem to think. Sure, you might not get real-time inventory in transit, for example, but you might have gotten next-day inventory counts, and that’s almost as good. Bird in hand.
• Be honest with yourself. Has this thing turned toxic for you? Do you even still want it done?
• If you’ve gotten this far down the list, it’s because you decided that canceling and bringing on the lawyers is not a good option. If that’s the case, stop the finger-pointing. Schedule a problem-solving meeting immediately with the development team leadership. Ask them directly, and with an honest willingness to be surprised, a) what they feel is going wrong; b) what they think can be done to make the project succeed; and c) whether there’s a way to close up the code that’s been done so far and leave you with a useful, valuable, partly-completed project.

On that last point, I’ve found a very valuable planning concept–really before the whole Agile thing became popular–is to make sure your software is always working even when it’s not done. (By “always” I mean at the end of every couple of weeks of work, once you’ve gotten more than a token amount of development time in.) That allows both development and management to stop at any point and have something valuable to show for it.

So those are my thoughts on killing a software project. Any suggestions? Let’s jam in the comments. When do you know it’s time to give up? When have you regretted it?