Anti-Pattern #5: Always Finish The Job

We're taught, when we're young, to finish what we started. When adults preached this, it was presumably because everything that we were supposed to do started and ended with a simple set of values that never changed. When your room's untidy, Mum isn't going to change her mind half way through the day, and say that tidiness is no longer her #1 objective. And when you've started sweeping the yard, Dad was never going to change his mind and decide that, hey, leaves are cool, and why don't we just leave them there?

But things aren't quite so simple in our professional lives: things change, and things can change pretty damn fast.

So what is this anti-pattern all about?

There are other ways of putting this:

"Focus on marginal costs, rather than sunk costs"

(I wish I could remembering the original author) and more colloquially:

"Throwing good money after bad"

Well, I won't claim that it's particularly advanced or even that rare, and you've probably seen it in action. Heck, I wouldn't be surprised if you've already tried to turn management around on something like this already, and are thinking about not reading on. But my plan was to list the things that I vow to never do (again), and this is one of them.

The basic premise of this anti-pattern is two-fold: it's about the value of what you're doing changing before you're finished, and the cost of what you're doing going up before the project's over. That's "Value", and "Money", so "Value for Money", or, as business minded folk prefer to term it, return on investment (ROI, my ever-recurring theme).

The sorts of behaviour that I've typically seen characterising this anti-pattern are dogged determinedness to finish a project that can clearly no longer create a positive ROI, because "it has to be done", or the decision to finish a particular project, because the extra investment seems like a better ROI than an investment in a new project that hasn't been started yet. Another form of this anti-pattern is to insist on finishing a release that is no longer relevant because it might make some money:

"There are only three features left on the list: let's just close those out, then we can look at re-thinking the product"

Now, the first of these two arguments can sometimes be completely immovable, for instance if you're re-writing the drivers for the printers you sell, and you simply can't sell printers without it, so I concede that you can trump me there. But ask yourself two questions:

1. Could we have bailed out on this bad investment earlier?
2. Can we still sell with the old software?

When it comes to bailing out on something that seems mandatory, it seems - in my experience at least - that businesses can be prone to discovering the maximum spend empirically, that is by actually spending the cash. When this is the case, sound ROI projections at a number of points along the way (every time the ship date gets pushed back) could indicate when this cost is going to be hit, and if we could just have grown a pair on day one and figured out how much we were really prepared to spend on "non-optional product X", then we would have saved a lot of money.

The second point is more of a supporting statement to the first: a fall-back for making the decision to stop developing something new. OK, this doesn't count for start-up software houses, but if this is the situation, then hitting the "maximum spend" actually means folding, because the venture capital has run out. Looking for more is an option, but trying to sell an opportunity to invest in an unfinished piece of software written by people that had no clue about how much it was going to cost isn't going to be easy... Just remember (if you did), that you had a working solution before, and that this is an option.

Looking back at that second reason for doggedly pursuing the project ship date - finishing it is better ROI than any of the other new projects on offer - is so convincing, because if it genuinely will make you more money than other opportunities (and you can't count the money you've spent already), then it would be insanity to do anything else right? Except that there's potentially a big flaw in this plan. The project has already run over, and therefore contains risks and problems. Why should a project that confounded everyone's best efforts to predict its costs suddenly become tractable and easy to close out? The simple Agile lesson is to make sure that you are definitely projecting the new (hopefully last!) ship date using a very well calibrated velocity, and have factored in all of the risk factors that have emerged to date.

And finally, the third sort of behaviour - based more on ignoring that the value has changed, as opposed to the cost - is potentially disastrous  While you are finishing off something irrelevant, your competitors are already working on the relevant stuff! If you don't have the right stuff to sell, it doesn't matter how cheap it was to produce, so the focus on value to the customer is almost - in my opinion, and many others' - more important than cost.

Given this, many formal project management techniques (such as PRINCE2) already teach us to re-evaluate ROI at a number of points throughout a project, particularly when anything goes out of bounds, such as time or cost. However, the part of of the equation that often isn't subject to close scrutiny by our business sponsors and stakeholders is value. By value, I mean value to the customer, and not the monetary value of what it is we are going to sell, although one is probably a pretty good surrogate measure for the other. How can we obtain this constant calibration? Rapid feedback, again, something Agile and Lean teach us. Get it into customers' hands and see if they like it and want to use it. If not, change direction, quickly!