Last night Mike Hadlow (@mikehadlow) posted a great blog about how he thought public sector IT could be fixed, coming from his perspective of a software developer working on public sector projects.
Public sector IT projects in the UK are renowned for overrunning, not working as expected and generally being an expensive drain on resources. Successive governments talk about taking IT projects in hand, but nothing seems to get done, and all the time there are a succession of high profile embarrassments, flops and cancelled projects.
I’ve had some experience working on government IT projects, and also come across people who have worked on them before and swore never again. In particular one contractor I worked with had just come off a large scale project for the NHS.
Like many big contracts it had been outsourced to one of the big corporate IT firms, who had put relatively junior project managers onto the project. They had the project plan, and were timeboxing – the problem being that at the end of each period they would just have the team move onto the next timebox, whether or not the previous one was finished. As this went on, they reported back to the civil servants in Whitehall that the project was proceeding according to plan, but when they reached the end, nothing worked as many of the deliverables for the many preceding timeboxes had been met. My contractor friend, who had many years of experience had tried early on to point out the issue to the project managers, but had basically been sent away as “just a contractor” by the young newly graduated project managers. As I said, after that experience he had sworn never to work on a public sector project again.
My experience was working on some defence projects. One in particular the company I worked for was called in for a second opinion on a system that the Army was purchasing and was being developed by a major defence IT contractor. Basically the project had hit major problems and we were consulting on what had gone wrong. On the Army side a quite senior soldier was running the project, and whilst I have no doubt he would know what to do in a battle, in an IT situation the defence contractor had taken him to the cleaners. Essentially they had got him to agree to a contract that left all the risk, and all the costs with the MoD, they basically paid for time and materials whether or not the fault that was being fixed was a bug in the software, or whatever. Again the company seemed to have put pretty inexperienced incompetent programmers who had made some fundamental programming and design errors, but as a result of the contract, the MoD were paying to fix the lot.
Many of my experiences chime with what Mike has said – the civil servants in charge of IT projects lack basic IT knowledge, and as a result don’t understand and can’t see when things are going wrong. They also rely extensively on outsourcing, something which in a number of private companies I have worked for is something to be avoided.
My experience has been that outsourcing works well if you have a clearly defined specification of what is needed. However in reality the vast majority of custom development projects are a moving target, as a result it needs a group of in house developers who are experienced developers but who also understand the business, working closely with the end users on an iterative basis. Working that way generally produces a system that more closely meets the requirements of the users, but at a lower cost. Mike highlights one such project working in that way that he has worked on that has successfully delivered, but unlike the high profile failures has largely gone unnoticed.
I can thoroughly recommend reading Mike’s excellent piece, we can only hope that a few politicians read it too!
