The analysis was fine, as far as it went, but in my view fundamentally missed a crucial point: the root cause of these failures is the 'collusion and illusion' that characterises most projects, but is almost the norm for big, complex, grandiose projects - much loved by board directors and government ministers. The director / minister obviously wants the project to happen because of the benefits promised (and wants to be seen as a very important person who takes 'big decisions'); and the supplier obviously wants to get the project contract. So in the happy spirit of joint wish fulfilment, it suits both parties to tacitly collude and enter an illusory - if temporarily comforting - world where completely unrealistic assumptions about the costs, benefits and risks are made in order to justify the project.
Once the project is started and real-world difficulties rear their ugly heads, well, then it's just too embarrassing for the customer to admit that the project they sanctioned was 'plain wrong' before it even started. And, of course, once you've run up some big bills, the customer doesn't want all that wasted money publicised any more than the supplier does. So, they just plough on and hope for the best, even though that didn't work out last time, or the time before, or - come to think of it - ever.
Recognise these issues?
So how do you justify a 'plain wrong' IT project? Well, your starting point is naïve optimism coupled with selective amnesia. After that a few simple techniques will suffice; here are the usual suspects:
- You, the supplier, pretend that the initial work and cost estimates are 'scientifically accurate', despite most IT project managers estimating their projects by no more sophisticated a method than 'gut feel'. Another common approach is to use the 'reverse estimation' technique: 'How do I have to price this work in order to win the contract? Right, let's divide that price by the cost of employing a programmer for a week and, hey presto, there is the number of programmer weeks required to develop this system.'
- You assume the initial cost estimates will be unchanging, despite the fact that at the time of the initial estimate you (and the customer) may have a very limited idea about what is actually required, and how, technologically, the solution will be developed or implemented and what risks are involved. Once you do know this, the estimates almost certainly will change substantially, if not dramatically (and requirements never reduce: it is never simpler than you expected; estimates never go down).
- You assume that only the development costs need appear in the project cost estimate, although the subsequent cost of maintaining, supporting and operating the system may well far outweigh the development costs and so may make a nonsense of the project's justification over the system's total life.
- You assume that all the staff reductions calculated to justify the project will actually happen, despite the fact that this virtually never happens (as a result of, for example, union resistance, staff actually just being 'moved sideways' or plain 'cold feet'; what's more, the redundancy costs of those who do go may get quietly overlooked).
- You assume that the capital expenditure reductions upon which the project justification is predicated will actually happen from day one, although you know that it will be much more difficult (and possibly impossible) in practice to actually deliver those reductions (as a result of, for example, being locked in to long-term contracts with suppliers).
- You creatively 'engineer' anticipated benefits values to ensure that the financial justification beats the return on investment (ROI), return on capital employed (ROCE) or net present value (NPV) - or whatever 'hurdle' set by the accountants for the project to be deemed viable (for example 'branch turnover will increase by 0.2 per cent', 'cost per hospital patient will decrease by 1.4 per cent', when you know that it might be a fraction of that figure or, say, zero - but are secure in the thought that there will be no credible check on it post-implementation anyway).
- You assume that, on implementing the system, its users will immediately change their established ways of working and embrace the solution, realising the full benefits from day one, despite the fact that you know that this never happens.
- You assume that over the (long) duration of the project the world - in particular, government or business strategy / priorities and economic/market conditions - won't change one iota and so the project justification will be as valid when you implement the system as it is, questionably, now.
Basically, once you take reality out of the equation you can justify just about anything. Once you've won the contract, then you can start worrying about those unrealistic costs and unmanageable risks. After all, the customer is immensely unlikely to walk away once you've got going. And the realisation of the benefits promised isn't the supplier's problem, is it? That's the customer's problem.
In short, we know that many (if not most) project justifications would not fly, or even make it to the end of the runway, if we were realistic in stating the true costs, benefits and risks. We know that once approved, the justification almost invariably becomes even less credible as every day of the project passes. All this we know - and then profess surprise when the project fails to deliver on its promises. And we do it over and over again.
If we built comprehensive, commercially realistic, honest project justifications that complemented the cost/benefit equation with a truly honest and realistic examination of the risks, not only of project delivery but also of benefits realisation, then I suspect that many (perhaps most) projects would not even be approved - and this is as it should be. If we monitored and revised the costs, benefits and risks throughout the development process, then I suspect that many (perhaps most) projects would be put out of their misery long before they were implemented - and this is also as it should be.
Enter the court jester
What corporations and governments need are 'court jesters'. In medieval England the court jester was the one person in the king's court who could, without fear of reprisal, whisper hugely unpalatable and inconvenient truths into the king's ear. Our court jester would apply an independent cost-benefit-risk 'reality check' to every significant project and give an honest and unbiased judgement on whether or not it should be approved; when the emperor (board director or government minister) has no clothes, the court jester will say so. And the court jester will then maintain a watching brief, using appropriate tools throughout the development, and stop projects that had become non-viable (in terms of delivering the promised net benefits). How many ill-conceived, 'plain wrong' projects would businesses and governments kill in a timely manner (if not at birth) if only they employed court jesters?
So, given that there is probably no immediate danger of our seeing a spate of adverts in the appointments pages looking for court jesters, what is our next best approach? In my opinion it is to make the project sponsor, whether that be a government agency head or a business departmental head, truly accountable for realising the predicted net benefits of the project. By 'truly accountable' I mean that there will be personal consequences if the benefits are not tolerably realised.
At the very least, we can adjust their department's next-year budget to reflect the promised project benefits and tell them that if they want the project approved/funded then the adjustment holds whether or not the promised benefits are realised (indeed, whether or not the system is delivered at all). Suddenly they are not 'just' spending the company's or taxpayers' money. You will find that this will focus their minds remarkably on the matter in hand and cause them to ask rather more searching questions about the likelihood of really realising the promised benefits in the promised timescales. It will also make them wonder whether they really want that system after all...
And if they do still want the system after all that, the business case needs to be revised and reviewed at key transition points throughout the project to ensure that only projects that really are going to realise the promised benefits are finally delivered.
