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?
February 22, 2010 @ 10:44 am
It’s so critical to prove that your product is marketable through prototyping before spending huge amounts of cash on actually developing something. Lock yourself in an office with a stack of paper for a weekend, prototype the whole deal in low-fidelity prototypes, and then bounce it off smart people to get real feedback.
Why? To make the product real as quickly and cheaply as possible. Even though it’s just a stack of screen concepts, people get it. They will give you feedback.
That feedback tells you what to do. That may mean canning the project, or just feedback towards continuing.
The goal here is to gain direction, not affirmation. I’ve never gotten feedback that says “You’ve got this perfect, just keep going as is.” If you do get that, just press for feedback anyway.
Another awesome post.
Mark W. Schumann
February 22, 2010 @ 10:52 am
Direction, not affirmation. Value, not fulfillment. Same kind of thing.
You’re right, Josh. The key is that if you’re going to fail, get it out of the way as soon as you can–whether it’s a project for a particular client, or a product for a wider market. Don’t waste resources on things that either a) can’t possibly work; or b) aren’t worth it even if they do work.
February 22, 2010 @ 10:53 am
or c) Would work, but the market doesn’t want it.
February 22, 2010 @ 7:32 pm
“Be open to the possibility that the developer or development team you hired may not be solely at fault.”
Absolutely key … if the one giving the requirements is trying to cure cancer (which represents a production or solution that is hard+complex), it is going to take a strong developer or project manager to try and reign in the one asking for the new battery car that can go 500 miles on a charge and carry a deck worth of pressure treated wood from Home Depot.
I enjoy when time goes by and then the discussions surrounding “how come we have spent this much time and I don’t have a use-able product yet? I clearly told you what it needs to do, why doesn’t it do it?” … and by enjoy I mean loathe.
(Let me know if I can work in some additional mixed metaphors in my comments going forward)
Mark W. Schumann
February 23, 2010 @ 2:19 pm
Hah! You know it, John.
I’m working on an article now–actually more like a manifesto, as pretentious at that may sound–to explain why software development takes so long and costs so much, when it really is just a matter of making instructions.
Shifting requirements are part of the problem, but if you could magically prevent the shifting we would still have trouble.
I think it has more to do with the fact that requirements are necessarily analog in nature while implementations are always digital. There is no English-to-C++ translator. English is really good at conveying nuances and connotations. It’s really bad at conveying details in an unshakably specific manner.
For that you need Loglan. Guess what? Speaking Loglan is as hard as programming. You can’t win, at least not easily.
Oh, and Josh? I think your c) is a subset of my b).
February 23, 2010 @ 2:30 pm
Mark – Kinda a subset, but not really. Maybe I’m being pedantic.
There are plenty of things that the market would accept that aren’t worth creating.
I’ve heard people say that “People don’t always know what they need till we give it to them.” Bullshit, and that’s kinda my point here.
If someone is thirsty, they tell you want water. If someone tells you that they need a faster way to review new orders, they tell you. The fact that you, the developer, know what the customer needs without them telling you is just ego.
So, to phrase better:
c) Don’t waste resources on things that you think people will need.
I’m amazed at how many developers are the source of their own scope-creep issues… but that’s a whole ‘nother discussion.