Another Govt IT system that doesn't work, apparently

(Written 18/9/2013)

 

I see the latest Universal Credit IT system project has been roundly condemned for being a bit useless. I am not surprised one bit.

 

Systems are fairly easy to design and code. Take it from me, I am a qualified systems analyst, accredited by the University of Birmingham. Ask me to design a system that assesses all the benefits a claimant is entitled to and I'll give you one in about three months. Ask me for a system that will assess the benefits that several million people are entitled to and I'll deliver it a few months later. What's more, it will work seamlessly within the parameters you've specified.

 

So why don't Govt IT projects work - ever? Because of useless Ministers who try to make political capital out of what they think will be delivered, and useless Civil Servants who think they know best.

 

Look, getting a computer to take certain values, manipulate them a bit, shove the result into a formula and use the final value to initiate a monetary bank transfer is simple if you have the ability to break down the sequence into logical steps and a tame programmer to work with. Once you can do that for one claimant, you can do it for a million - a billion, if you're prepared to use enough resources. If it works for one transaction, it'll work for (n) transactions.

 

What tends to go wrong, though, and causes massive delays, is when people either forget to mention an element of the kernel formula that ought to have been drawn to the hapless analyst's attention on day one ("Yes, people on sickness benefit don't qualify for tax relief on their bloat-mobiles, but registered disabled chubbies can claim an allowance for them if they have no other transport. It's obvious, why did you leave that out?") or they change the specified parameters ("The Minister has told the House that your system will also root out illegal benefit claims, please build that in before 'go live' testing starts next week. Some kind of fingerprint or iris recognition technology would be best.")

 

You see, what happens then is that the system build team have to add some more steps to the process diagram, run their theoretical systems tests again to make sure that all the right benefits go to all the right claimants, then add several hundred/thousand lines of code, and run a test of the program to make sure that all the screens don't light up with <"Out of cheese error"> (or, worse:

 

<Error 3791 - missing subroutine>

<Error 939 - divide by zero error>

<Error 7302 - divide by error 5804 error>

<Error 1603 - missing ")">  Ho, ho... but where?)

 

Then, when everything seems to work, both theoretically and without crashing dependant systems ("Claimants bank accounts frozen! Millions starve!" - Daily Mail), test scenarios can be run. Assuming that they all produce the correct results - and if they don't, we all go back to the start of the last paragraph, we do not pass "GO", but we still get paid the £200 a day - we move on to load testing.

 

This is where all the data is put onto the system, while we wait to see if the servers can take it. When they can't, we remind our masters that "buying better servers" was one of the items they removed from the system spec because their own in-house Scotty said that the engines could take it. And that extra dilythium crystals would make the project "Verra, verra expensive, Captain."

 

The person responsible for buying adequate servers is actually a committee of 30 that rarely makes a decision due to the conflicting interests of its members. Imagine an early-adopter techno-geek, a time-served C++ programmer and a parsimonious skinflint trying to arrive at a server-buying policy that will be acceptable to a Minister who struggles to find the "Start" button on his laptop, then multiply the confusion by six and you'll realise why an urgent project-saving decision can take three months and five meetings before it's implemented.

 

So, now the data loads without bringing down other essential systems ("Bulgarian scroungers walk through open borders as passport recognition systems fail!" - Daily Mail) and it's time to see if the system - which is already a few months overdue and over budget - can cope with many multiple operations at the same time. To test this, around a hundred Civil Servants are temporarily relieved from their duties and put in front of PCs, then handed a script and told not to deviate from it. The script runs along the lines of:

 

Press button "A"

Now click on "New claimant"

Choose "Romanian" from the drop-down list

Click on "Asylum seeker"

For "Dependant children", choose "4"

For "Sort Code", enter "11-11-12" and "123456" for Account Number

Click "Done"

The result is £0.00.

Please raise your hand if you get any other result, including <Out of cheese> error.

 

Many of the scripts run other more complex or simpler scenarios, and they're kept at it all day while Scotty looks at the load levels and mutters. Finally, it seems that everything works.

 

So now the training team can go to work. They were recruited quite a long time ago (just before the bloat-mobile confusion happened) so that they could document the system in ways the eventual users could understand. These documents are known as "manuals", and they contain many screenshots with helpful arrows labelled "Press this button" and the like. They have also been devising training scenarios and stitching them together into 90 minute presentations. Four such presentations will eventually become one training day. The trainers, too, are costing the project £200 a day, plus expenses.

 

The training team are mightily pissed off, because they are now on version seven of the manuals due to the ever-changing screens that the project build team are amending. On the plus side, they're at the top of their leaderboards on Bejewelled Blitz, they're enjoying their hotels and the owners of various ethnic restaurants welcome the distribution of their chargeable expenses.

 

Now that the system works, and there's a training programme that reflects the current build, a two-month training schedule that's at least six months overdue can start. And here's where the real problems arrive, because most Civil Servants will avoid training on new systems with might, main and meetings. I speak from experience. Most training sessions will run at 75% capacity. Meaning that the two-month training schedule is extended by a month to pick up the no-shows, the final few of which have to be dragged in with whaling harpoons as they claim that they have an urgent meeting concerning national security with the Prime Minister. At Buckingham Palace.

 

You have a working system and trained staff. It's nearly a year overdue, you've bought servers that were not included in the project cost and during that year-long over-run you've been employing trainers earnig £200 a day from an agency that charges £600 a day for each one and a system build team from the people who made the software. They're usually more expensive than trainers.

 

"Go Live" day coincides with Budget Day. The Chancellor of the Exchequer announces significant changes to the benefits system, changes that have been secret to prevent press leaks. We all start again...

 

My best advice for project managers? Nail the system parameters down tight, refuse to accept any changes to it - ("The bloat-mobile tax allowance is now called Fatties On Castors, please change the relevant screens." "Tough, you're getting what you paid for.") and insist on quality kit that copes with almost anything from day one.

 

The final system still won't work, of course, but it will be delivered on time and on budget. And in the crazy world that is Government project management, that's much more important than a system that works properly.

 

Just ask ATOS.