Without sounding like Jesse from the fast show, this week I have been mostly doing blueprinting (he would of course have never said that).
As discussed last week, this is an attempt at sense-making more than anything else, and off the back of one call with Sussex about musculoskeletal (MSK) care in the community, it’s allowed us to see which bits we’ve got a reasonable handling of and which bits we don’t.
The next step will be to go back to them, sense check what we have, and dig deeper where necessary.
Up to this point, a lot of our information has come from publicly available reports, but these only help to a point. They give broadbrush insights onto MSK as a whole (the punishing waiting lists, the cost of people missing work due to lower back pain etc), but not enough of the detail as to what is really going on. And the ‘why’.
It struck me that there’s about four levels of work in the NHS.
Recognising and exploring the problem. Normally the work that allows you to do more work. It establishes a problem (MSK waiting lists and some of the reasons), and provides some insight into the repercussions of it. It’s a level of depth that makes you feel you know what’s going on, but not enough whereby you could actually start solving the problem.
Evidencing the problem properly. This is where we are. This is about going into depth, understanding what solutions have been attemped, why, and what impact they’ve had (or not). The workarounds. For this you need proper UCD work, and off the back of it you can document problems and their severity within a specific pathway, leading you to…
Exploring solutions. Sometimes these are quite obvious, sometimes not. But without the work done in step 2, you risk applying solutions to broadstroke problems and getting it wrong. I think this can happen. ‘We need to bring down waiting lists, so therefore we’re going to…’ without understanding the specifics of why the waiting lists are high. Does it happen more in complex environments? There’s an element of the political here: the detail is complicated and difficult to communicate. Ideally in this step you’re doing more UCD work to explore solutions, ideally with codesign. (And why you’ll be frustrated if you’re in UCD doing this work when step 2 has not been done.)
Executing solutions. Actually getting a decided upon solution to market. I would say that relatively speaking, steps 1–3 are easy compared to this one. Integrating systems is fucking hard, and that’s the reason things are not better than they are. We’re all sorry about that. But getting stuff delivered is really bloody hard work.
You could argue that a lot of this aligns to the service manual approach, with step 1 being pre-discovery, step 2 discovery, step 3 alpha, and step 4 beta. But that language doesn’t persist everywhere, and you could end up moving through steps in an uneven fashion.
For example, you could identify a problem, explore it specifically, and try and get something to market very quickly in a pilot. I believe this is roughly what test and learn in the cabinet office are doing.
So there you go then. Thoughts.
Reading it back, this blog seems to be an argument for good UCD work and the value of discovery and evidencing problems properly. Hardly revolutionary.
Felt good to write it down though.