One of my most favoured touchstones is a sentiment first expressed by H L Mencken but ever since misquoted along these lines: “For every complex problem, there is an answer that is clear, simple, and wrong.”
I reach for it frequently in client meetings, discussions with my highly skilled operations team and anyone else who presents a requirement, specification or solution as a fait accompli. It has saved projects more times than I care to remember. But it is incomplete. The corollary is that complex, sophisticated solutions often obscure simple needs.
I lack a proper IT background – the last time I wrote a line of code was in Visual Basic 1 – so I have always tended to come at problems slightly differently. In particular, I look for the true business need and whether existing technology can be configured rather than assuming the need for custom development. After all, almost all organisations have similar core business needs and therefore it’s possible to prebuild much of what they are going to ask for.
I founded Cloud2 with my business partner eight years ago, after some great learning (and a spectacular falling out) with the managed services and development company we both worked for in York. We quickly became a Microsoft Gold Partner and one of the leading SharePoint companies supporting the NHS. So when, two years in, our Microsoft friends brought us a project at East Midlands Strategic Health Authority to help with the crisis in Referrals from GP to Hospitals we were totally up for it. “It’s simple”, said Microsoft, “they need some kind of portal to exchange information between GPs and Consultants to avoid unnecessary referrals. SharePoint can do that. Off you go.”
The rest of this column is some learning from this project…
I genuinely like Microsoft, the people and many of the technologies. Some people may find that odd, but the company’s techie mindset, the corporate market it addresses, the ground-breaking things it has actually established over the years and its commitment to the people it is trying to help (however disorganised and dysfunctional that is sometimes) has always worked for me. But I’m not blind: at times Microsoft’s sales teams have been targeted on what the company is focused on rather than what the market really wants. This was one of those times. SharePoint was a big deal to Microsoft for a while and everything looked like a SharePoint solution as a result.
Insight 1: When you get paid to swing a hammer everything looks like a nail.
As a sceptic by training, and with a background in health, I set out to discover what the NHS folk genuinely needed – and it rapidly became apparent this wasn’t a SharePoint problem. What the lead clinician and the project stakeholders envisioned was something that provided real-time chat between GPs and hospital specialists, with the ability to escalate to voice conversations, transfer documents and notes and share screens.
Today we would call this Skype for Business; back then it was Office Communication Server (OCS), a technology we couldn’t do. Fortunately, we were friends with a company that did and who were happy to collaborate on the project based on our NHS expertise. It was convinced it could customise the OCS interface and functionality to meet the need; the NHS team was sure that would be great and budget was duly approved.
After several months of toil, we rolled out the beta version. It was clunky, slow, complex, unstable and licence costs were scary. The client was initially happy. Then we showed it to the end user GPs. They didn’t get it at all; their working reality was that they would never have time for a chat session during the day, the consultants would never be at their PC anyway. Our prototype was what they had specified, but what people say they want is not what they need.
Insight 2: What they say they want is not what they need.
After much soul searching, conversations with potential users and a crisis meeting with the sponsoring CIO (a genuinely decent and honourable chap) we took the decision to write off the entire development and start again. £50K of development effort is a big decision when your turnover the previous year was £250K. But it was clear that we had built the right solution to the wrong problem. A different type of solution was needed; it still wasn’t SharePoint.
Insight 3: If it isn’t fit for purpose, don’t try to fix it up
We had to think hard about our development partner. Although technically strong, the people there struggled to see that real-time messaging wasn’t the answer: GPs were happy with something that could assure them of a response within a few days.
Ultimately we approached Bliss Systems in Wetherby; I knew its MD (physicists tend to attract each other) and had seen the company’s ability to work up innovative custom solutions. Also, it could do what we needed for the pitiful remains of our budget in the scant timescale remaining, loved the concept and was happy to do a joint IP arrangement. This time I stayed very close to the users to ensure that we were truly addressing the way they needed to operate.
GPs have remarkably little time; pesky patients turn up every ten minutes with some ailment, injury or concern in search of treatment and reassurance. GPs can’t know everything and don’t have time to research all the things they don’t have a quick answer to. If in doubt their professional and ethical duty is to refer to some other expert, via an outpatient appointment. They mostly do this at the end of the day via a hastily written referral or a dictated note to their reception staff. Time is acutely precious (pun intended).
They needed something simple, a minimally viable product. It really only needed to do three things: Enable users to quickly FIND an expert and ask them for advice; ensure a useful RESPONSE in a clinically meaningful timeframe (72 hours was the initial aspiration); track the OUTCOME of the request to see if the advice avoids a referral. Our target was to train groups of users in 15 minutes. We built the replacement using .NET and SQL Server – simple, fast, stable, secure and largely licence free.
Figure 1Fast, simple and consistent user interface design is critical to user acceptance.
Insight 4: Make it as simple as simple as possible (but no simpler).
Five years have passed since all this. The Strategic Health Authority finished the pilot successfully but the new government disbanded all such authorities, leaving further progress unsponsored. Its departing CIO gave the IP to us with the thought that there was “something in it and we should see if we could get it established”. Wandsworth Clinical Commissioning Group (CCG), a client for our SharePoint work, was searching for options to improve referrals and asked to pilot the technology. Its insights drove enhancements based on careful user feedback. Another CCG came on board. We rewrote the application to be a multi-tenant platform. Two more CCGs adopted it.
Figure 2 – Gaining user feedback helped us continually enhance the design and functions.
We realised that we were no longer the people with the best insights into the product, so we established a user steering group and put them in charge of identifying development needs and prioritising them, while ensuring that it remains simple for end users. Most enhancements have been on background business functionality with only subtle introduction of new user features. Training still takes 15 minutes.
Insight 5: Evolve both the technology and the innovation process. Consider putting your users in charge.
Out most successful users have really worked at it. They have driven adoption across their GP practices and hospitals and evangelised the benefits (not the system). They have actively sought user feedback and brought that to us to address. They understand that for every early adopter there will be a laggard – such is the nature of diffusion of innovation – and acted to bring on those in undecided ground between. They recognise that great technology is only 10% of any effective solution.
Insight 6: Great technology is only 10% of any effective solution.
Today we have a technology platform that is about two years ahead of anything in the market, driven by users, and currently generating around £1 million net savings for the NHS per year; it has the potential to save around half a billion pounds per year as we roll it out to further clients and as GPs increase their use. It’s gradually growing as GPs and specialists extol the virtues to their friends and colleagues; almost all our new leads come through referrals as a result. Real patients are being kept out of hospitals.
Figure 3 – Thousands of outpatient appointments are avoided per year as well as many urgent admissions.
We still haven’t made the national breakthrough I believe that it deserves, but my clients love it and that makes me happy. The outcomes data says that one patient avoids going to hospital for every two requests for advice put through the system; that makes me happy too. We are on track to double the client base this year. There is talk of moving the entire thing onto the Azure platform to deal with growth, resilience and performance. That makes Microsoft happy.
Insight 7: Success rarely happens overnight. Believe hard and keep the faith.
We are beginning to get some recognition, including a recent article on The Guardian’s site about how GPs in south London are reducing hospital referrals as a result of the technology (pcpro.link/266health).
As I reflect on what it has taken to build a successful technology for the health sector, with the benefit of my hindsight augmented goggles, it seems obvious that one should always ensure that the real world user need is understood rather than being based on assumptions and Chinese whispers, that being trusted and liked by your clients enough that you can admit when you have collectively got it wrong and work together to start again is a core business and personal principle and, ultimately, the trick is to find a balance between the complex and the simple. If it doesn’t match what happens in the real world then you can’t drive user adoption, regardless of the density of clever technical features you might have built in.