Postscript: Why government IT constantly fails

Monsieur Dickson has prodded me into posting Philip Virgo's conclusions on 'Why government IT constantly fails', an article hidden behind a content firewall and in PDF in CapGemini's magazine Transformation. Jeez, why don't I do Huge Corp CapGemini's job for them and publish the whole thing ... 'transformation' my arse !;]

Take it away Philip (his bolds):

What are the lessons?
The most important is to manage political expectations, beginning with what is realistic, given the time and resources available. This requires ensuring that the minister’s policy team includes advisors with relevant practical experience of delivery.
The next is to try to confine risk to one dimension at a time. For example, if there is a high risk that the objectives or organisational structures will change, you should avoid changing supplier or systems at the same time.
Break the programme into modules. In the private sector, projects that take more than three months are more likely to be cancelled than to go live. If the implementation team has not worked together before on programmes of this type, it is even more essential to begin with a series of small projects and quick wins to build experience and confidence.
By all means think big – but ‘start small, test hard, scale fast’ is the route to systems success in the private sector. It is not a new technique and has had many names over the years: from structured evolution to rapid application development and dynamic systems methodology.
Don’t be an early adopter. But novelty is not always what you think. Linux is not new. It is forty-year-old Unix, re-written for scalability and reliability, and most high performance, high volume, online private sector services have open source software at their core.
Review progress regularly against clear, open and ordered priorities and objectives. A project with more than six has none and is probably doomed. And only the top three count. This is not easy, given the temptation to resolve conflict by adding more. But it is essential.
Maintain team continuity. Bringing component projects in a complex programme in on time and budget entails ensuring that the key players know their next project and are eager to start, but also know they cannot do so until their current one has passed its acceptance test.

As I said, I think this all applies equally to web as to IT (which he was actually talking about). Even what he says about 'early adopters'. Blogs ain't new and much 2.0 stuff isn't actually 'new' and usually isn't tried'n'tested somewhere. What has changed is cheapness. Even when you do TCO.