The paradox of ambition

We have information technology projects in healthcare which are hugely ambitious in their scope - for example, the nursing documentation project in Wales - in which there are many requirements, interactions, dependencies and fundamentally so many issues of change management required across multiple organisations, that it is hugely ambitious as a result of it being really very difficult. That worries me, because ambition to solve something that is extremely difficult is misplaced ambition.

Welsh Senedd meeting on nursing documentation project

The right kind of ambition is ambition to make a difference and deliver value at pace.

So when we talk about nursing documentation, it is ambitious because I think, the project, as currently designed, will just not work. The approach is just wrong; it needs to be something driven from the bottom-up and not the top-down. What the top-down should be doing is setting the direction of travel, setting the rulebook, giving the users and the people who work on their behalf the tools to solve their problems. You need to get software in the hands of users as soon as possible in order to more fully understand the problems you are trying to solve; a more agile approach is required.

The right kind of ambition is to deliver. So what I mean by ambition is that I want to have my consultations recorded and my dictation to order blood investigations automatically. Who will be the first to deploy “Amazon Echo” or “Google Home” in the clinic to support my outpatient consultations? How can we enable that innovative future? We do it by creating an appropriate open services-based architecture and allow multiple applications to use those services.

So sure, build test requesting into a portal but don’t build the whole stack of functionality into that single codebase so it is inaccessible to any other application. Likewise, don’t build a service that only one application can use. Break it up, make test requesting a service. Make the applications, such as Welsh Clinical Portal, use that service. Don’t make any single application mandating for use.

So then if we come along and want to get Amazon or Apple or Google to listen to our speech in clinic, to turn that speech into text and make a range of test requests based on that text, then don’t stop us doing that. Create something that enables that. Enable innovation and don’t suffocate it.

There is another paradox here in that I keep repeating in this forum and others, that we don’t know all the stuff we need to solve. We need to look really hard at people who think that they have all of the answers, because they don’t. Getting everyone in a room, and listing the requirements, building a technical specification and building it like it was a bridge, is not the way to build software.

Be ambitious, be realistic. Have a vision and plan to deliver that vision incrementally at pace.