OK, I’ll concede that the relationship between mountaineering, satellites and software development is not immediately obvious. But, nevertheless, whilst lying stormbound in small tent near Whitcombe Pass during my now almost forgotten “summer” holidays, certain commonality in the area of project delivery became apparent.
The occasion of this revelation was day seven of three-week traverse of the Southern Alps from Arthur’s Pass to Mt Cook. It was raining heavily, very heavily, in fact, and with persistence suggesting this storm wouldn’t be breaking any time soon. My climbing partner, Martin Hawes, was running ‘what if’ scenarios through our trip schedule and judging by his serious mood, the results were not promising.
An updated weather forecast was clearly required so out came the Iridium phone and shortly our weather forecaster was delivering his prediction: the already heavy rain becoming heavier for the rest of the week followed by another series of cold (and wet) fronts the next week. pattern of bad weather with no end in sight.
This was not good news. As we settled back to contemplate our options I gazed at the phone and realised that we confronted the very same dilemma as the corporate rulers of the original, now bankrupt, Iridium company: how long do you keep investing in project over which storm clouds are gathering? When is it time to cut the losses and walk away or start again?
Ours was not low budget expedition: helicopter delivered food dumps, specialised equipment, planning and communication added up to tidy sum. Moreover, we had committed to the challenge and invested week of hard effort in it thus far. Abandoning all this was not top of mind.
Iridium and ourselves were not alone. In fact, our little problem is common enough in the world of web and software development. Marvellous plans are hatched only to founder on various combinations of changes in technology, market shifts, inadequate developers, uncommitted clients and just plain bad luck. Often the goals are sound, it’s just the execution that fails. And when that’s the case, starting afresh must be an option.
Obvious point: whether it’s in the Alps, the upper atmosphere or corporate headquarters, the longer project has been running, the more time, money, reputation and emotional investment in it, the harder it is to pull the plug. Yet occasionally we see examples (all the more remarkable for being public) of corporate willingness to walk away at the 11th hour. In New Zealand we have our very own timeless classic: Incis. While we should lament the judgement that let that project live as long as it did, common sense ultimately prevailed, sparing taxpayers the burden of sinking more money into police information infrastructure that was doomed to be outdated on arrival.
Ditching your ailing development project is bound to be horror show when it’s in public view (and web development is particularly exposed to public scrutiny). But even behind closed doors advising the board to scrap software development investment can be lethal experience for management. Still, there’s no doubt it’s better to take the initiative and do what management is supposed to do: lead.
Four principles to help you put sick project out of its misery:
1) Beware of false Rubicons. Any belief that project has passed the point at which there is no choice but to proceed should be put to the test. The Point of No Return is valid concept in aviation but the opposite will often apply in the development world.
2) It’s never too late to walk away. Returning to the mountaineering theme, it was once my privilege to witness an astonishing instance of disciplined judgement: team mate climbed to within few minutes of the summit of Everest. He had time in hand and excellent weather but turned back because he calculated that he wouldn’t have the strength to descend if he pushed on those few extra steps to the top. In software terms that’s like taking months of development, ditching it the day before the launch and paying for it out of your own pocket! Drastic but it may be the rational option. Managers who think the end is within reach should bear in mind that the last 10 percent of development project will probably gobble resources far out of proportion to the preceding 90 percent. Especially the shaky ones.
3) False summits (last mountaineering analogy, I promise). Following on from the previous point, the whole argument that project completion is so close that it’s not worth stopping is predicated on the assumption that you or your software engineers can actually see the end. painful and not uncommon mountaineering experience is to wearily slog your way to what you earnestly believe (hope) is the top only to find you’re on false summit which has obscured the true summit lying some distance away. On bad day there can be succession of false summits and in my experience the terrain between has habit of turning nasty. It’s hard to see false summit coming but prudent to assume they exist.
4) Experience. Any software engineer who claims they would do it exactly the same way again is either arrogant or genius. restarted project has the benefit of experience gained in the first attempt to offset its costs. In the short term this might seem like cold comfort but there could be real dividends long term.
It’s all common sense really and that makes it all the harder to understand how the undoubtedly super smart people behind Iridium could have orchestrated such disaster. It wasn’t all bad though – the plan to bring down their satellite network has served up another collectible American euphemism: ‘deorbiting’ and that’s on par with ‘collateral damage’ in my book.
And, of course, there’s still the phones. For which I was particularly grateful as I dialled up the Pudding Hill helicopter base and chartered Squirrel to deliver us from the storm to the dry heat of the Canterbury Plains.
Mike Perry is chief executive of Montage Interactive, Christchurch-based web software development company.
