Months ago, when the UK was in the midst of a nationwide lockdown brought on by the outbreak of Covid-19, Health Secretary Matt Hancock announced the release of an NHSX contact-tracing app that would be at the heart of the Government’s strategy to ease restrictions.
Although the app was touted for a mid-May release, after a trial on the Isle of Wight and £12m of public funding spent on development, plans for a wider release were culled after it transpired that the app didn’t work on Apple devices, sending the Government back to the drawing board to work with Apple and Google on a new app.
Measures may have eased since then, but the Government has still yet to deliver on a technical solution for contact tracing. Another project punctuated with months of delay and millions of pounds of taxpayers’ money wasted – the story with the app follows a familiar narrative.
When it was announced back in 2005, the National Program for IT (NPfIT) was set to be the largest public-sector IT programme ever attempted in the UK, one that would see the NHS into the digital age, offering centralised patient records and a faster, more reliable IT infrastructure. Despite such grand designs for digital transformation, the Government overpromised and underdelivered. After nine years’ work, marked by stakeholder opposition, delays and an ultimate failure to communicate clearly with end users, the project was scrapped in 2011, setting the government back a staggering £10bn in public spending.
With a history of poorly executed IT projects, what can the Government learn from its past mistakes, in order to redouble its efforts to deliver on digital innovation in the future?
It is no secret that the Government often lags behind on digital-transformation projects due to a restrictive bureaucratic culture. As larger institutions – in both the private and public sectors alike – tend to be constrained by excessive red tape, it can be difficult to take a chance on novel ideas due to the high level of risk involved.
The Government mantra seems to be that “failure is not an option”. Indeed, with so much public money at stake, the public sector favours long-term, sequential processes when it comes to building new technology. Requirements are set in stone early on in the development process, without any scope for change or margin for error.
While defaulting to overly formal processes like this might give off the impression that the safety and success of a new venture lies in the details of a well thought-out plan, having development schedules laid out so far in advance can actually be inhibiting. In fact, these efforts to minimise risk often result in delays and running into problems that could have otherwise been avoided. Developers might, for example, find that the information gathered at the beginning of the project is no longer of any use months down the line, as new developments render the envisioned project largely obsolete.
That’s why the Government needs to look to agile development – leaner, more efficient ways of working – that allow more scope for flexibility and changes that might occur throughout the process. By working in shorter, more efficient ‘bursts’ of activity and re-evaluating work regularly, public institutions can produce more innovative solutions with a quicker turnaround. This way of working prevents the entire project from failing entirely when issues crop up, as features are delivered gradually, leaving some much-needed breathing room for developers to resolve issues as and when they arise.
The key to innovation is iterative design; that’s why the Government should tap into a startup mentality when pursuing large-scale digital transformation projects.
It’s true that nobody really knows what the customer needs until developers have experimented with a variety of different approaches. One of the main criticisms of the NPfIT, for example, was the lack of proper testing and consultation with the hospitals, clinicians and patients who would ultimately be the end-users of the software.
The Government would do well to learn from this in order to improve user experience in the future. Conducting initial user research will ensure proof of concept, but further rounds of user testing are needed to enhance the user experience and ensure that every aspect of the final product serves a purpose. After all, it is generally the public that will be the ultimate beneficiary of the technology. That’s why it is of vital importance to test, learn what’s needed early on in the process and iterate on it, step by step. In this way, any issues with a product can be ironed out before it’s too late.
Rapid prototyping is an invaluable approach that ensures any risks taken don’t have to be momentous – smaller, faster teams appreciate the importance of quickly mocking up what a system will look like and testing it, before precious time and resource is spent on developing the end-result. This process also serves to speed things up in the early stages, while giving the team the freedom to modify elements of the product along the way.
Rather than relying solely on large vendors to deliver technical solutions, the public sector should leverage smaller organisations as an asset and a useful testbed for innovation. Various participants of all sizes, backgrounds, and experience should be encouraged to work on a given project to foster enhanced problem-solving.
This is especially important for the discovery phase. Having as many outside opinions as possible will help to effectively unpack ideas and create a plan of execution. Broadening the pool of expertise and collectively brainstorming a number of possible solutions to a problem, rather than focusing on just one, will no doubt pay dividends in the long run.
All in all, it’s clear that when it comes to digital transformation, the Government needs to learn to fail better and pursue more out-of-the-box thinking. By tapping into a startup mentality and learning from its smaller counterparts, the public sector can rejuvenate its approach to developing ambitious IT projects, and truly move along the path to a digital future.