|A completely inaccuarate depiction of the Big Bang.|
Also not a good approach to most software projects.
Well, I hate to say I told you so, but ... I told you so. Just under a year ago, I idly speculated that the next big story about an IT cock-up might be the upcoming Universal Credits system. I won't go over the whole thing in detail, but it boiled down to two concerns: firstly, I was sceptical over whether the intended launch of October 2013 was realistic; and secondly, I know from my experience of ID cards that there is a culture in the civil service of making promises that cannot be delivered. And what do I find yesterday? Oh dear, oh dear, oh dear.
Now, before I jump on any bandwagons, it's helpful to put this in a bit of context. Firstly, the National Audit Office is notorious for nit-picking (as is the Public Accounts Committee), and their supposedly damning reports are often little more than minor points blown out of proportion by the press. Secondly, benefit reform is a hugely controversial issue and a lot of criticism (and defence) of this IT project will be down to ideological stance on benefits rather than whether the product does the job. (For the record, I think the principles of Universal Credit - that work should always pay and simplification of a bloated complex system - are a good idea, but there's valid points over using the reform as a smokescreen for cuts.) Nevertheless, it looks like there's more to this one than political hype. The October launch is now just six pilot sites, which is a common Civil Service method of back-pedalling in a way they can claim they "met" the deadline.
So what's gone wrong? There is a good summary of reported mistakes on BBC news, and the thing that struck me the most about this is how similar these mistakes are to the mistakes made with ID cards. Comparing what's happening now to what happened with ID cards, I can tell you the following:
- The over-ambitious timetable: Oh dear, I'd really hoped that the civil service might have learnt their lesson here. I remember the first thing that set alarm bells ringing was my first look at the development timetable. Even with the promises that you could easily adapt an existing piece of software (they thought a program designed to issue security passes for buildings would do the job), I could tell straight away the schedule was unrealistic. You need to allow at least one month of testing and stabilisation for every month of programming - this project tried to six six months' worth of work in three months.
The new passport issuing system has fared little better - what was supposed to roll out in 2010 is only just being rolled out now. They never seem to learn this lesson.
- There was no detailed plan: Now, for once, I can't accuse civil servants of repeating an old mistake. ID cards was based on the V-model method of software development, where requirements, system design and component design were done in order, and testing starting with components and working up to a whole system. This was a reasonable approach, but - as often is the fate of V-model-based projects - there were a lot of oversights in design that resulted in too many disruptive last-minute changes.
This project, however, seems to have made the opposite mistake. It is reported that this project used the Agile Model, where you start off with creating and testing a prototype, and through many iterations add in extra features, developing the design go along. The Agile method can work if you have a suitably flexible project. This was not. There was a fixed deadline, a big undertaking, and complex contracts awarded to suppliers. The plans for ID cards were probably too rigid, but it seems we've gone from one extreme to the other.
- A bunker mentality developed: This one doesn't surprise me at all. One of the things that shocked me the most about the ID cards projects was the amount of toadying that went on. I sat in a training session where people tried to out-do each other on how enthusiastic they were about ID cards, including - I am not making this up - a helpful suggestion for how to encourage take-up, which was to only give benefits to people with ID cards as if this would suddenly make the scheme popular. It was also taken as gospel truth that once ID cards were introduced, no future government could reverse it. (Um, yes they can, and yes they did.)
Any attempt I made to highlight the mildest of concerns about the state of the IT systems got nowhere, so it's no surprise if DWP underlings with constructive concerns fared little better.
- Poor financial management: I didn't see much of the financial side so I can't make much comment about this. What I do know is that there was a massive discrepancy in pay between permanent staff and interims brought in from outside, which created a lot of resentment within the organisation. To be fair, the civil service has made a lot of progress cutting down on expensive consultants when they're not needed, but evidently that didn't happen with Universal Credit.
- High staff turnover: Unclear what the exact cause of this was in DWP's case, but a common effect of badly-managed IT projects is that everyone wants to get out. This is especially common when staff are expected to have their lives outside of work put on hold in order to work round increasingly unreasonable demands, as happened with ID cards. To be fair, I believe the people at the top of the project genuinely tried to maintain a work-life balance, but there were too many people down the management chain who ignored this.
- Inadequate control over suppliers: I will be fair to the ID cards management here: managing the relationship between government department and contractor is difficult. You need clearly defined areas of responsibility so that everyone knows who is responsible for what, but you also want to avoid fiddly micromanagement going on between the two. The management of the ID cards project were perfectly aware of this challenge.
But for all of their efforts to get this right, something went badly wrong.. I did a large part of the testing at the offices of the developers, and it wasn't long before I heard developers openly making derogatory remarks about individual senior civil servants and interims when I was clearly in earshot. The relationship between the programmers and the testers on the ground was all right, thank goodness, and we managed to ignore the squabbling and work together, but I dread to think what was going on upstairs.
- Ignoring recommendations: This one I can't comment on, because I have no idea if any recommendations were made to the ID cards project, let alone whether they were acted on - those sorts of things were kept out of view. What I do know is that, as well as the futility of anyone on the inside trying to give advice, successive layers of management were seemingly oblivious to the increasing notoriety of the scheme outside the bubble. Doesn't bode well for listening, and it seems that the bunker mentality has struck again.
In defence of the DWP, the project managers were probably unaware of all the mistakes made in the ID Cards project. This is because we never got to hear about it. ID cards were binned on political grounds by a change of government, so the problems with the IT system never came to public attention. This time, however, there's no way you can fail to notice what's gone wrong. Some serious lessons need learning here before yet another IT project is embarked on with silly timescales.
But there is one other other issue here, one that I think is more important than all of the above. I think the original mistake was to embark on an IT project of this scale in the first place. This is what I call a "Big Bang" project, where a date is set in the future where everything switches at once: IT systems, rules, maybe even working practices. Big Bang projects are extremely risky because if they go wrong, they can go massively wrong, in this case threatening to derail a flagship government policy. Sometimes a Big Bang approach is unavoidable; ID cards, for example, were a completely new thing that required the development of a completely new system. Even so, they had the safeguard of not needing to switch over millions of existing records.
I cannot understand why it was necessary to make the Universal Credits IT project so complicated. When one purpose of the project is to simplify the benefits system, one would have thought the easiest approach would be to adapt the existing systems to work with the new rules. I'd have thought it would have been reasonably easy to make the existing system for Jobseekers' Allowance (which already considers means-testing such as income as savings) also handle Universal Credits claims. Housing benefit and other benefits that are replaced with Universal credit could then be set to zero, hopefully preserving the interface between the systems. The DWP system will need replacing eventually, as all systems do. But it's better to do that as a project in its own right, where you're free to do it over a sensible timescale without deadlines for government policy getting in the way.
It is not clear whether this debacle was down to a government minister imposing this silly timescale on civil servants, or civil servants choosing this silly timescale and telling government ministers it was achievable. That is not important. Well, it is important if you're more interested in scoring political points one way or the other, but that is what happens after every IT cock-up and lessons don't get learned. Neither will lessons be learned if civil servants and government ministers blame each other. If things are ever to change, ministers and mandarins alike must appreciate a simple rule: the big bang approach rarely pays off in IT.