The solution to failed Government IT projects is not better (whatever that is) technology – or another IT project that miraculously has some insight that the smart people working on the original project didn’t have. And yes, whatever you think, the people working on large IT projects are generally very smart people – but you are right that however smart they are, a very large number of Government IT projects fail.
Not just fail, but F A I L.
- Fail in a ‘£10bn Patient Records write off’ type fail
- Fail in a ‘still stuck with paper world print off and sign‘ type fail
- Fail in a ‘have you heard of Facebook or social networking‘ type fail
- Fail with a ‘45 minute application process with no save’ type fail
And my insightful piece of original input to this …?
The problem with failed IT projects is not the IT.
Not the technology, not what is built, not that painful unusable system. Not that slow, hard to use interface, or that unreliable program.
The seeds of failure, in fact the genetic code of IT failure is embedded into the Government IT project long before the technology is switched on. A computer is nothing more than a processor of information. It is a tool. It does what we tell it to do. It may have some machine learning, but the program has not developed itself, it is doing what a human has told it to do. Even with intelligent machines and artificial intelligence a human has defined the conditions and the boundaries of its operation.
The Government IT service delivered may be completely useless and not fit for purpose, but the problem is not the technology. It is the people and the processes that decided what the technology should do and how it should do it long before an exorbitantly expensive procurement process was started. [When you understand the process, you can understand why Government IT is always so expensive].
So if the technology is not the problem, then better technology is not the solution.
Whatever better technology is, it is still technology, so is missing the real source of the problem.
Better technology may help the end solution work better, but it is unlikely to be the best possible solution. So whatever you read in the IT press, a new platform, engine, database, open source codebase or new architecture is not going to magically solve the problem – regardless of what the evangelists and salesman tell you. A new platform may be better, but it is a better technology outcome, not necessarily a better service outcome.
The reason for this is that the starting point to solving any challenge begins with questions, not answers. Technology is a ‘how‘. It is an answer, but it is one of many possible answers. To validate whether the answer is correct we need to understand the context and boundaries of the question. This requires asking, ‘what‘ and ‘why‘ not just ‘how‘.
‘How‘ can only be answered with confidence once we know the answers to ‘what‘ and ‘why‘. You may also want to ask ‘when‘ and ‘where‘ too before moving onto ‘how‘.
So if the solution starts with understanding ‘what and ‘why‘ we need to look at the best people to do this. And this is not technology people.
Remember the old proverb, “If all you have is a hammer, everything looks like a nail“.
To IT people, everything is solvable by IT … in Government this typically means big monolithic, expensive, [very expensive] IT. Lovely BIG technology projects.
Instead we should look anthropologists, sociologists, scientists [whether data, social or behavioural]. Look for people who immerse themselves in the complexity of people. You may also want to involve advertisers, marketers, counsellors and psychologists. You want people who study people. You want who seek to learn about behaviour, how social situations work, how to influence, change behaviour and attain the desired action.
Perhaps more than anyone it is about designers.
It is not a great coder! Sorry.
It is not a database specialist. A statistician perhaps, but never someone who focuses on designing a potential technology solution before wanting to understand whether technology even has a role to play in the solution. It is not someone who jumps to a whiteboard proclaiming they know how to fix this. What you need is someone who leans forward and keep asking ‘why‘; inviting an ever increasing understanding of the problem.
Their goal is not to find the solution but to understand the problem and the relationship between this and the outcomes that are desired.
So does this fix Government IT problems?
There is one more critical change that needs to be made.
Stop Government IT projects.
Stop Government designing IT solutions.
Instead focus on understanding and defining the desired outcomes – and nothing else. State the problem as it is understand, then ask for ideas, proposals and thought on how to better understand the problem and qualify potential solutions. Not a solution, not a technology solution, but solutions to the problem.
Instead of appealing to technology companies, engage service designers, pressure groups, citizen bodies and the general public to help UNDERSTAND the problem and possible solutions. Not THE solution, but possible solutions. Note that this is plural.
Then test the solutions. Real world tests, with real people and real problems problems to validate proposed solutions. Prototype, mock-up, whatever method you want. At this stage you may want to involve technology people … but be mindful that technology is likely to be part of the solution, not THE solution.
Remember the golden question at this stage, “how do you know this to be true?”
or put more bluntly … “I don’t care what you think. Prove it. Show me the data”
At this point there is an interesting irony. We flip from being focusing on people and behaviour which are highly variable and often subjective (qualitative) to evidence of what works , which is the opposite; hard, quantitative and varifiable. We start with designers, but end with mathematicians and analysts. The order of course it critical. Do it the other way around and you can get beautiful square wheels; well designed, but useless.
Or in the case of Government IT you get ugly expensive square wheels.
And then when you have the data. When you have validated it, correlated input and output. When you know what works. When you know what matters. When you understand how to deliver the required outcome and can prove this … THEN … you can start looking at ‘how‘ to build the solution. Recognise that the best solution may be to learn from several prototypes and separate ideas. Open innovation is what you are looking for. Sharing ideas, sharing learning.
Then you can start to build the solution … knowing of course that what you have is the start of a journey of continual improvement; a development process that includes continual measuring and learning; a process of A/B testing and micro-changes to colour, single digit pixel layout changes, an obsession with the time taken to core complete tasks and manic reporting of incomplete transactions.
Looking at the recently announced Universal Benefit solution, and its widely reported 45 minute application process with no save functionality, it becomes painfully aware of how much change is still needed. When you see a design that no commercial IT company would ever support you know something is very wrong.
It is over 15 years since the original eGovernment visions were published. Personal technology and our relationship with it has completely been transformed, but most of government IT hasn’t moved a jot. Early visions of joined-up government are still in future roadmaps, after many billions spent on ‘integration’ and the development of digital services.
Government still wants to send me paper, thinks efficiency means more people and is still unable to conduct a conversation electronically through the channel of my choice. The myth of technology as a silver bullet capable of compensating for a lack of vision or clarity of strategy exists as much now as it ever did.
There are some beacons of hope though.
The Government Digital Service (GDS) is a team setup to transform government digital solutions. Its approach to user centred design, to shared learning and open engagement is a big step forward. My only concern is that the technology focused philosophy and a mandate that is driven by moving to digital channels risks making the same mistakes as previous projects, albeit with better designed websites. The assumption with GDS is still that the solution is a move to an integrated digital service. Surely this in itself is contrary to true user centred design principles, which don’t presume to define the solution before understanding the problem.
Surely there are government services that are not best delivered digitally? Ones where redesigning the roles people play, reengineering the flow of services, or the amending interaction between departments could deliver greater benefits than a better website?
A brilliant website is not a great deal of use to someone who is illiterate, dyslexic or simply uncomfortable with technology. Commercial companies increasingly respect this with many increasing the channels that they offer, maintaining telephone services, re-establishing face to face services and putting the quality of service experience as the primary metric regardless of the channel chosen.
Whilst healthcare, social services and education will benefit from better designed technology services, by limiting ourselves to electronic channels, we are potentially missing major improvements from rethinking and redesigned the human, social and cultural aspects of the service.
With the majority of business and citizen government services now online, perhaps we can move our attention from cost of provision to quality of outcome, allowing designers to innovate in something other than code and APIs?
Perhaps the recent Design of the Year award for gov.uk will give help give government the confidence to broaden the scope of the GDS. Such a win would have been almost unthinkable until the GDS was established. Perhaps the time is now right to trust its designers to tackle problems where the solution is not a digital service.
That really would be innovative.
This post is a rewritten version my response to an article in Computer Weekly about Government IT. The original post was to the Facebook page of one of the authors, Jerry Fishenden. His article was the fifth part of a series called the Great Deverticalisation that used the analogy of a High Street to highlight the differences between how small businesses and Government approached IT. This version takes a much broader perspective of the problem and the potential solution than the original Facebook reply.