Flavours of Government IT project
I’m still on holiday, but I had to reference Daniel Davies’ points about government IT projects and the pernicious role of consultants (not consultants like me of course - the other kind of consultant):
Consultants are a bit like bindweed. When you’ve got bindweed in your garden, you don’t get rid of it just by getting up one morning and saying, “You know what? I fancy a bit less bindweed!”. Consultants are the same. Consultants are, if anything, a bit more difficult to be rid of. With bindweed, it is a hell of a job to eradicate, but at the end of it, your garden looks more or less how you wanted it to.
However it’s his accompanying blog post at Crooked Timber that really tells the truth - a truth not just about government IT projects but any IT project that involves big bureaucracies. And yes, that includes the UN, national governments and even (increasingly) some NGOs.
The sales process is an important part of the procurement of big, failed IT projects, but the proliferation of big failed IT projects isn’t really a result of successful selling – it’s a result of the fact that nearly anything new that the government does is going to require an IT element, and that government projects tend to only come in one size, “big”, and to very often come in the variety “failed”.
I’m as pessimistic as Davies is when it comes to big IT. I think IT should be small, modular, oriented towards how people actually work rather than how consultants think they should work. Design from the bottom-up, design from the experience-out, and dispense with the jargon as much as possible…
And a lot of the reason why these projects screw up so badly has to do with the fact that they have to reinvent a lot of wheels, duplicate data collection exercises, and integrate incompatible systems (useful rule of thumb: whenever you hear an IT person use the word “metadata”, as in the sentence “all we need to do in order to make this work is to define suitable metadata”, you can take it to the bank; this project is fucked)
Amen to that. I used to preach the gospel of metadata until I realised that it’s frequently a good excuse for not actually implementing your project. Metadata is important, but a) the end users must never, ever hear the word and b) if you’re relying on metadata to make the project work, you may as well forget it.
Open Source should also be on the radar of these type of projects. The work that goes into one Govt, UN, or NGO project can be reused and made better over time through cooperation in the open. You could almost say it’s part of the mandate of a public serving organization.
Not that open source is a magic bullet, and if an existing proprietary or web based system is judged to serve needs better, great. Then, the pressure should be on to support open standards and lightweight formats, as in the every day working practices of the web (and the web is working out pretty well).
A number of times, I’ve heard consultants and representatives of big software companies (you know who they are) spreading fear uncertainty and doubt about open source. This type of commercially beneficial rhetoric has no place when software is being developed for humanitarian needs.
Mikel Maron
16 Aug 08 at 9:34