How IT works (or doesn't)

It turns out, according to Michael Cross, that the report into IT systems commissioned by the Conservative Party wasn't as opposed to central database as might have been hoped. Cross writes that although the party spun it as a call to dismantle Labour's "centralised IT infrastructure",

In fact, the review specifically says the £13bn NHS national programme for IT in England "should not … be abandoned, as some are suggesting it should be." While it proposes dropping the programme's distant and quixotic goal of storing health information on the central data spine, essential central IT architecture should continue to be provided centrally. This might include the current patient index, which includes nearly 30 items of "demographic" data. Likewise, it dashes any hope that central IT organisations can be demolished. "It is clear that there is still an appetite for a central support body for NHS IT. No one feels that local health economies should function alone."

If so, I hope the party has the self-confidence to ditch the report - although the precise nature of a "central support body" remains to be determined. A minimal system providing support need not be a privacy-munching database - and it needn't cost £13 billion.

My main purpose in writing this, though, is to reproduce this excellent comment from HardlyEverRight, who explains why such products are doomed to run over budget and never quite work.

Nobody knows how to deliver a successful £13bn IT project - nobody. That's at least two orders of magnitude greater than anything we know how to manage successfully, for the same reason that a war cannot be thought of as a single battle fought by millions of soldiers. No one who understands the roles of platoons, companies, batallions and so on would try to think of war in that way. In the same way, what we know about managing IT projects is valid only at a certain scale. Because it is my job and because I've been doing it forever, I sometimes know how to use a hundred people effectively in an IT project. I know that thousand-person projects have succeeded because I've worked on smallish pieces of them, but I also know that thousand-person projects fail more often than not. I am sure that no ten thousand-person IT project has ever succeeded at anything.

Allow me to suggest a heuristic method for determining whether an IT project is doomed by its very size. The first step (which can be a lot of fun) is to imagine that you are a thief who has been put in charge of a serious IT project that could be accomplished for £x if it were done right. Your goal is to expand the project to £10x (or £100x or even, in the present case, £1000x - the principle is the same regardless of the scope of the desired theft; but let's stick with £10x for the sake of brevity).

Very well. To get to £10x , the project must consume ten times as many billable hours as are actually required. You might think that you would simply employ ten times as many people as you really need, but that's excessive, more like the £100x solution, in fact. That's because ten people take far longer than one person to do what one person can really accomplish working alone. To achieve a reliable 10x cost inflation you really need only three or four times the most efficient staff size. Then you chain them together, never allowing anyone to accomplish anything unimpeded by "teammates", you require them to produce a series of intermediate work products (documents and presentations of various kinds) that have absolutely nothing at all to do with the putative goals of the project, and you require that each step occur in a meeting or, better, in a series of meetings. You can tune the rate of cost inflation by adjusting the number and size of these meetings (requiring thirty people to listen to a one hour presentation is a breathtakingly efficient way of wasting far more than thirty hours).

If you do this well, nobody on your team will be aware of stealing. On the contrary, they will be "working" at a frantic pace just to tread water. In fact, when the sought-after cost inflation factor reaches a certain critical point, even treading water becomes impossible and the project is doomed.

OK. That's how big consulting firms go about their pillaging. That doesn't mean that it always happens, so how do you know whether it's happening in any given project? You simply look at what the project staff are doing all day long: if their work roles could have been designed that way, then they were. This doesn't mean that everyone involved in the project is a crook. On the contrary, the project sponsors are almost always victims rather than perpetrators.