NHS £13bn IT programme to be overhauled - good luck with that
computerworlduk.com
computerworlduk.com
I bet a small group of motivated people could get the work done faster, cheaper and with greater user satisfaction if they built out from a small project to the wider NHS.
I happen to be in the weird position of knowing some of the people who are currently running the UK. I was at Oxford at the same time as Cameron etc. and actually know Michael Gove. I wrote time him just before the election about this very issue. Who knows if they'll listen.
I think one of the biggest problems with modern society is that due to the scale of institutions, there are way too many layers of abstraction and aggregation between decision-makers and the decisions they make. This breaks the feedback loop, since decision-makers can only operate against generalities and not actual knowledge, and it encourages a great deal of risk aversion that prevents the exploration and variation necessary to create real solutions.
Secondly you can not do agile things or indeed anything other than mainstream IT projects under the current procurement rules. I've tried (from both sides)
So reform will have to come from the top down. The good news is that this government does seem interested in root and branch reform so keep pushing. However it is going to require dramatic new thinking in an organisation (the civil service) that is fundamentally built to resist such a thing as part of its very foundations.
Take 2 or 3 teams of (really good) agile programmers, assign each to a local health authority and give them each a tiny budget (£10,000?) and see who can come up with the best/first working system.
If only the process of coding were more watchable...
However, I believe that the market for healthcare software in the UK is severely flawed, and there is little commercial incentive for companies to produce high quality products. Specifically,
1. As identified elsewhere on this thread, the procurement process generally does not reward quality or functionality above accountability / company financials.
2. The cost of sales is very high, and hospital trusts have no money. Therefore, suppliers will generally sell at a loss and require significant revenue through support contracts to make the contract viable. The business is all about lock-in, and there is very little customer demand for real interoperability between systems. Startups are unlikely to become profitable for a long time. It also means that customers resent suppliers for charging through the nose for an apparently trivial change to the software.
3. For any non-trivial IT solution, there are significant interoperability and business process differences between hospitals. You end up implementing a custom solution for each trust and have to absorb the operational costs associated with this. As a supplier, we spend a lot of time trying to get trusts to talk to each other to agree on standard processes, but really this needs to be done at a national level.
4. Many hospitals will roll their own solutions because it is "cheaper". A huge number of hospital systems have been written by doctors who dabble in programming and grow into a big ball of mud. Indeed, our product started out like this (although the doctor in question was smart enough to hire some programmers early on). For me, this shows the lack of experience in the IT departments which allow this to happen, as it is generally not the right way to go.
There are many other challenging aspects to this market, but it does feel like there are opportunities for good software companies to make a difference.
I do understand the project is huge and really very complicated, and naturally a difficult problem probably more so than is immediately obvious, but it is that very fact that makes it easy for poor engineering decisions to have a big impact.
Remember that scaling this kind of business is hard because you are selling peoples time - so for each salary you pay you can only sell it one time over. Compare and contrast with being a product company - I might spend a few weeks working on a product and then those few weeks of my salary can be sold over and over again.
The scaling of so many employees also brings massive overheads.
So yes - the day rates seem high but the margins can be pretty rubbish.
In my experience most of the programmers in these kind of companies are people who just do it for a job (as opposed to those of us who do it because we can't help it and are pleasantly surprised to discover people will pay us to do it :-) )
(I'm not looking for an answer like "They're gouging them because they can" - although I'm sure there is some of that going on - I'm actually interested in what are the purported costs, i.e. how could it even be seen to be the correct order of magnitude of expenditure)
Over a billion pounds was spent on the programme last year alone
seems to indicate that it's an accumulated number.
Also, I think it's a safe guess that a significant slice of that money is recurring license fees for many, many instances of very enterprisey software.
You first of all need to go into the procurement process. This pretty much starts with the principle that you need to know whose fault it is when it all goes wrong which kind of sets the tone for everything.
To be able to cope with the procurement you need quite a large and bureaucracy heavy setup to start with - the emphasis is on accountability not performance. Also the government moves very slowly - it is a very large organisation with few of the commercial pressures we in the private sector are used to - this leads to delays - which in turn lead to costs. The type of company that can cope with doing business with the government has a lot of overheads.
Secondly the government side is quite hampered with rules and regulations to prevent what you might characterise as corruption. This means a lot of stuff has to be done formally and that often brings delays (and expense). (I don't want to portray this as a bad thing - corruption is bad - but it does prevent a lot of agility IMO)
Thirdly the people on the government side often don't know what a successful IT project looks like and the people doing the procuring frequently won't be people who know anything about what they are buying (and the actual end users of the system will likely not be consulted until long after the procurement). To be fair to the procurers they really do try and get value for money - but way things are setup normally means that this can't be done in sensible ways.
It's one of those "well you wouldn't start from here" type things - and whats worse they do keep starting from here and it keeps going wrong.
Then they say, OK, we can do this, and it will cost that much. Any changes however to this spec will cost THAT much.
The bureaucrats say OK and work starts, then they realize that they need to make a whole slew of changes, since they didn't really know what they were doing in these meetings, none of them has ever worked in the NHS, they went straight from Oxbridge to the Civil Service Management Fast Track. But, whatever, it's only taxpayer's money, and Accenture did take us golfing that time.
So it goes. Fix is easy: any civil servant who overspends is dismissed with no severance and no pension. Then you'll see their interests aligned with ours.
To be fair though I think that the "its only taxpayers money" attitude is disappearing. But there are still so many other inefficiencies.
As for your fix. You try firing a civil servant and making it cost less than their salary plus pension.....
I can see you've never worked in the civil service. Promotion, possibly "sideways", is by far the more likely outcome for gross negligence. Sacking people for gross negligence is hard enough even in the private sector under uk law.
HR in the civil service is sh*t scared of the unions and strikes are an option of last resort. Virtually nothing gets that far.
Again as I've commented above it would require such a sea change both in law and process - all of which the unions would fight every last step of the way - that there are undoubtedly other lines of attack.
For example, check out the UK e-Borders system [1]. The spec, according to the article is
"Under the e-Borders scheme, immigration and government security systems will be linked with transportation hubs to check and log every passenger travelling in and out of the country."
On the face of it, it doesn't sound much more complicated than say the Diaspora project, and I'd fully expect a small group of YC-calibre hackers to put together a functioning prototype in a couple of months. It's obviously not that simple, but what do you expect when you hire a consortium consisting of Raytheon, Serco, Accenture, Detica, QinetiQ, Steria and Capgemeni [2]? Christ.
And how do you think the existing security systems that need linking to have been developed? Do you think there's an api?
[1] http://www.computing.co.uk/computing/news/2202536/borders-wi...
Implementations of complex systems in the commercial world (e.g. global ERP systems) often work best when the chance is taken to align the processes of the organization at the same time. I can't see that happening in the context of outsourced government projects - nobody has any incentive to reduce the amount of money spent.
the lack of incentive to cut is one thing.
The ability to see things that can be cut is the other piece of the jigsaw - and I guess this stems from exactly what you are talking about - its not been a necessary skill or a part of the process before.
In order to constrain costs both motive and ability to do so are essential.