Will small biz get a bite of mega UK.gov IT pie? Yes: if it can pass the bulls**t sniff test
ObamaCare, UK.gov, and paying for blusterguffs instead of technology
Analysis Does the UK government have a chance of being able to push 25 per cent of IT spend onto SMEs as it has promised?
The correct answer is perhaps it does, but it doesn't actually matter either way. However, the reason why it doesn't matter is what's interesting to the economists among us.
The exact and detailed reasons as to why government IT contracts always go titsup will be better known to readers here than they are to me. For example, that decision on the US government's part to write its own digital records software – when there was a perfectly good open-source standard left over from the American Veterans' Health Administration project – is particularly baffling. No, I don't know why the US did that but you might.
However, we do see two things regularly happening.
Who has the resources to do it all?
The first is that there is only a limited number of the big IT contractors that can actually handle the sort of chunky contracts that government throws around. This isn't, sadly, because the actual programming or integration skills required are only available in that handful of large IT contractors. Rather the opposite in fact: we're much more likely to see truly interesting work from smaller outfits. No, it's because there's so much damn argle bargle about bidding on a government IT contract that only the large firms have the overhead to carry the teams that win such contracts.
This isn't limited to IT contracts either: all and any contracts with any level of government are so stifled by the contracting requirements that you need to have specialists in just being able to win said contracts. This explains the consolidation of the defence industry just as well as it does the existence of only a few firms hanging off the IT teats.
Lead 'em by the nose
The second thing is that government is the archetypal simple shopper. "We'd like a computer system please but we don't really know quite what one we'd like": face it, salesmen dream of moments like this.
As everyone who has ever run a successful project knows, the first thing to do is to get the specifications right. Only once you've have, written in stone, what the system is going to do and how it is going to do it, can you possibly start to bring in anyone to start building it for you.
That this doesn't happen in government IT can best be seen (or perhaps most recently) in the Healthcare.gov site over in the US. It was clearly and entirely run, as a project, by total muppets.
According to one source, they did just four days of testing before rolling the system out. And this was just after they'd run a test with a couple of hundred users (rather than the millions expected to use the system in the real world – who promptly crashed the system entirely).
There has also been a report that the design of Healthcare.gov was changed, for political reasons, just a few weeks before that triumphant rollout. No one wanted anyone to see the insurance prices without their also being shown the subsidies they would receive. Therefore everything had to be frontloaded: a user had to input all of their financial information before they could even start to go looking for a plan.
Perhaps that was a good idea, perhaps a bad one, but a few weeks before going live, it was also a remarkably stupid one to insist upon.
Keep calm and carry on: Following the UK.gov's example
And an interesting way to look at UK governmental IT is through the eyes of those mining that Obamacare mess for lessons. And they do seem to like it:
The British learned from their mistakes. The disaster empowered Francis Maude, the minister for the Cabinet office, to bring in technologist Mike Bracken to overhaul how the British government did IT. Today, gov.uk is something of a wonder. It’s a single, centralized portal to pretty much everything the British government might be able to do for you. It’s designed for users. It’s nominated for awards. With the deep admiration of Silicon Valley boosters, Bracken is working to change everything about the way the British government builds technology. His keynote speech at the October Code for America conference received a standing ovation.
The thing that is actually being done?
“This is a hard problem for government,” Bracken says, “because it’s not really a technology problem. It’s a self-image problem. Government constructs its self-image in terms of size. It thinks of itself as huge and big. I’ve been in D.C. and seen your buildings. They’re very big! The harsh truth for governments all over the world is that many digital public services could be developed at a fraction of the size of nondigital services, and they can be created by very small teams of people in an open way.”
Those very small teams working in an open manner necessarily need to come from firms that don't have to carry the vast overhead of the people who know how to win government contracts.
You know, those who know how to avoid the problem of total meltdown after a major governmental services launch like this one. John Naughton at The Observer writes:
So why was the Obamacare site launch such a disaster? Writing in the New York Times, two politically experienced geeks argue that it's mostly down to the way the government purchases IT services. "Much of the problem," they write, "has to do with the way the government buys things. The government has to follow a code called the Federal Acquisition Regulation, which is more than 1,800 pages of legalese that all but ensure that the companies that win government contracts, like the ones put out to build HealthCare.gov, are those that can navigate the regulations best, but not necessarily do the best job."
Now, whether the Government Digital Service can continue to avoid all of that bureaucratic bullshit is going to be an interesting thing to watch – but it does seem to be doing well so far. And it's actually rather fun, isn't it, the Brits teaching the Yanks how to do tech?
But here, from those economists' trenches, is what I consider to be the crucial point:
But eventually the penny dropped: HMG simply had to smarten up. And smarten up it has. The Cabinet Office now has some geeks who can spot consultancy bullshit at 50 paces. The unit they belong to is called the Government Digital Service. Its brief is to build the right technology, using modern methods and approaches, or to employ agile computing firms that regard £100,000 as a lot of money and that are accustomed to delivering on time.
Know how and what you're going to do before you start doing it
People who are accustomed to delivering on time are the people who don't make the mistake of trying to start a project before they've got the sign-off on the total design, our second problem above.
And it's that which is going to make the delivery of government IT so much better. Not that they're using SMEs or not, but that they're actually going to be forced into writing a proper project description before they actually try to do anything.
At which point it doesn't matter very much whether 25 per cent of the IT work goes to SMEs or not. For, as Adam Smith pointed out, the entire purpose of all production is consumption – and we should only consider the interests of the producer insofar as that is important to the consumer.
An extension of this is that we really don't care who produces something but we do care that it is produced. So, if we're now going to get IT contracts offered out on a sensible basis, only after they've actually been designed, then it doesn't matter whether it's the SMEs or the enormous firms with all the marketing bods that get those contracts: for what we care about is that we get to consume those lovely digital services, nothing else.
Of course, it could be that the only people capable of actually accepting a contract on those terms will be those SMEs, in which case why not let them have 100 per cent of the budget? Oh, and entirely trash the cost of those vast departments that exist only to gain the government contracts in the first place.
Hmm. Probably won't happen but a man can dream, can't he? ®
Sponsored: DevOps and continuous delivery