Recently Internet guru Seth Godin blogged about “Halfway Projects”: you can get value from eating half of a pear, but half a canoe is worth less than no canoe at all. I like that. It’s a great metaphor for project management, where quitting a project just before the finish line doesn’t deliver any of its value—but leaves you with all of the costs.
Now, I misremembered Godin’s example a bit – what he actually said was “half a pear might deliver 85% of its value”. But the principle is sound: half a battery charge might let you do 85% of your work … but half a parachute is definitely worth less than no parachute at all, because it might encourage you to take risks that you shouldn’t.
For project management, though, the idea helps explain my long-running idea “work just a little bit harder than you want to.” Often, when working on a project, we get exhausted, and decide to give up – but working just a little bit harder can take us over the finish line. Our instinct to save us effort can actually thwart the work we need to do to achieve success.
For example, recently I was working on a machine learning project that just wasn’t working. We’d spent enormous effort on getting the learning system up and running, without good learning results to show for it, and the arbitrarily imposed deadline was coming up to show something impressive, or the project would be axed.
But, if you know anything about machine learning, you know most of the effort goes into data preparation. We had to modify the system to log its data, massage it into a format that was useful for learning, and spend further coding effort to speed it up so it was useful for development (taking the data load from 36 hours to 36 seconds!).
The point is, we only got the data running in mid-February, and were trying to compress months of experimentation into just ten days. Finally, as the deadline approached, I got philosophical: we’d done all the work we needed to do to start learning, and my recommendation was that the team keep working on it, with or without me.
But … I didn’t stop there.
Before the final presentation, I spent time cleaning up the code, checking things in, and getting a few of the most promising programs ready to collect “baselines” – long runs of the system set up for comparisons. And the next morning, I reviewed those baselines to present a report to the team about which one was most promising.
Long story short, one of the simplest models that we tried was actually sort of kinda working. Once I realized we had a scaling issue in the output, a simple tweak made the system get even better. I spent another hour tweaking the graphs to put the human input and the system results onto the same graph, and the good results leapt out into sharp relief.
I could have just decided that the system was a failure – but then I wouldn’t have done that extra work, making it a self-fulfilling prophecy. I call this the “Sunken Cost Fallacy Fallacy”. For those not familiar, the “Sunken Cost Fallacy” kicks in when you keep doing something that isn’t working because of the effort you’ve spent, even though you have a better option.
But you can’t “decide” that something is a better option because you’re a Decisive Decider™. It actually has to be a better option, or what you’re doing is simply throwing away the effort that you’ve spent to date because you want to throw your weight around. No, if you suspect a cost is sunken, there’s no substitute for doing your due diligence – is the project working?
If it isn’t, sure, then quit. But often, that little bit of extra work can unlock the solution to the problem. During my presentation, the team asked natural about the simple model that turned out to be the most successful – and those questions made me realize it could be improved. Over the weekend, I applied those fixes – taking merely good to excellent.
Last week, as of Thursday night, I was pretty down on the possibility of success for our project. But I did my due diligence anyway, and by Friday morning, I had a working solution. By Friday afternoon, all the team knew it – and by Sunday evening, I was composing an email outlining our machine learning “recipe” that we can build on going forward.
Quitting just before the finish line wastes all the effort you spent on the project. Before you quit, work a little bit harder than you want to and do your due diligence to check whether it is working. If it isn’t, you can stop with no regrets; if it is, you will have not just saved the value of your project – you will have saved yourself from shooting yourself in the foot.
-The Centaur
Pictured: The project team. Three-quarters of them want to try a new direction, but the old seasoned hand isn’t quite so sure.
