Send As SMS

Friday, May 26, 2006

so what do you want again

I use my computer to code, watch some TV and listen to music. I hate as a rule writting documentation, project specs, plans etc I love, I LOVE plans... as anybody from prevsious collaborative projects but handouts, help sheets - guides, user manuals. I think I do an OK job of it, not great that does come from being technical Even when your'e stepping through a process to write a guide you still do lots of little thigns you don't even notice you're doing. When I've written a plan I like even more sticking to plans. Therefore when at work I suggest we hammer out specificiations to help projects come together more effectivly, rather than running in with fairly chunky changes a week before something is going live we've all got an idea what to expect. It is rather annoying to have this idea dismissed on. I don't want this post to sound like a Professional Issues lecture but documentation is a good thing.

Joel Spolsky he makes a great comment about a project plan not only to write it but then it's not an icon to be worshipped on high... get it off the shelf and read it, know it, use it. Change it. I don't believe that these documents are or should be cast iron. I was a great proponant of the idea of the organic document in previous projects. Does having an organic document then actually help prevent specification creep ? No, you're not going to stop the mad child eating beast that is spec creep. You could write the best spec in the world, lucidly describing every nuance of the system that you're modelling. Then someone will come in five weeks later and inform you that they forgot to include the fact that you need a new box / field / menu / colour / widget. You can't and should't refuse this if you do the system is a bad model even before distribution.

Private sector IT service companies try to restrict this sort of behaviour, whereby the client actually gets what they want, by leveraging incredibly large fees for making changes even simple ones like wordings in a menu - therefore the system doesn't get changed, it fits the spec the company gets paid but the users don't get what they want - the system isn't used and merely becomes the thing of a public enquiry some months later.

Hazel Blears, the Police minister in the UK last month decided to sign off on spending £367m on a new police database management system. From what I have briefly read, it's a big agragator to bring together all the current systems. Then today a third response from Ms Blears office to the Bichard report tells us that over 50% of British Constabularies have causes for concern regarding their database and data systems. Data integrity and accuracy was highlighted as an intelligence failing that contributed to the deaths of two British School girls some years ago.

New systems are supposed to go through an acceptance test, this is clearly often carried out by managers who sign off that a system is excellent, without ever actually unleashing it on the real users. Recently the debacle over the MOT computer system that the UK Home Office didn't even know it had paid countless millions for failed as soon as real load was placed on it up and down the country.
Last week Accenture was left defending itself to a select committee regarding it's rural payments system that had cost £34m... no sorry in the end UK Gov paid £54m for it not to work.

Would these continued errors in the public sector have been caught by good specifications ? There is a problem with the developers writing the spec, just as you can't expect the designers to test their own system. I realise that there are cost restrictions to this ideal. However I know of large companies who treat public IT contracts as a gravy train. People will instantly damn Thatcher for treating everything like a business lay the blame squarely at her door. However this is a non sequitur, consumers have rights and get good deals. The reason public IT services are in a mess isn't because they should have all been conceived and developed internally like a mass produced 10^6 pair of wellingtons. It is however because those managing them and collaborating with the private don't know what they are doing. Of course you can't expect an IT graduate to work in the public services to oversee their peers raking it in in the private sector. That is after all what you outsource for... to find a skill set you don't have. What you can expect is that the person whilst not an IT graduate should at least know if they are being taken for a ride. That can spot a gaping hole in a specification if asked to read one, that's why they're written in the first place, well should be.

When I want a knew roof in my kitchen I didn't call a builder and provide him with a plan complete with measurements, a list of suppliers and a supporting cast of half a dozen lackeys. No I call him up and ask him to provide a quote for a new roof. Then I call 4 or 5 others. These all then come and visit my kitchen and work out what they reckon they need to do and gimme a number called a quote that should be itemised. If this number changes when the work is on going I damn well want an explanation. If as part of that I discover he's also trying to rewire my house and is charging me for setting up my digital television and washing my dog, I tell him to get stuffed. If he then does so leaving me with no roof, I'm not giving him a damn penny. I don't heartily laugh and cut a cheque for all the jolly good hard work he's done thus far. That is the impression I get regarding government IT projects at the moment. I doubt the proposed ID card system will be any different.


Post a Comment

<< Home