I’m sure I’m not the only one that hears about big public sector IT projects costing billions and exclaims that my firm could have delivered a better solution for a fraction of the cost. And that’s just the ones that go well. The public domain is full of stories about government IT contracts gone wrong or consulting firms paid enormous sums to deliver poor quality solutions.
Take the infamous NHS National Programme for IT project. Intended to unify the core IT systems of the NHS and cover everything from patient health records to sharing imaging files, the project was mostly outsourced to the usual suspects.
By the time it was abandoned and written off, it had cost over £12.4 billion. Ouch.
Naturally, it’s not fair to say that all government IT projects are doomed to fail. We typically only hear about the newsworthy cock-ups. But, even so, it’s difficult to shift the feeling of inevitability when a large government IT project is announced, and with the failures that do happen tending to fail hard, it’s valid to ask why this keeps happening and why the government keeps giving big contracts to large outsourcing firms.
Well, in my view, there are three main reasons. The first – a lack of personnel and experience in running large digital projects – has been covered extensively elsewhere, so I’ll avoid retreading that ground and instead focus on how attitudes to risk and complexity undermine big public sector projects.
Offloading reputational risk is desirable
This is strictly my opinion – and perhaps reveals a level of cynicism – but the first factor to understand when asking why governments continue to use big outsourcing firms is the offloading of risk and bad PR. Large outsourcing firms are familiar with, and experienced in, taking on the risk of a project going wrong. Not in the sense of any financial risk, but in terms of reputational risk – it is part of the service a government department is buying. No political head of department or organisation wants to take the blame for a project going awry, it can be a career killer, so why not outsource that risk too?
The interesting thing to note here is that this is a vicious cycle. The more aspects of the project you outsource the less control you have and the further from the decision making process you are, so the more likely you are to be delivered something that is not fit for purpose. I’ve written on this subject before in the private sector, and this is exactly the same effect only on a grander scale.
Complexity kills public sector IT
Potentially the most pernicious reason big public sector digital products fail, for me, however, is complexity. Or, maybe more accurately, a lack of understanding of complexity at the outset of a project.
The key thing to realise is that in the public sector there is no such thing as a “simple” project. In fact, I would argue the ones that instil the reaction “wow, I could build a better solution at 10% of the cost” are the most dangerous ones.
When we’re engaged with our private sector clients we’re looking to provide a solution that gives them the biggest bang for their buck. Return on investment (ROI) is king in nearly all situations, particularly with new greenfield services that introduce a new way of working to an organisation.
For example, where we have built digital platforms that partly automate day to day operations, we’re not doing that to make it easy for the existing staff of the business, we’re doing it to make them more efficient and to make their operations scale in a sustainable way. Even with consumer-facing solutions, each thing we build must be justified as the available budget must be used efficiently.
The end result is that we always start with a Minimum Viable Product (MVP) that contains only the very basics so that it can be rolled out and start having an impact immediately, proving its own value. This is optimising for efficiency.
What most don’t seem to grasp is that for a big public-facing digital service the requirement is not to optimise for efficiency, it needs to optimise for accessibility.
You don’t understand people
By accessibility we mean more than just folks with screen readers and so forth; there are all sorts of other aspects in play. Consider those citizens of a country who might use a different language, or have different learning abilities or those with very limited technical skills. They need access to these services too, particularly if you intend to degrade or remove the old systems that the new service may be replacing. A private company doesn’t need to take absolutely everybody into account, they can choose their audience. The government does not have that luxury.
A private organisation is also less likely to be covering very sensitive matters. If you’re creating a government service that deals with probate for a recently passed on loved one, for example, then language and tone need to be not only clear at easy to understand, but also sympathetic to the probable state the user will be in.
This is why in the UK we now have strict rules surrounding the clear use of languages, user flows, and how to present potentially sensitive questions. Getting this right requires an incredible amount of careful research, with these points all being something the Government Digital Service (GDS) team will audit your services for. If GDS’ copywriters think your service might cause problems for somebody with dyslexia, for example, you won’t pass the test.
Best of luck to you if you have to provide that same service with the same delicate balance of tone in multiple languages… including Welsh.
You don’t understand the world
Additionally, when building systems for a private organisation it isn’t so terrible to make some assumptions to save time. After all, we’re optimising for budget efficiency and ROI, right?
As a result, there are a lot of situations that, for a commercial organisation, it’s not worth covering as an edge case. When something happens twice a year, for example, it’s far cheaper to have customer service or support desks deal with these instances on a case by case basis than to code a specific exemption into your digital product or service. When you’re working on a public service that many millions of citizens of all walks of life and abilities must use, this isn’t acceptable, both from a support burden perspective but also from a discriminatory perspective.
These edge cases can be very subtle too. As an example, let’s say we’re building a service to register a new car. First of all, we will need to be clear with our language.
We said ‘register a car’, does that include vans? Where is the cutoff between a van as a ‘car’ before it becomes an HGV? Will people struggle with the language you present this in?
“A motorbike has 2 wheels, a car has 4 wheels” – this isn’t correct. Trikes, quad bikes, and Reliant Robins all exist.
Lets say, though, that you’re the DVSA and you already have a clear simple language set that you can use elsewhere, so you copy and paste that in and move on. Let’s sort out collecting the person’s address next. We’ll need to do some validation here!
‘A building or house number must be 1 or higher‘. Nope 0 Egmont Road, Middlesbrough, TS4 2HT exists.
These might seem like tiny small trivial things, and they are, but when you’re providing a government service these tiny little edge cases really do matter – and there are so so many of them. Somebody registering on the system might actually live in the van they’re trying to register and thus not have an address at all.
This difference in optimisation – between efficiency and accessibility – is the key distinction between creating private and public digital services. Making the jump between disciplines is far more work and expense than most people realise.
So why do government IT contracts always seem huge and bloated? Because they are hard and nobody politically wants to shoulder the burden if they go wrong.
The post Public sector IT projects are hard because some people live in goddamn vans appeared first on Browser London.
Top comments (0)