HMRC SOFTWARE - the Tortoise or the Hare
When HMRC announced a new IT system would be rolled out later than expected, it got the usual catcalls. It will take until 31 March 2023 for HMRC’s Customs Declaration Service to completely replace CHIEF (Customs Handling of Import Export Freight) as the UK’s customs platform. But for once, I’ve got to say hats off HMRC. When they started to replace CHIEF we were still part of Europe. Once Brexit was declared, they had to amend the Customs Declaration Service to take Brexit into account, even though the Government couldn’t make up its mind if, when and how we were leaving Europe. The fact that we’re only talking about late completion of CDS, when bits of it are already in place is a miracle. Just don’t expect the cost increase to be written on the side of a bus.
In the past HMRC software projects had a pretty good reputation. When King and Crewe covered Information Technology in ‘The Blunders of Our Government’ (2013) they admitted that not all government IT schemes have been disasters; “the customers of HMRC and the Driver and Vehicle Licensing Agency have benefited hugely from the successful exploitation of IT.”
But it’s true that recently there have been cock ups. From my rapidly outdated memories of being inside HMRC, here is my biased, personal opinion of what goes wrong when they try to replace paper and people with microchips and robots.
1 The people running the project don’t understand the process they’re trying to automate. No-one would expect the IT people to understand it, but they’re relying on an HMRC sponsor who is probably doing this as a “developmental thing” (if you’re really lucky it will be someone who is being “fast-tracked” and knows they will be out of here before the lifeboat hits the water). And as I’ve said before (here and here ), HMRC is more like a collection of villages, each with its own little ways. So it’s inevitable people can work their way up to a high grade without knowing every process.
2 When the project team try to gather information about the process they’re going to automate they either ask the wrong people, or get an incomplete picture from the right people. (More about this later). Either way, they busily start work on a piece of software that will gum up as soon as it goes to testing.
3 They decide they can improve the process by knocking out unnecessary steps. Sometimes they’re right and sometimes they’re wrong. Sometimes it turns out the steps they knock out were actually necessary. They were put in place 20 years ago because they have an impact on another team in another office that nobody remembers because the process hasn’t gone wrong in 20 years.
4 Either someone cuts the budget and short-cuts have to be taken or the budget was too low in the first place. In both cases the project is rolled out and hailed as a success, even though everyone knows it is half baked.
5 Some genius tries to apply accruals accounting to real life. So, on being told that new software will eliminate the work of 40 members of staff, he decides to switch the 40 staff to another line of work before the software is delivered.
6 Priesthood. I developed this crazy theory after banging my head against a firewall. Software problems were having a real-life impact on punters, but the IT developers refused to carry out workarounds that would have solved the punters problem. They said it was more important to ensure the system as a whole was fixed. Maybe, as a wise man once said, the problems of three little people don’t amount to a hill of beans. But sitting in the middle, it seemed to me like they’d forgotten the system they were working on was supposed to deliver a service to people . They were priests of a new religion and the system was their God.
Just going back to point 2 and why the system developers get wrong or incomplete information about the process. As I said, the HMRC people in charge of the project don’t always understand the work they’re trying to automate . The managers of the people who do the work don’t always understand the work. And the people who do the work understand it, but don’t always know why they do it.
Today’s HMRC doesn’t think that’s a problem because Administrative Assistant grade staff don’t need knowledge. They just need to follow the guidance. Just as managers at Officer and Higher Officer level don’t need any expertise. They just need to TELL staff to follow the guidance. And you ever come in contact with a punter (sorry, “customer”) just tell THEM where to FIND the guidance.
But when you’re trying to automate procedures (or write the procedures in the first place) it helps to have staff who can tell you what they do. And it’s even more helpful if they know why they do it. That was driven home to me when an IT development team asked me to confirm a few details about a process they were trying to automate.
My team had only taken this work back a couple of months before, after a break of a couple of years (with the office closure programme and the Brexit Hokey Cokey it was standard procedure for work to be shifted between offices). We had a mixture of people who’d done the work before and others who were new to it.
I didn’t have a clue how to answer the IT team’s questions. So, I asked a handful of the AO staff. And I got three different answers. Like talented chefs, the staff had all been doing subtle variations on the same recipe. Why? None of them knew, except that each them said their way was the right way.
The procedural guidance was too basic to give any answers. One of the staff remembered a Performance Improvement team revising the guidance a couple of years ago, cutting out un-necessary steps. But they hadn’t left any notes or explanations of what they’d cut our or why (the Lean priesthood insisted that you didn’t need any notes because what Lean left in its wake was perfection).
Now you might ask why no-one had noticed all this before. And I guess the answer is that when you get a bunch of people working together, things tend to work out in the end. If something goes wrong, everyone pitches in to put it right and then moves on to the next problem. It’s only when you try to standardise the process for a computer that basically only understands one or zero, yes or no, that you have to start trying to answer these problems.
And no, I don’t believe this is typical civil service. Because, as I’ve said before, the civil service has been copying the “best practice” of private industry for years. And As King and Crew put it, “ministers and civil servants evidently failed to notice that all manner of IT disasters had already lost private-sector companies many billions…”