Disasters hold an unholy attraction for many people. Some of us are fascinated by train wrecks, others by earthquakes. What I can't seem to keep away from are the gory details of IT projects that go off the rails.
In the '90s, there have been many projects that famously self-destructed. Some of the large banks' new systems went west early in the decade, although their customers have most generously since made up the losses. A recent example of a disaster is Telstra's JORN (Jindalee Operational Radar Network) project, which reportedly sent half a billion over the horizon. Computer companies supply their fair share of wipe-outs, too. For instance, the Taligent joint venture between Apple and IBM gurgled down the plug-hole after seven years of work.
But before you feel too smug, dear reader, you should know that industry surveys and the studies of metrics experts indicate that even the average project is likely to be six to 12 months behind schedule and 50 to 100 per cent over budget.
I'm indebted for that rather dispiriting statistic to a fascinating book by Ed Yourdon. Yourdon is a well-known guru of the software developer crowd, and his book is Death March, sub-titled "The complete software developer's guide to surviving Mission Impossible projects" (Prentice-Hall, $49.95).
While it makes interesting reading for project managers, and indeed is targeted to that audience, Death March treats a subject that CIOs must know about, too.
My own informal surveys show that what nine out of 10 CIOs fear most is looking like a nana in front of their board and their peers, and a "death march" project is a real recipe for egg on the face.
By Yourdon's definition, a death march project - with apologies to Weary Dunlop and the real death marches of World War II - is one where the time, staff, budget and resources are less than half those normally allotted. Such projects usually are characterised by a very high upfront likelihood of failure, horrendous overtime, and huge personal stress and even relationship breakdowns.
The typical death march project seems to arise mainly because of hopelessly unrealistic schedules and budgets, users who keep adding more requirements to the original ones, naive promises by managers - CIOs included - and corporate political plays.
Yourdon offers a lot of practical advice on how to cope with these horrendous black holes of projects. Ideally, he says, you should kill them off in their cradle. Try to have the guts to question unrealistic deadlines or snuff out doomed projects before the train starts moving. But if you can't stifle a potential disaster project at the start, and if you don't wish to leave the organisation, then Yourdon's advice is that you must adopt a survival strategy.
That survival strategy includes identifying all the major players in the project - the owner, customer(s), shareholders, stakeholders, and champion - and ascertaining their levels of commitment. Identify the real objectives of the project owner. Break huge projects into smaller ones, with intermediate deliverables. Practise triage, focusing on the essential at the expense of the optional. Never succumb to the trap of producing an "instant estimate" for a project. Consider implementing daily builds of the system (as Microsoft does).
And there are plenty of other tactics, as you'll find if you read the book.
Yet even if your projects are not death marches, and not likely to be, I believe it could be a useful idea to follow some of Yourdon's excellent advice.
After all, each of us wants to become more effective in bringing systems in on time and under budget - not to mention avoiding disasters.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.