Why does Government mess up IT?

There was an article on the Daily Politics today about Government IT projects. Francis Mause said that they are changing the way in which IT projects occur and that it's improving the situation. I believe him, it could hardly be worse.

The last Government wasted £12Bn on the NHS computer system. I'll say that again. £12Bn. That's mammoth. You have to stand back in disbelief when Labour shadow ministers complain about the £40m misspent on the Universal Benefits project.

For non-IT professionals, I'll give the low down on why IT projects go wrong. The old way of doing projects meant that there would be a desired aim for the project.Project Managers and Analysts would then spend months and months writing requirement specifications, trying to nail down every last item of functionality (what the project should do). When a specification was finally agreed it be outsourced to one of the large IT contractors who would start work on it. After several years, the project would be delivered back and the Government would find out that it didn't do what was necessary.

There would then need to be a re-design, possibly a large one. Maybe there were so many flaws that it had to be completely ditched. Many times the Analysts got some requirements wrong, or needed to add new ones. Political priorities change, new responsibilities get added on. As the end of the project nears it becomes frantic and previously essential features get dropped and scaled down.

This system is called the Waterfall approach, every stage feeds onto the next. The problems are that each stage takes for ever, and you only find out how badly the stage went at the end - several years later.

A new project methodology, called Agile, has changed the way big projects can be tackled. The project starts with little detail and gets broken down into 'stories' and tasks. The stories get fleshed out and implemented in an 'iteration' or 'sprint' which could be a few weeks or nothing more than one month. These sprints contain less than 10 people in the development team, and so there may be more than one team working on different functional areas. At the end of the month, all the implemented stories and collected into a demo and shown.

This way, the project managers and clients can see it develop and point out flaws, or extra requirements and things not liked. The development team can also have a say on what went wrong in the sprint and hopefully make improvements for next time. As time goes by the projects get closer to completion. "Must have" features have to be completed, and "nice to have" are just that. In theory, this means that there should be few surprises, including all the essential features and having been demo'ed to the client throughout.

This latter method is what Francis Maude's team are using. It's certainly better than the old Waterfall method, and its about time.

Although there will be some problems and some money will be misspent, its likely to be much less than before. Let's hope so!

Squiffy.