If you always buy what you've always bought...

What motivates an organisation to consider changing a system?

The system doesn’t do what you need it to.
The users don’t like it.
Information governance wasn’t adequate.
The system didn’t change with your needs.
It is too expensive.
The support isn’t good enough.

In my experience, the focus isn’t always where it should be when procuring a system. Typically, an organisation will primarily list out the features and functions they require to complete a task. This will form the basis for their choice, but what if additional features or functionality is required over time? We all know that it can be a painful process to swap out systems, especially if we then get it wrong again.

When I worked in the NHS, I was responsible for several systems, many of which were inherited. If there was a general feeling that a system needed to be changed, whether it be due to bad user experience or it was no longer fit for purpose, I would start by asking the following questions:

What didn’t we do last time that led us to this situation?
What do we need to do differently to make sure it doesn’t happen again?

Learning from your mistakes is one thing. Putting what you’ve learned into practice is another. This led me to consider what the focus of procuring either a new system or replacing an old one should be. This is not an exhaustive list but a good starting point:

What problem are we trying to solve?
What happens if the problem changes over time?
Who will the software impact?
What outcome do we require from a successful rollout?
What sort of provider do we need to achieve these goals?

Without a focus on those points, the outcome of procuring a system is likely to be small incremental gains, getting something that is marginally better at doing what you already do. I would go as far as saying that following certain tender routines can lead to little by way of solving your problem as they look at all providers through a restricted lens. From the point of view of a supplier, it feels like the customer is presenting you with the solution and not the problem and expecting you to have already developed a system to meet that pre-determined outcome. Don’t get me wrong you can get pretty close by running the process this way, but it will still inevitably lead to churn. Especially if your focus is on: what do I need to support this process today? And not: what happens if the process evolves and changes tomorrow?

Tenders become a beauty pageant based on system functionality and cost. In my opinion this is the wrong approach, the most important focus should be: what sort of provider do we need to achieve the required outcome both now and in the future? Does the provider have great support for end users and stakeholders? Are they agile and practice continuous development? Do they consider the user journey? Do they put emphasis on the systems outputs and data flow? Do they understand how systems interact with each other? Are they accessible? What experience and pedigree do they have? After all we are in the SaaS market, but the ‘as a service’ seems to be M.I.A.

Of course, system functionality is very important, there is no point in having a great provider and a useless system. However, great providers tend to have the capacity to provide you with what you really need, when you need it and have a history of delivering. As I write this I can hear many people asking, is this not an expensive approach? The answer is that it doesn’t need to be and even if it may be more expensive initially than a straight head-to-head tender, how much does continually having to change system and provider’s cost? How much does it cost to stick with a system that you need to create your own workarounds for, deploying staff from other areas? How much does it cost to invest in providers that make bad technical choices And how expensive is non engagement in a trust?

We get asked almost weekly to develop new systems for our existing clients and by doing so, wherever possible, our company grows both in product range and the relevance of systems we can provide. Team Job Planning is the most recent and successful example of this.

When I take all of this into account I wonder, is the ongoing churn of systems within the NHS down to game changing innovation that requires change or are trusts just searching for the least worst option? My fear is the latter. But by changing our mindset and our approach we have the choice to engage with innovation, to see real improvements and to banish cyclical change.

If you are ready for real change and to propel your Trust forward, book a demo or email chris@sardjv.co.uk for an informal chat with us.