However, after an initial trial and plans for release in mid-May, the app was scrapped after doubts were raised about its technical capabilities. Now, the Government has found itself back at square one to work with Google and Apple on a new app.

Even with a new digital solution on the way, it’s safe to say that confidence in the Government’s ability to deliver timely digital solutions, especially at a time when these are of paramount importance, is flagging.

That’s because the story of the NHSX app follows a familiar narrative. The mishap is reminiscent of the 2002 National Program for IT (NPfIT), which was set to revolutionise the use of healthcare informatics in the public sector by offering centralised electronic records and fast, reliable IT infrastructure. After nine years of work on the project which was punctuated by delays, stakeholder opposition and issues with implementation, the project was finally shelved, costing the tax payer a staggering £10 billion.

Yet, although these IT failures have set the public health sector back, there are lessons to be learned for the future where digital innovation is concerned.

Accept that risk is inevitable, manage it effectively

It is wholly unsurprising that with so much of the tax payer’s money at stake, institutions in the public sector are risk-averse when it comes to pursuing new ideas. However, it is precisely this reluctance to take a chance on new ideas that aren’t guaranteed to succeed that leads to the downfall of many large organisations on the path to digital innovation. Without a change in tack, efforts towards large-scale IT projects will continue to fall short.

Risk is a necessary part of developing technical new solutions, yet many large organisations favour a long-term, sequential process, with product requirements set in stone early on. With clear lines of authority and a rigid development plan in place, there is very little margin for error and institutions are forced to stay within the framework set out for them at the beginning of the project – even if it isn’t quite working out. This only makes resolving issues more difficult as and when they inevitably crop up.

Institutions in the public sector therefore should look to agile development processes for a more effective strategy. By revisiting progress regularly and working in shorter, more efficient bursts, iterative product design allows teams to properly gauge whether or not the technology is working, and suggest features and amendments that could add value, before more money is spent on scaling up.

Indeed, at each stage of development, a startup would have judiciously evaluated the rollout based on progress made, and perhaps more importantly, allowed some scope for flexibility to navigate any challenges encountered along the way. Only when an idea has been proven, the designs tested, and technical feasibility demonstrated would the resource then be spent on a larger scale deployment.

Agile development prevents information that was relevant at the product’s inception becoming irrelevant and outdated along the way, stopping projects from failing before they have even gotten off the ground.

That’s why in order for future IT projects to succeed, Governments must be willing to change their attitude where risk is concerned. By allowing their teams to fail little and often, larger, more costly mistakes can be avoided and issues with schedule predictability can be dealt with before a project spirals out of control.

Think more like a startup, and learn from mistakes

Most startups harbour the mentality that, like risk, some degree of failure is also inevitable as they transform a concept into a tangible product. In fact, often failure can be leveraged as a powerful tool to create more innovative solutions.

Like startups and SMEs, the Government should put into practice a similar process of failing incrementally and using the lessons learnt to pioneer new solutions, rather than allowing new ventures to become stifled by red tape and bureaucracy.

And these failures needn’t be huge or cataclysmic. Smaller teams appreciate the benefits of rapid prototyping, which encourages a persistent evaluation of the product. The process involves quickly mocking up what a system might look like in the end, and how it might work – with the purpose of finding out how the product will serve the public and if there are any changes needed to make it function better.

Trial and error are key in this process. The developer(s) would first create a prototype of the design which covers the core aspects of the product. Having a model of the end product enables teams to test its usability, performance and features, and developers can quickly modify features in line with the feedback that they get. In essence, this process of rapid prototyping speeds things up in the early stages and gives the team freedom to modify elements of the customised product along the way.

With a mindset shift, making mistakes becomes part and parcel of the development process and adds to the final product, rather than acting as a hindrance.

After all, it’s true that nobody can ever really know what the customer wants until various approaches have been tested and experimented with along with way. Initial user research and rounds of user testing should result in a proof of concept, but further rounds of testing are also required to refine the design and create a more fulfilling user experience.

Rather than relying solely on Big 4-syle relationships, the Government would do well to broaden the pool of expertise and utilise teams of all different sizes, backgrounds and experience – particularly in the discovery phase, where collective problem solving can foster a number of different solutions to a problem.

The public sector should also work to foster a culture where making mistakes and taking risks is encouraged, rather discouraged, early on in the process. By looking to, and learning from, smaller organisations, the public sector can truly deliver valuable digital solutions.