The aim of this webinar is to provide an opportunity for clinical and non-clinical staff working in a healthcare environment to better understand what is involved in structured problem solving, as well as the foundation elements required to lead and sustain changes. You can view the presentation slides from the webinar here.

Simon

Got it? All right. I’ll introduce myself – so my name is Simon Craig. For those of you I haven’t met, I’m looking through the names, there’s a couple people there I know but most of you guys I haven’t met. so my name is Simon Craig and I’m the industry coach with Better Care Victoria. Primarily I’m working with the emergency access collaborative. Emergency access collaborative I’ve been working with other health services on that so –

Participant 

I think we’ve logged in but – 

Simon

The other part of my role is supporting capability across the sector as well, it’s really – 

Participant 

[other inaudible voices] That’s all good – move the volume down just a little bit –

Simon

What I might do is I might get everyone to just so that we can, so that we’re not interrupting each other. We’ll get going like I said, please use the chat box if you want to get in contact and ask any questions and we can go through them. So what we’re gonna go through today is – actually make sure I can do this – firstly an introduction of problem solving and then later on we’ll go into the environmental conditions, if you like, the organisational environmental conditions to ensure that problem solving can work in your organisations.  All well and good to have our structure and understand how problem solving works, but if we don’t have a, an environment that supports that within a health service, it’s all really for nothing. So, but firstly an introduction to problem solving. For anyone who’s spent any amount of time with me, you’ll know that I’m quite passionate about problem solving, it’s actually really important. The reason problem solving is so important is because, at the most fundamental level, they can’t solve problems, they can’t improve, and improvement is what we’re about here at Better Care Victoria. This slide here, what we’re trying to show is, if you look at this graph on the left – let me just draw – let me just make sure – on here, you see how our performance before – whatever it might be – it might be safety, it might be quality, it might be length of stay, whatever it is – at the moment, before we do anything, there’s a gap between where we need to be and where our target is. And of course we call that a problem. We’re not achieving what we need to be, and because we’re not achieving where we need to be we consider that a problem, and it’s something we need to fix and I think we’re all familiar with that. The act of improving our performance from here to here, typically we call that problem solving, or improvement, and hopefully we can achieve our target. Now the reason this is relevant is because that target line there, that red line, is arbitrary in the real world. In the real world, on a ward or in an emergency department or an outpatient clinic – whatever it is, that target line doesn’t actually exist at the front line when we’re doing our work. This line only really exists on graphs. So if we move over here to the graph on the right, we still got this step – this step from before to after, where we’ve changed our performance we’ve increased our performance. The only difference between these two graphs apart from the scale if you like – but the only difference is where the target line is. Over here we call this a problem because we are below our target line, over here we call this improvement because we’re already at our target line or we’re ahead of our target line. The reason that’s so important is because this act – the act of going from before to after – it doesn’t matter where the target line is – like I said, the target line is largely irrelevant to people who work on the front line the people who are doing the work – that target line doesn’t really exist. So if we say well why is problem solving so important and why are we here talking about this – that’s it. The reason is because it’s not just about problems, it’s about improving anything we do to improve, we can use a structured problem solving approach to achieve that. I’ll make sure my computer works we’ll move onto the next slide. It’s a bit of a light-hearted look at why we use structured problem solving. That neighbourhood implemented gates and it improved their safety. We should have a gate. What we often see is when we don’t use structured problem solving, we fix problems that aren’t problems, or we fix problems incorrectly by assuming things. So in this case, again, quite a light-hearted look at it – we’ve picked up a solution from someone else, we haven’t really understood what our problem is because we didn’t have a structured problem solving approach to it. We’ve implemented a solution, hoping we’re gonna get the same results as someone else. And obviously in this case it’s not gonna prove anything. 

So why do we use structured problem solving? The main reason we use structured problem solving is to manage human instinct. Human instinct is to fix – we feel like we are adding value when we’re making change, we feel like we’re adding value when we’re doing something. And unfortunately, in problem solving, doing something, if you like fixing or changing without understanding often leads to wasted effort and frustration and in actual fact it can lead to more problem than it’s worth and if you think about your own work, and you think about change that has occurred in the last year or two years or previous jobs that you’ve had, and think about where change has been implemented without real deep understanding of what’s happening or what’s required – what you’ll find is there will be frustration and confusion and perhaps things go backwards rather than forwards. So, this is the number one reason why we use structured problem solving, to manage human instinct. Our instinct, all of our instincts, tends to be to jump forward to try and improve and we really need to make sure that we hold back on that bit and we don’t rush forward. Secondly, we need to collaborate and collaborate across health services but particularly here we’re talking about within a health service. If everyone in the health service solves problems or addresses problems or approaches problems in a different way, what happens is no one can actually support anyone else and the reason that is is because no one is predictable to anyone else. So if I solve problems different to someone who’s in a different department to me, to get that personal ward, to get that person engaged and working with me, is actually impossible. They don’t know what I’m gonna do, I’m not predictable and because I’m not predictable we tend to not work together and we go back to siloed working where we improve our part of the organisation and we improve our division, but we’re not able to work across divisions or across health services. I guess an extension of that is to build organisational and individual capability. If we have a structured approach, we have a standardised approach we can train people in that approach and if we can train people we can build organisational capability. If I have my own way of solving problems, even though it might be structured, if I have my own way of solving problems, it’s very difficult for me to be able to train other people, and it’s very difficult then for me to be able to build organisational capability. Maybe I can build individual capability, but we have a real struggle trying to build organisational capability. If you like to put it most simply, structured problem solving is more effective. I’ve done this quite a lot in my career, and more structured and the more methodical problem solving it is, the more successful it tends to be. So if we – for no other reason, that success or how well it works, if for no other reason, it actually is most successful. So – they’re the main reasons we might want to use structured problem solving.

I’m sure I’m talking to a lot of people here who have experience in problem solving or improvement methodologies and often there’s some discussion about well which one should we use and what is our framework – what is our methodology. And sometimes a bit of evangelical kind of discussion around which one is better and which one we should use. So here I’ve got five different approaches, practical problem solving, a Toyota approach, we got the eight D, or the eight disciplines, which some of you might have heard of, you got the C4, the concern, cause, countermeasure, confirm, you got DMAIC, for those of you or anyone who’s done anything with six sigma you might be familiar with the DMAIC approach, and you got the plan, do, check, act, or plan, do, study, act, which is the DMAIC approach to improvement. In actual fact, this plan do study act is quite popular and I’m sure most of you have probably heard of this within the healthcare industry. A bit of a secret for you guys, they’re all great and fundamentally they all cover the same steps. So someone asked me a little while ago about what my approach is and where I like to and which methodology, and I heard from someone and I’ve stolen this saying, that I’m methodology agnostic. I don’t really mind and the reason I don’t mind is because they actually all do the same. I’ll start with plan do study act because I think that generally speaking we understand this, there’s an awareness of what plan do study act is within the health services so let’s start with that firstly and then we’ll talk about where I think we need to go. 

So our plan do study act for those who are not familiar let me just quickly step through it – our plan is we understand the current situation, we see what the problems are, we plan what we wanna do about it. Then we do – we implement – in a controlled way hopefully, but we implement what we’ve identified as needs to be changed. We then study it, so we check, basically we’re checking whether what we’ve done has improved what we set out to improve. And then we act and so this act depends on what happens in the study – if the study found that we didn’t improve, or we went backwards, hopefully not, but if we went backwards, this act will be to go back and make another plan and start again. So, we’re in a bit of a cycle. If our study found that it was successful, our act will be to standardise perhaps spread and scale what we’ve learnt. Now, if you look at the scale, this is almost like a timeline here, this is typically how we do problem solving. We do a little bit of planning, a lot of doing, a bit of study, and then a lot of act, which tends to be rework where we change things. What we need to be doing though, is this – we need to do a lot more planning. The doing, if we do a lot more planning, the doing should take a lot less time. It’ll be a lot easier to implement, it’ll be a lot easier, we won’t come across as many unseen barriers. Certainly we need to study to make sure that what we’ve done has been successful, and if we’ve done our planning well and thoroughly enough, this act will be easy because we won’t need to rework so much it’ll be mainly standardising, spreading, scaling. Now the reason I show you this slide here is because, again, we all understand PDSA, or a lot of us would be familiar with PDSA. But I’m not gonna use PDSA today, I don’t wanna use PDSA today because what happens is, in PDSA, you’ve only got one stage for this, all of this planning, and this planning is really important. And so, if we just designate that as one stage, sometimes we wanna rush through it, we wanna get to the next stage, we wanna complete something, almost like a list like we wanna tick something off the list, we wanna progress to the next stage, and so the intent tends to be right, we gotta get into the doing stage. If we’ve got two projects, one’s running like this, the top, and one’s running like this, at this point here, we will feel like this project’s actually doing a lot better job and so the trap we can fall into is to speed this process up and say, right, come on, we’ve planned enough, let’s jump into the do. So what I’d like to do is I’d like to break this plan up a little bit. I have no problem with PDSA, except that this planning is quite a large chunk, we need to break this up. 

So, I tend to use a DMAIC process. For those of you who’ve been involved in six sigma, like I said you may be familiar with this, but what it does is it actually breaks up our plan so we define our problem, we measure to understand, to deeply understand what’s happening in our problem, we analyse our causes, we design and implement improvements, and we control our model of it over time. If we look at that against our PDSA, what you’ll see is define, measure analyse and part of improve are all part of that planning stage. And so let me sorry, couple of people asking me to mute this, you got it guys. Got it. If we have a look here, here’s our PDSA down the side here, and you see how big that plan is. When we draw them as quadrants, and I’ve seen PDSA drawn as a little quadrant with one, two, three, four equal stages, it doesn’t give us good enough clarity. It doesn’t give us good enough understanding of how important this plan stage is. So, this is why, for today anyway, we will use the DMAIC process to make sure that we understand deeply what we need to do in this plan stage. 

What it also does is that it allows us to do what we want which is tick things off and move forward. So, we can define and move forward into another stage which is measure and then we can move forward into analyse. Whereas if you were using PDSA, you need to get through all of this before you get to almost tick a box. So, just quickly, we’ll go through here. Define is all about identifying the gap between where we are and where we want to be. That might be a gap to our target, where we, our target from the organisation, or from the department or from wherever, or it might be a target that we set ourselves. So we’re already achieving our targets, but we set a target up above that. Once we’ve identified that gap we measure and what we’re doing by measuring, is we are understanding, we are understanding what that gap is. So we’re unpacking that gap and giving us a bit more clarity, a bit more granularity around what that gap is and we’ll talk about how that works but this is the most important stage. If we don’t get this stage right, the rest of it can often be a complete waste. Our third stage is analyse and this is where, because we now deeply understand through the define and measure stage we understand what the problem is, we can now start to analyse well what is causing it, what’s driving these problems. Once we understand our root cause, and we’ll talk about how we get to our root cause, once we understand our root cause, we can then start to design and improve – uh design and implement improvements. This is the easy bit, because this is what people wanna do. So the hard part is holding back, holding back, not allowing people to go forward. Once we understand the root cause, then we can move forward and we get to allow people to do what they want which is identify and design changes. Then we obviously we improve those in a controlled fashion and we then monitor that over time to make sure that we don’t slip and that when we do sustain it, we’re spreading that learning to other org – to other parts of the organisation. 

Before jumping in, and this is an important part and this has to be done at this point because if we don’t do this at this stage, the later we uh, the later we leave these things the more difficult they become. So, firstly, we need to establish a team. And in a team there are four key roles within each team. Firstly there’s our project sponsor. Our project sponsor is our senior management or executive, lead if you like of the project and their role broadly speaking is to provide us with one direction, make sure that we’re heading in the right direction and that we’re trying to achieve the right things, so our targets are appropriate targets based on what we’re trying to achieve as an organisation, but also to remove roadblocks and often when we’re – especially when we’re working across silos or across divisions within organisations, we’ll come across roadblocks which might not necessarily be within our scope of influence or our authority and remit. So we need our project sponsors to help us with that but really, that’s what they’re there for. Provide us with direction and help us remove or get around roadblocks. Our project lead is the person who is now leading the project. So this won’t be executive level, and ideally will be some leadership level from within the organisation, from within the operation, or clinical hierarchy. So it might be a NUM, or an aux major or ANUM perhaps or a head of unit or it might just even be a, you know, doctor, or senior nurse or whoever. But the key there is that the project lead should be from within the team or within the area that’s being affected by the change or by the problem. Then we have our project team and our project team should be made up of basically the stakeholders – basically the people who are going to be affected by one the problem that’s currently occurring, so people are being frustrated perhaps, or being impacted in their daily job because of the problem, but also people who will be affected by potential changes so we’ve also gotta think up and down the patient journey about what other parts of the patient journey may be affected through our problem solving or change event. Then at the bottom we got our problem solving subject matter expert, and this tends to be our redesign leads, or improvement coach or quality manager, those types of people. Now, this is important – this role is very important from a project point of view but we do need to make a very clear distinction between project lead and problem solving SME, they’re not the same thing. If we use them as the same thing, what tends to happen is the organisation can’t solve problems by themselves because what we do is we ask these people to solve all the problems or to lead the problem solving. Now within any organisation, doesn’t matter whether it’s healthcare or not, but particularly within healthcare, there are a lot more people who are able to lead a team than there are these people, and rightly so, the amount of NUMs and ANUMs and nurse in charge and head of units and aux managers – there’s perhaps a hundred of these within a large health service whereas you only got a handful of these guys and again, rightly so. By having these guys leading projects, you’re essentially limiting the ability or capability of an organisation to their workload, to their capacity. So, please when you’re thinking about your teams, make that distinction. These are not the same, they shouldn’t be the same, but this role here should just be support – primarily to support that leader. The other things we might want to look at are project structure so today we’re going through the DMAIC process, but whatever process you’re using, it doesn’t really matter as long as we got those main steps are, are there, that we establish that structure and the people in that team understand what the structure is so that things are predictable, things aren’t gonna be surprises to people and they can see what’s happening. People like to see a roadmap ahead of them. The only other thing we need is project time and reporting and really this is just back into the sponsor, and back into the broader team, not the project team but the broader team who will be affected, so there’s a regular cadence of reporting and communication. This is much the same as what we said before, the only additional thing here is this bottom one which is there is no hierarchy in the team and this is pretty hard, it’s not an easy thing to do, but we need to try and break down hierarchy and the easiest example I can use is, in the medical teams, if you have a consultant and a registrar and a resident and an intern all sitting there, if you don’t actively try to remove hierarchy in that meeting, I’m not saying in business as usual, but in the meeting if you don’t try and remove hierarchy, what tends to happen is a consultant will assume spokesperson duties for the medical team. Now, the problem with that is we don’t get to hear from the people who are doing, and the same occurs with nursing staff. So if you’ve got a NUM in a room with a junior nurse, the NUM or the ANUM will tend to assume spokesperson duties on behalf of the nursing staff so what we need to do is we need to break down the hierarchies and allow everyone to have a voice. We’ve got a nice little sentence here and it sounds very easy on the PowerPoint presentation, it’s not easy but it’s very, very important – if we can’t do this, we’re gonna really struggle to unpack some of our problems effectively. 

So let’s jump into it – our first step is define. Some of you might have seen this before and anyone who’s used A3 reporting will be familiar with this kind of approach. The definition of a problem is a gap between where we want to be and where we currently are and this is important because if we know where we want to be, we can align a team, we can build a team behind how do we get to where we want to be. When we don’t have an ideal condition, there is a risk that the team will diverge in where they’re trying to head. They’re actually – even though they might be thinking the same thing or we’re talking the same thing, there are just very small differences in the way they’re thinking about it, and that will cause confusion and divergence within that team. So it’s very important to establish an ideal condition or a target condition and the reason we want to do that is because that becomes our gap, our gap then becomes our definition of the problem. Ideally at this point, and this is where I’m gonna be quite pragmatic as opposed to evangelical about it, ideally this should be quantifiable. At this early stage we should have a quantifiable gap, you know, x percentage, or x number of patients or x number of hours, length of stay, whatever it is, this should be quantifiable. If it’s not, however, we shouldn’t allow that to stop our problem solving at this stage, as long as we can see a gap and we can understand the gap, we understand what ideal condition looks like, we should allow it to go forward into the measure phase and in the measure phase, we’ll be able to backfill where that current gap is and add some numbers to it or quantify it in some particular way. So on this slide the important bit here is this – the ideal condition – if we can understand the ideal condition, we’re gonna establish a gap and from there that gap becomes our problem. At this stage we also wanna establish a target. I won’t harp on this one too long because I’m sure most of you will be familiar with this but we wanna look at our targets and we need to make sure that they are smart, and not smart as in intelligent, that, of course that helps, but smart as in S.M.A.R.T. The A and the R depend on the school of thought and might be around differently but they tell the same story. So specific – the scope should be clear, we should be specific about what we’re trying to achieve, is it a specific patient cohort, is it a specific campus, is it a specific time of the day, whatever it is, it should be measurable, again, this might be difficult sometimes and if it is so be it we will move on and can backfill it but the target should be measurable. And the reason that’s important is for two reasons. One, an improvement of one percent and an improvement of twenty percent for any particular area will require different resources, different approach and maybe different scale of project. And if we don’t define what that scale is, it’s very difficult to understand how we should be going. And thanks for pointing out that appropriate is spelt wrong, that was a test and you passed the test [laughter]. Appropriate – this is where our executive sponsorship come into play. This is where we test that we make sure that our target is in line with where we want to be achieve –  where we want to be focusing or heading. It’s no good to improve in an area that doesn’t help us as an organisation or doesn’t help the overall patient journey. So appropriateness is a test that – wait a second – as a discrete project we’re heading in the right direction. Realistic, given the time, the scope, the resource and our authority that we have, we need to be setting realistic targets. So, we don’t wanna – well, we’d like to – we’d love to fix everything in one step but, for the most part, that’s gonna be unrealistic. So let’s make sure that our targets are realistic and we give our teams a chance to succeed. And the last one there is timebounded and let’s make sure that it’s clear when we need to be achieving this and it’s not a five year project. If we expect it to be done in six months, we need to make that clear up front. Because very similar to what we talk about with measurable, what might be required to achieve a result in six months will be very different in terms of what is required to achieve a result in two years. The only other thing I hear is sometimes the gap will be a gap between where we are and where we wanna be will be too big for one project – and so we might have to break that target down and that’s ok, as long as we understand that as an organisation and as a project. 

So measure – sorry so, define is really that easy. It’s really about establishing where we are, and where we should be, and identifying that gap, making sure that everyone in that team understands that gap. For those of you who have used A3’s before, you’ll be familiar with how small that little section of the A3 is. It is small, and it is deliberately small because it’s not detailed and really shouldn’t take all that long, but it does get us started, it does start to align the team. Think about the projects you guys are working on at the moment, and about whether you can define that gap. And if you can’t define that gap, my advice to you is to go back and double check and confirm that we know what we’re trying do, that we know where we’re trying to head and our true north if you like, is clear. So what we’ll do is we’ll move on because I’m already way over time, like I usually am, onto measure.

So measure is all about understanding that gap that we’ve establish. So we establish a gap in the define stage and that’s all very well and good, but unless we understand the detail of that gap, it’s very difficult to understand what’s driving it, what our causes are and therefore what we need to do to improve it. So measure is about understanding the depth of knowledge about what our gap is. There’s two main targets or two main goals to our measure phase – one is to understand and establish that depth of knowledge of our process – so we really want to deeply understand what is that gap, and what that’ll do is it’ll allow us to identify specific areas for improvement, if you like, scope the project down and make the problem smaller. If we can make the problem smaller, our chance of improving or our chance of addressing that effectively are significantly improved. And the second one is to establish baseline performers with reliable data. So this is our chance to make sure that we understand what our current condition is, and to go back to our define stage and make sure we understand that that gap is clearly articulated with data of some sort. The baseline of the project and therefore where we wanna be heading. I’m a simple guy and I like to remember things in simple ways so when I think measure, I think four W’s and one H and some of you might be familiar with this but I’ll go through it anyway. If we can understand the four W’s and the one H of the problem, and we are able to understand that well, we then understand the problem well enough to progress into the analyse phase. The four W’s and all the W’s except for why – we don’t ask why at this stage and this is the only W we don’t ask and we deliberately don’t ask why because until you know more detail about the problem, you can’t ask why it’s happening. So, let me quickly go through them, we’ll ask what, so what’s happening. For instance, the best example, the easiest example for us all to understand here is, if we have problems with paperwork, errors with paperwork or errors let’s say, with a script, so we’re getting scripts from the doctor but there are errors on them that have to be reworked – the what in that circumstance or in that example would be what errors are we seeing? Are they, is it missing information, is it wrong information, is it written in the wrong area? Are they using the wrong form? Is it – if we can understand that, we can reduce the scope of our problem. When we reduce the scope of our problem, our project becomes smaller and therefore easier to fix. When is – when do problems occur, or when is this occurring – it might be a time of day, it might be a time of the month, it might be seasonal, so it might be a month of the year, or months of the year. And critically, when don’t they occur. This is important because if we know when they don’t occur we can actually understand what’s different between when they do occur and don’t occur and that might give us a clue in terms of  what drivers behind the problem are. So, asking when they occur is another way of reducing that scope and making sure that we’re clear about where those problems are and where we should be focusing moving forward rather than on everything. Where – are where the problems being identified or originated. So it might be, for instance, if we’re looking at a patient journey, where are the patients coming from, where are they going to, it might be where in the hospital is the problem occurring – is it happening in ED or inpatient, or is it in our subacute areas or is it in our residential care or – if we understand that, again, we can understand that our problems are a bit smaller, again smaller problems can be fixed a little bit more easily. So a good example of this, a really easy example to understand would be if we have people getting sick across Australia with this mysterious disease at the rate of one percent, Australia’s a big country and it’s a big project to start looking at that. So how do we start that? Where do we start? If we were able to understand that, actually people won’t get sick in most places but there were two cities where people are predominantly getting sick and the rates there are much higher, we would reduce our scope – we would tighten our scope, so that, don’t worry about the cities where everyone aren’t getting sick, only worry about the cities where there’s a higher rate of people getting sick, and we do the same here, if we can scope it down to a part of the organisation, or a particular part of our process, we can reduce the scope and therefore make it a little bit more easy. 

Who – so, when we’re thinking about who we might think about the who in two ways – so for the patient’s side – so, is there a particular patient group, an age group perhaps, or a VHE, or a presentation type who are particularly overrepresented in this problem? Or it might be for our staff – so the specific types of people who may be different craft groups who are involved in these issues or is a particular people within a craft group. This can get a little bit tricky and a little bit uncomfortable sometimes because people feel like maybe we’re picking on people but – it is what it is. If the issues are coming from certain people, we need to unpack that and with respect to those people, we don’t wanna say that you know, you’re causing the issues, but the problem is there and then we need to understand what’s causing it which, for the most part, won’t be the person, it’ll be the processes is in issue in some way and is just affecting those people more for some reason. And lastly is how much, so we want to quantify all of these, so all these should be quantifiable with numbers and then that goes back to further bolstering or further quantifying our defined gap. So when I think measure, think 4W 1H. now, in each of these stages – so measure, analyse, improve, control – I’ve got a toolbox and for anyone who’s done structured problem solving before – this toolbox is certainly not complete. And this slide could go on for days in terms of all the different tools we have at our disposal to measure and properly understand a problem. These are the four that if we do well, the vast majority of our problems we’ll be able to understand and appropriately measure the problem. So let’s go through these – if you understand these well or if your organisation understands these well, it’s rare that you’re gonna get out of your depths in terms of technical knowledge at the measure stage so let’s quickly go into it. 

Process mapping. Process mapping allows us to see a process. Now if I’m working at Toyota and I’m watching cars go down the line this is less important. And the reason it’s less important is because I can see the car going down the line. I’m gonna see that the car there has no wheel on that, or that it does have a wheel so I can see that obviously between those two, they are putting a wheel on. Unfortunately, your processes are not so visual. And they’re never going to be. So for us to understand them, and particularly to understand them as a cross-functioning group or a multidisciplinary group, we need to visualise that and the easiest way to do that is to map the process out. I use – there’s a space that looks like post-its here – I tend to use post-its or white boards basically because it’s easier and it’s quicker and that process map is by itself, not important except that it helps us understand which, remember, measure is all about understanding. The key on this one here is, capture what actually happens, so that means you need to get up off your chair and go follow some patients, if it means that you need to go and stand in a ward and observe for a day, so be it. But we capture what actually happens not what’s supposed to happen because fixing what’s written down on paper doesn’t help anyone and in actual fact, often upsets our staff and our frontline guys more than doing nothing at all. So we map out what happens – this happens then this happens then this happens and then that might happen but then will branch off in this way, and what we’ll find is that as we go through it, the pure act of discussing that as a cross-functional team helps us understand. Remember, we say measure is all about understanding. Helps us understand the problems, or helps us understand the process and where the problems are. And we will identify problems in that process just by mapping it, just by talking through what happens, we’ll be able to talk about and identify where the problems are. So this is process mapping, but process mapping has a big brother called value stream mapping. And I’m not sure how many people have seen value stream mapping, but if you like, we go back to process mapping this is your plain old cheeseburger, this is your hamburger with the lot. They’re the same thing except value stream mapping’s got a lot more information on it. And the main thing, especially in healthcare that’s different, is that it has information flow, so if I go backwards again, back to our process map, at this point here, I’ve got all these steps but I can’t understand what they’re talking to, so step A – what does that talk to? Where does it get its information from? What tells it to do what it needs to do and when to do it and how many it needs to do and how fast it needs to do it? I can see that that happens but nothing tells me then how that fits into the organisation or how that is triggered or how that is controlled. Information flow on a value stream map will help us understand that. And often, particularly in healthcare settings, we’ll have just as many problems in our information flows as we do in our process. We also wanna catch a value added and non-value added so we want to identify the bits of our process where we’re adding value to our consumers and to our patients, and areas where we’re actually not adding value or we’re taking time. So let’s just quickly go through our value stream mapping stages. Before I do this, I always put this up. We only do mapping – value stream mapping or process mapping to make sure that we understand where our problems are. So, if we’re expecting anything other than problems out of value stream mapping, we’re expecting the wrong thing so be prepared to find problems and don’t feel uncomfortable when we start to uncover problems particularly when those problems might be a little bit uncomfortable or, a bit of an issue to discuss as an organisation. Better out than in, I guess. 

Here are our main steps for establishing a current state value stream map. This is a process map as we understand it. We do this, then we do this, then we do this, then that happens. So in this case a patient’s presented, we triage, we register, might be some early treatment, but then they go to the cubicle for observation, and et cetera, et cetera. this is a process map. I can see what happens but I can’t see how it happens, I can’t see how it’s controlled, I can’t see how long each step takes, I can’t see where the problem might start. So this is great, but for me to understand more I might want some more information. So the first step is I’ll put waiting times, average, min, max, median perhaps, waiting times between each of the steps. How long does it take a patient in this case in this patient journey – how long does it take a patient to get from here to here? So in this case, it’s 12 minutes to get from treatment to be observed on average. 

Then I might add some process information. So each of these steps has some information about that process. We don’t know what we don’t know at this stage so we collect any kind of information that might be relevant. So in this case we’ve got how many we’re doing a day, how many staff we’ve got, how many cubicles we’ve got, cycle times, so how long it takes to do each step or to do this process. We might have other things like reject rates or rework rates or maybe there’s times of the day where this can’t happen because our consultants are on rounds or something. Anything that might be relevant goes in here, no rules. But again, it helps us understand, remember we say measure is about understanding, we’re understanding it a bit more. Then we add information flow, and this is the bit where things can start to get confusing. So in this case we’ve got electronic health records and outpatient system and journey boards and we can now see which of these processes talk to what information and how do they get their information. Then we might see that there’s other things here. So, information noted on a chart, and this treatment is started by the nurse, but the nurse knows because the nurse checks the chart. Now I understand how that treatment works, it’s a bit more standalone if you like. I might also want to track our movement, it might be a movement of our patients, or of our staff, and so I use an example of patient movements here into an ED, so we present, we go to triage, we go sit back down, oh sorry so also we can go to triage, back, sit back down perhaps have treatment, go back into cubicles, into x-ray, back out of x-ray, etc. This might be useful might not be useful. I’ve seen these used for – just recently actually in a resus bay where they map the staff movements during a resuscitation, and realise there was significant amount of movement for one of the staff in the resus process. And so they relayed out some of their area to improve that. So, this may or may not be helpful, but it’s another thing that we can have up our sleeve to use from time to time. Once we understand our value stream maps so we got our processes, we got our information flow, we might also put our timeline down the bottom, I’m not really too fussed about this for most processes but what it allows you to do here is it allows us to get some of our problems out and start to talk about where some of our key problems are. Actually, it’s part of the analyse phase but it’s part of the value stream mapping so I just put it in here as well. So that’s value stream mapping. Super quick overview of it, and it is quite a difficult process but it is important, and what you’ll find is just that discussion helps you understand and remember the measures about understanding. So, the discussion, even though you value stream map may or may not look as structured and as pretty as this, the discussion – that’s the important part, because that measure is all about understanding. 

The next tool we have and often overlooked, much maligned tool is our check sheet. Now, often we don’t have the right data. Often we don’t have data that we need to properly understand our problems. What we often see though, is that when that happens, we go back to business intelligence and ask them to create a new form or new IT systems and it takes months to get that new data. A much easier and quicker way is to make a physical check sheet and ask people in the work areas on a temporary basis to collect some information that we can hopefully understand. So it might be the types of defects we receive or the reason for the delay in discharge or whatever it was – if we can collect that in a real time setting, we can understand things quickly. So we don’t always need to understand, high level data through our business intelligence course, we can collect it ourselves and nursing staff, and frontline staff can all be involved in that. So Nicole’s asked a really good question about are there any other resources for value stream mapping, there’s actually quite a lot of resources around. I’ve got a – I – Better Care Victoria’s got a basic overview of value stream mapping but it is quite basic. If I was to recommend a book for it, there’s a book called Learning to See, I’ll just write it in here, which is known as the authority on value stream mapping. It’s a book by the LEAN institute – LEAN enterprise institute – a great book so if you do want to understand value stream mapping and how to do it and probably understand where I’ve given you bad advice in my explanation there, Learning to See is quite a comprehensive book, so anyone trying to learn more about value stream mapping, I highly recommend that. 

The next one is Pareto analysis. Pareto analysis is – hopefully some of you have seen this – if you haven’t seen the word or you’re not used to that word, you’re certainly familiar with the concept. Pareto is – the name comes from an Italian economist called Vilfredo Pareto which is one of the cooler names you’re ever gonna hear – but we know it as the 80-20 rule. And the idea is that, if we focus on the right things, we can get a disproportionate result to the effort we put in, if that makes sense. So let me use an example, again, paperwork errors, we might use script errors, or whatever it is, we’ve got all these departments, got all these perhaps units, divisions. If we focus here on department seven, just an example, pick on department seven, if we focussed on department seven, the effort perhaps to fix this problem might be the same as it is to fix a problem in department one. But the result or the outcome we’re gonna achieve is very small compared to if we focus our efforts over here. So, the 80 20 rule, or the pareto analysis, all it does is helps us focus on our biggest problems and if we’ve got data, we can then make sure that we don’t focus on what the common understanding of problems is, but we understand – we focus on what the data tells us what the biggest problem is, and we can lay out our pareto analysis or lay out the data. So for instance paperwork errors or script errors let’s say. Department one at this first level we can see – woah, wait a second, in this case this line here is our cumulative percentage, over half of our problems all come from this one department, so don’t worry about the rest for now, let’s just worry about department one. So we might even drill down further, and say right, within department one, what problems are we having? So if we go back to our 4W and 1H, this is the ‘where’, or the ‘who’ perhaps, the where’s it happening, and this is the what – what is happening. So, in this case, incomplete. So again, more than half of data one – er, department one problems are then coming from incomplete, something’s incomplete. You can see that the problem has gone from paperwork errors down to just department one down to just incomplete on department one. The problem becomes a lot smaller and because it’s a lot smaller, it’s a lot easier to start to tackle and start to address. If there’s a single tool, if I was asked to do problem solving and they said, you’ve only got one tool up your sleeve to do this, pareto analysis every day of the week is gonna, is gonna be where I’m gonna focus. It rarely lets you down. It rarely lets you down if you get the data, it’ll point to where the problems are. 

And the last one and this is particularly valuable I’ve noticed in healthcare, is our scatter diagram. So this is not a cause and effect, but it is a relationship and if we can establish relationships, we can then establish abnormal cohorts or abnormal clinicians. So for instance, we’ve got two characteristics here, and every time we have a data point, we plot the characteristics against each other. So this might be one point eight, and four, so it might be the overall length of stay and the length of stay in ED perhaps. If we can then plot all of those, we can see ok there’s a pattern. There’s a pattern in this district here there’s a clear pattern. The longer we stay in ED, the longer our overall stay will be, ok, I can see that pattern no problem. Then I see here, there’s something abnormal here. They’re staying a long time in ED but their overall length of stay is quite small. So it’d make me focus what’s happening here. So in this case it’s perhaps good or bad we don’t know, but it tells us that group there and that group there are different and helps us understand or helps us interrogate why those two groups are different. 

Right so, we’ve gone through the measure phase, and if we go back to what I said at the very start, our 4W and 1H we’ve understood our 4W and our 1H and hopefully at this stage, our problems have gone from a big cloud down to a small, specific set of problems and it might be that instead of having one problem now we have six different problems, so be it, but those six different problems should be small problems now, they should be small enough that we can start to start – start to analyse and say why are they happening. We can understand now why they’re happening, we can get to our root cause and that’s what analyse is all about. It’s taking those very small problems that we got out of the measure phase and start to ask why did those problems occur. Here’s our causal tree, if that’s a word, we wanna understand firstly our point of cause, so that’s where the problem occurs, and that’s really should have been established in the measure phase so hopefully this is already done, and direct cause, so what’s happening, what’s causing it, and our root causes, which is why. And this is the important bit, if we don’t get down to this why, we can’t really fix the problem in an effective way. So let’s just start quickly on point of cause. Sorry, before we do that, here’s our toolbox again. Process mapping, like I said we should have already done that, when we’re looking at our possible causes, or our what, we use a fish bone diagram, and when we do our root cause, we’ll go to our 5 why analysis. So, quickly on point of cause I won’t spend too much time on this because, it’s if we don’t understand the point of cause by now, we probably have progressed into our analyse phase too early. So if we don’t understand the where well enough, we shouldn’t have come into the analyse phase. Go back to measure phase until we understand it properly. The idea is, through our process, and our process maps is the easiest way to do it – through our process we wanna isolate where problems are. So that we don’t need to focus on this bit here, we don’t need to focus here, cause the problem occurs here. If you like, a treasure map, x marks the spot, digging starts here. Doesn’t matter how good a digging we do here, if the problem doesn’t occur here at step three, we’re never gonna find it. 

So let’s move onto the important bit, cause and effect. There’s a couple of things and I’ll talk about it at the end, but there’s a couple of things that make or break problem solving and cause and effect is one of them, because what this does is it helps us open our minds and break our bias and like it or not, we all carry a bias into a lot of what we do in life  but particularly in problem solving, we’re all very self-assured and understand that we know what the problem is and so to break that human condition, the cause and effect can help us do that when we use it properly. Ideally what we’re trying to do is brainstorm and purge out all our problems. What we’ve done so far in our measure phase is we’ve converged our problem, we’ve made our problem more specific and tighter and got a team focus around a tighter problem. What we’re gonna do now is we are now gonna ask everyone to diverge again – we’re gonna ask for – for that specific problem, for us to start to diverge and think about all the possible contributing factors to that problem. We can use a fish bone diagram to help us frame our brainstorming, but just a little bit about brainstorming firstly, I think a lot of people will have understood and been involved in brainstorming before. The concept really is that this synergy, this idea that if we can get people in a group talking and bringing out ideas, what’ll happen is the outcome of that session or the outcome of that kind of free discussion tends to be that the sum of the parts sorry the outcome is greater than the sum of the parts, so one plus one equals three if you like.  We wanna focus on quantity of ideas and not quality, and the reason it’s important is because it doesn’t matter – even if an idea is rubbish, it’s actually, it’s not gotta basis in the real world, it may trigger someone else to think about something that they wouldn’t have otherwise thought about, that’s this concept of synergy. It allows us to combine and then therefore build on ideas. Again, our best friend sticky notes and white board just to make it easy. Don’t worry about typing this stuff up guys, just get it out, get it out in the open and let’s get people talking about it. So, what are the problems? What are the things that are contributing to these specific problems? This is what a fish bone diagram looks like, and there’s no prizes for guess where the name came from. It looks like a dodgy old fish here, here’s your head and this is the problem that we’re talking about. Now this problem is not our original problem from the start of the problem solving. This is our scope down problem that fall out the bottom of our measure phase. So these are our small problems so here’s an example that we had it might be that incomplete or missing information on forms from department one. That would be the problem, not the bigger problem, just the scope down problem. Now the reason – the way we use this to break bias or to break our ideas is we talk about the question differently. So if we say, if I was to ask anyone, right what’s causing a particular problem, people will have their own ideas and it’s very difficult for people to break their bias to start thinking about well, what other factors are there or what else can contribute to this. People tend to go in – people believe that there’s a problem with the computer system, when you ask them what’s causing this problem, the answer will be the computer system. And if you’re asking what else is causing this problem, it’s gonna be very difficult for them to think about anything other than the computer system. So what we do is we don’t ask that question, we ask a different question, it’s a very, slightly different question but it makes all the difference. So in this case we’ve got what the problem is, the contributors, the contributing factors, we got our people, we got our machines we got our equipment and our IT systems perhaps, we got our methods the way we work and the materials that our information might be actual materials like supplies, and our measurement – the way we measure or the way we track ourselves. Instead of asking what’s causing it, we ask this question – how could the method contribute to this problem? We don’t use the word cause and we focus on one branch at a time, so we say how could the method, hypothetically, how could the method contribute to this problem? How could our machines and our equipment contribute to this problem? Again we’re not saying cause, all we’re saying is contribute. And what you’ll find is you’ll be able to explore and open up a few more opportunities by asking that question in a different way, it’s a little less confronting, so instead of saying what caused this problem, almost in an accusing kind of fashion, we’re saying well how could this contribute to it. 

Now, we said at the start that we focus on quantity not quality of ideas, and we say that there’s no such thing as a bad idea, but unfortunately there are bad ideas, and some ideas are wrong. Some of the contributing factors that people will come up with, when we actually test them in the sober cold light of day, won’t actually stand up. So it might be that ah, the computer keeps crashing and deletes all our work but then when we look at it, it doesn’t crash, or when it does crash it doesn’t delete any work at all. So what we’ll need to do is we’ll need to go back and check each of these and just confirm – are they actually correct or is it just someone thought about it in the session but it’s not really, doesn’t really have a basis. So some will be able to discount and remove them, the rest, what’ll tend to happen is you’ll be able to group those into themes. So if we go back to our fish bone now, an example of a theme that constantly comes up would be our nursing staff are unclear about how to do the job, and then down here it might be, our nursing staff are not trained and over here we have, there’s no standardised or documented way to do the job. So for me, that’s the theme. If someone doesn’t know how to do the job, they’re gonna do it in different ways, and that could have been because we don’t have a standardised way of doing it. So all these three, I would then group together and say, right that’s one problem. We don’t have a standard way of working. That’s just the example and I use that example because that comes up nearly every problem solving I do, if there’s a standardisation problem, you’ll see it on method. But you might see it in other areas as well where you group them together and say well they’re actually just the same thing, paraphrased. What’ll typically happen is for each problem, you’ll have two, three, four of these themes. We call these themes the direct causes. These are direct causes. They’re not root causes, because we haven’t asked the question why yet, we’ve only asked what contributes, or what causes it, we haven’t asked why and so they’re only direct causes, they’re an intermediate on our journey towards the root cause. Our root causes analysis, is often done poorly but really there should be no excuse for it. The only reason we do it poorly is because we allow our pesky human biases to get in our way again. Some of you might be familiar with the 5 why analysis. The concept behind the 5 why analysis or the idea behind 5 why analysis for root cause is, we just ask for why. We continually ask why until we get to a root cause. So, look at our direct cause up here, and these are the direct causes, if I go back up a slide, these are our direct causes these things here. Each one of them we’ll have to do a 5 why analysis on. So in this case, we have our direct cause, the first thing we do is we ask why – why. I’ll move that out of the way. So we say why. And there might be a few reasons why that happens. Then, one at a time, we’ll then go down again. Ok, well then why does that happen? We’ll go down again. And then we’ll say why does that happen? And so channelling your inner two year old and just keep asking why, it sounds silly but it’s an incredibly powerful tool.  Continue to ask why, and if you’re genuine, you continually genuinely answer the question of why, you’ll eventually get to the root cause. Keep asking why, why, why and you do it on this branch as well, and sometimes they’ll branch it out and sometimes they’ll loop back on themselves and they’ll refer back to themselves and sometimes they’ll join in. At these dead ends, then become our root causes. My advice on this one is, trust the process. In fact, my advice for all problems solving is trust the process but 5 why analysis particularly do what it says on the box which is ask why. And if you genuinely answer that question why, actively think about am I answering the question of why. Well then you’re gonna get down to the root cause. So it might be, I didn’t follow, the nurse didn’t follow the normal process. Why? Well, she didn’t update the computer system. Why? Because, the computer system was locked. Why was it locked? Because the ward clerk left the desk. Why did the ward clerk leave the desk? The ward clerk left the desk because the ward clerk’s got another job in another part of the ward. If we keep going down, so that’s one contributing root cause, if we keep going down these other paths, we have other contributing root causes. Now we say 5 whys, it doesn’t always take 5 whys to reach  the root cause, sometimes it takes one, sometimes it takes seven, we just use 5 just arbitrarily and to be completely honest with you, I don’t know where 5 came from. I guess maybe 5 – most problems would be solved in 5 steps I guess but that 5 there is somewhat arbitrary. We just ask why until we get to the root cause. Now the question is, how do we know when we get to our root cause? Cause you can continue to ask why forever. Broadly speaking, we start – we stop asking why, therefore we’ve achieved, or we’ve got to our root cause when the problem starts to become more vague rather than more specific. So as we’re going down our root cause, the problem will be getting more specific and perhaps more pointed and easier to fix. At some point, it’ll turn into too vague. So an example will be if my car broke down, I can say well why did my car break down? My car broke down cause I didn’t get it serviced. Well why didn’t I get it serviced? Because I’m lazy. Well why am I lazy? Well, dad was lazy and maybe it passed down to me. Well why was dad lazy? I dunno. His dad was lazy. You see that we continue to ask why forever, and you continue to answer why forever. But at some point you get into areas where you say, this has got nothing to do with the project, it’s outside the scope of the project, that’s completely vague and I’ve got no way of fixing it. So in that case, the root cause of my car breaking down is I didn’t get it serviced, so my countermeasure needs to be to address that. Address why you don’t get your car serviced as opposed to the fact that I’m lazy or dad was lazy or – my grandfather was lazy and taught my dad to be lazy. They’re nonsensical, even though you get there if you continue to ask why. So stop when the problem starts to become too vague, when the cause or the potential countermeasure then becomes outside the scope of our project, or when the cause becomes a matter of individual personality, cause, if you like that’s kind of the same as the scope of the project. We can’t – we can’t control people’s personalities, nor should we, so that becomes outside of our scope. Some common misconceptions around 5 why analysis is that it’s linear, and that there’s one why – one answer to every why. That’s just simply not true. It branches out, it’s messy, it loops back on itself, and as long as you trust this why, you continue to trust the process, you won’t go wrong. Just answer the question why, don’t worry about what it looks like. And the other misconception is there’s only one root cause to any problem. Again, completely untrue and if we take that mindset into problem solving, you’re never gonna effectively solve problems. Specially in complicated or complex and multifaceted organisations and processes like healthcare, usually a problem occurs because the holes in our Swiss cheese have lined up and something has gotten through the system and so fixing just one layer of that Swiss cheese might help for a certain amount of time, but it certainly won’t fix a problem dead. What we’ve got to do is, we’ve got to look at all those contributing factors, and start to improve each of those. 

The outcome of our analyse phase is these. These things here are our root causes and are the key outcome of analyse. So if you like, when we’re doing our analyse phase, what we need to try and achieve is our root cause. From there we can jump into our improve stage. There’s three steps that we’ll follow in our improve stage, we need to identify possible improvements, once we see our possible improvements, we can assess them, not all improvements or changes are created equal, so which ones should we be chasing after and implementing, and then we need to obviously, we need to implement them. Couple of quick tools here, how-how diagram and decision matrix. You might not always use a how-how diagram but for big projects this can be useful to frame our thinking. Decision matrix – chances are, we should be using this for most of our projects. So, we are now in a situation where we’ve got multiple root causes and we need to select improvements for each of those root causes. Once we understand those multiple solutions we’ll then understand which of the best ones we need to implement through a decision making matrix approach, but for complex solutions, we might not be able to quickly understand what the solution is without breaking it down. So the first thing we might do is use what we call a how-how diagram. This is a very – not an overly complicated solution, but if we’ve got a complicated solution, we can use a how-how approach to break it down and frame our work in terms of what do we need to do. Very similar to our root cause analysis, we just ask how. So, in this case, we’ve obviously come up against our root cause of the form is hard to use. You can argue that’s probably not a deep enough root cause, and I probably don’t disagree with you, but for the purposes just trust me here and we’ll just go through this example. So improve form usability is what we wanna do to improve. To unpack this to turn it into something that’s tangible and something we can start to address and action, we can ask how. So, improve form usability. Well, how? Well we need to improve people’s knowledge around form and we need to make the form more logical. Ok. Well how are we gonna make it more logical? Well we’ll align it to our work sequence and we’ll use common language on our form. Ok I see. Alright. Good. How are we gonna improve our knowledge? We’ll create a how to sheet on the back of the forms so people can refer to it easily, and we’ll train our staff. Well how are we gonna train our staff? We’ll do it in group training, or in team meetings? And this might be an or, and we might say we won’t do that or we won’t do that. So, like I said this is not a terribly complicated solution here, but for those big complex solutions, we might wanna use this approach to unpack it so we get down to these here, these are the solutions, the implementable solutions.  

Once we understand our solutions which we may have come up with through a how-how analysis or it may have just been that we’ve come up with them directly, we wanna assess them and decide well which ones are the ones we wanna go ahead with and broadly speaking we assess our solutions against two areas, one is effectiveness and one is cost. Effectiveness is made up of a few things and, this is not well understood I don’t think and from what I’ve seen, this is not well understood. Effectiveness, we think about efficacy as opposed to effectiveness. Now, the problem with this is, there’s an assumption that we’re gonna adhere to it a hundred percent. So certainly that is an input, but our ability for the solution to be sustained and suitable for all scenarios are other aspects to effectiveness,  it’s all well and good to have a solution that works if we use it a hundred percent of the time, but if we’re only gonna use it forty percent of the time, our effectiveness is actually quite poor. So, not only consider the effectiveness should we always use it, but also consider how likely or how easy it is gonna be to use. And we also need to consider the cost, so the cost to implement, training costs perhaps, the cost to implement might be our own effort or might be if we have to pay for equipment or IT solutions, but also the cost to maintain, so there might be trailing costs, ongoing costs, so for instance if we add an additional staff in to address a problem there’s obviously a maintenance cost to that, which is we gotta pay for someone’s salary for the next however many years. So these are our broad criteria that we analyse our solution against – cost and effectiveness are impacted. Here’s a decision making matrix, I call it a Boston matrix, which it’s not, so don’t call it that, but we use this to help us understand where should we be focusing our efforts. Now, you got the two maps – those two scales, those two are factors, effectiveness, so highly effective, or not so effective, and you’ve got cost and it’s a low cost or its high cost. So certainly our first starting point wants to be low cost and highly effective, up here. They’re our quick wins and if we can get solutions that fall up in here, they’re the ones we’re likely to go with. Our next area that we might wanna focus on will be over here, they tend to be our projects where, they’re still quite effective but they cost a bit more or they might be a bit longer lead time or something. Down here, you got the low cost but the less effective, these tend to be things like memo out to our staff or discussing in our team meetings, things like that. We might use them as stock gaps but they’re not effective and really we shouldn’t be relying on those to fix our problems in there, in the fullness of time. And then you’ve got these ones over here which you’re not gonna touch. They’re – they cost a lot of money, and they’re not effective so they’re just – your genuine old bad ideas. 

If we go back to this one – once we understand this, we can then understand which of the ones we’re gonna choose and the team should then identify right we’re gonna choose this one and this one and this one and this one to implement. At this point, this is where we can also start to break some of that bias or some of that ready-made solutions that people come into problem solving with, which is oh, we need an IT solution to fix this, but actually if we rate it, it might be that it’s costing quite a lot of money and it’s not, all things considered, not gonna be actually all that effective, or it might be up here or wherever. Or, it might actually not be so expensive and it’s highly effective, so be it, but it allows us to in some objective fashion, assess where we wanna be. 

Once we’ve identified our solutions, we understand what we wanna implement, we then need to implement them in a controlled way and there’s four things here that I’ll quickly go through. The implementation sequence and schedule, our communication of changes, our training and updating standards. So firstly, implementation sequence and schedule, think about how we might implement. Implementing a change all at once, all wards, all units, all campuses is fraught with danger because what’s going to happen, whether we like it or not, what’s gonna happen is problems are gonna happen during the implementation period. And rather than making those mistakes fifty times, we’re better off making them once or twice, address them before we expand and spread our improvements. So think about – what wards or units might we focus on then? I’m working on projects with health service at the moment and we’re actually working within specific units within specific wards, so it’s not even a whole ward, and it’s not even a whole unit. It’s a specific unit within a specific ward, and if we can get that right, we’ll maybe spread it out to the rest of the unit or to the rest of the ward. We’re gonna document the plan and we wanna manage that plan regularly. 

Communication of changes now, I know this is very simple, very quick here, but if you haven’t already started a communication of changes, you’re probably in a world of hurt. So we said at the very start you need to establish a team and that team needs to be made up of people that this is affecting, if that hasn’t happened and this has all happened behind closed doors, this you’re in for a hard road here. So, communication of changes, if you’ve had the right people on board from the start, it will be easy. So it should be coming from the project team members, shouldn’t becoming from management, the project team members, whether that be nursing staff, or doctors, or PSA, or ward clerk or whoever it is, they’re the ones who should be communicating back to the rest of the team about what’s happening. We shouldn’t just do at implementation timing, so the morning huddles say – by the way guys, we’re changing this tomorrow – and we wanna consider our different communication styles. 

Some of you might be familiar with the DOPE personality framework. Broadly speaking, all of us fall into one of these four categories, we’re doves, owls, peacocks or eagles. And within these we might be a really strong dove, or a – just a borderline dove, or we might be a really strong eagle, or just a borderline eagle. Our doves are our soft and cuddly and warm people that care about people, they wanna talk about team work a lot. Our owls are our highly analytical introverted people. Our peacocks are our showy, what’s in it for me type people, and our eagles are our direct, brash, hurry up and get to the facts, hurry up and get to your point type people. Now, that saying that talk to people how you want to be spoken to is absolute rubbish because, if you’re an eagle and you talk to a dove the way you wanna be spoken to, you’re gonna scare the dove and the dove’s gonna sit there and say yes and agree with what you say. But if you’re a dove and you speak to an eagle like a dove, you’re gonna bore the eagle, the eagle’s gonna get up and their mind’s gonna start wandering, they’re gonna start thinking about their next meeting, they’re not gonna be interested in what you’re saying because you’re rabbling on for too long. So, I won’t go into this in too much detail but have a look – there’s plenty of literature around DOPE personalities. Have a look at it, and when you’re communicating change, just be familiar with who you are and be familiar with who your audiences are. Now, I focused on doves and eagles because in healthcare, we – there are a lot of doves, which is reassuring as a consumer, it’s reassuring that there are a lot of doves cause doves tend to be people-people and warm people. There are also quite a lot of eagles, so they’re actually quite opposed, these two personality types. So, consider who you’re communicating to, and also consider about is there any way I can communicate to both people or all these people all at once. So, I’ll leave that to you guys to do more reading if you’d like, but this is an important concept. It’s not about communicating to people the way you wanna be communicated to, it’s actually quite the opposite. 

Training. Training is important and we as project leaders need to respect that that is the case. So changing the way we work is not easy, it’s actually, it’s uncomfortable, it doesn’t feel right, even though we might be able to do it, it doesn’t feel right and in in a busy situation when you’re not actively thinking about what you’re doing, you’re gonna tend back to your muscle memory, you’re gonna tend back to where you’re used to be, because that’s what’s comfortable and that’s what feels right. Oop – here’s Johnny Bravo. You guys are all sitting there in front of your computer. Cross your arms like Johnny Bravo’s crossed his arms. Now cross your arms the other way. What you’ll find is, if you can cross your arms the other way without looking silly, congratulations, but it won’t feel comfortable. So we’ve got those odd people out there who listen to me and they’re talking about – and it’s actually quite comfortable, you’re the exception to the rule, but for most people, we can probably cross our arms the other way, it’s not a hard thing to do, but it feels weird, it’s uncomfortable and if we weren’t thinking about it and we go to the pub tonight, and we cross our arms, you’re gonna cross them the way you normally cross them unless you’re actively thinking about it and actively thinking about doing it the other way. So when we do go over to training and implementation let’s just make sure that we are respecting our people well enough to afford them the time to make that change. Change is not always easy, even though simple case like this, crossing your arms the other way, well it should be easy, but it doesn’t feel comfortable. Change is hard, guys.

Right. Then once we’ve implemented the change, we’re now into control. So control’s all about making sure that what we’ve done one, is maintained, and two, we haven’t affected other things. That’s the important part of it. We wanna monitor the performance of our process and we wanna share the improvements and our lessons learnt. Back to our toolbox we got our SPC tools, statistical process control, for anyone who’s used SPC you know there’s a lot more than just a run chart and a control chart from an SPC point of view, but again similar to what I spoke about with our measure phase, if you understand these, most problems, or most projects you’re gonna be able to track in an effective enough way that when problems occur, you’ll see them. So, make sure that you know these, but if you wanna know more detail, there’s quite a lot of literature around SPC. The other one’s A3 reporting and I imagine that most of you are familiar with A3 reporting, or have seen and been exposed to A3 reporting. We’ll talk about that a little bit but it’s an important tool not only for thinking about what we’re doing but also communicating what we do.

So SPC, it’s a data driven monitoring process. And essentially it helps us monitor the effectiveness of our changes in some sort of objective way. The other thing we can use it for and as I said before there’s no unintended consequences with that change. So for instance, the two diametrically opposed factors tend to be things like quality and lead time, or quality and length of stay. And you can always achieve a length of stay result by compromising patient care or quality. On the flip side, you can always achieve a potentially really good result in quality by just ignoring length of stay. So, we need to make sure that by achieving something let’s say we’re tracking and we’re trying to improve length of stay, that we are not doing that at the expense of something else. Here are the two tools. A run chart – this is – that is, weeks, perhaps, maybe hours, essentially it’s time, so each data point is another point in time. What we use this for is to monitor the impact of discrete changes so if we’re tracking a particular aspect it might be length of stay it might be the number of discharges from a ward before 10am it might be number of paperwork errors whatever it is – if we can track that over time, when we implement a change, we can track what that discrete impact of that change is. So, you can see here, something’s changed. Hopefully we’ve implemented something that’s improved that and now we’re on our journey here. So I can see that that’s made an impact which is good. I could also see if it didn’t make an impact, which tells me that my solution is not working or something is not effective out there. A control chart, as the name suggests is used to make sure we’re in control, we’re not losing control and we often use this to monitor our peripheral processes to make sure we don’t detrimentally affect it. So for instance, like I said, we’re trying to get our patients out by 10am, our length of stay target, we could use a control chart to make sure that we’re not affecting patient care. These control lines – there’s a lot of statistics that go behind how to calculate these control lines. And again, if there’s any purists out there listening to me, I apologise cause I’m probably gonna give you a heart attack, but the easiest way, my experience, is look at what you’ve been achieving in the past and just draw them by hand. Draw them by eye. In the past, we’ve never broken through five. Right, so one control line would be round about five, and in the past we’ve never broken down through four, so we’ll leave it there at four. If we see a significant shift that breaks through those lines, we know that we’ve changed something over here, that’s now affecting this over here. Again, there’s quite a lot of literature around how to calculate these control lines and how to use control charts so if you wanna look at that detail by all means do. But really what we’re trying to look for here is something that’s changed that we’re not intending. One thing we do need to do and I’ll talk about it a little bit at the end is we need to expect problems. We need to ready ourselves and ready our teams for problems to occur because if we’re not ready for problems to occur people are going to take that as a failure. Part of our PDSA cycle, the S, is designed to find problems, and not because they shouldn’t occur but because we know they will occur. Change is inherently risky, and when we implement something we, for the first time, we expect problems so, expect problems and tell your staff and tell your team that problems are gonna happen and we need to be willing to see them and willing to then address them. Now if we have that expectation, our checking or our cadence of management should be heightened around implementation time. Because we know problems are gonna occur so if we check more often we’re gonna find them before they start to hurt us too much in too many ways. And sharing the learning, the other part of controlling. So, when we successfully address a problem, we wanna get other people in our organisation to get a free kick, we’re on the same team, and what’s good for another ward is good for me, and what’s good for another unit is also good for me. 

A3 reporting is a vehicle for that success. If you guys haven’t seen it, pretend this is an A3 piece of paper, and what we do is we tell a story. And that’s deliberately written there – tell a story. We consume information through stories quite effectively. People do. People – if you go to a restaurant tonight with your friends, they’re not gonna tell you a fact and a series of facts, and give you some data. If they wanna tell you something, they’ll tell it as a story, they’ll introduce it, they’ll tell you the background, they’ll tell you who was involved, they’ll tell you what happened, and invariably they’ll give you their spin on it and what their conclusion is. They tell you a story and we consume stories. So we tell a story, cause people will consume it. So if we look we got our DMAIC steps here – define, measure, analyse, prove, control. Because it’s an A3, we are limited on space, we can’t have a 700 page document with seven appendices at the back. We’ve got this much space to get our story across. And as an author, it makes us think about what’s important and what’s not important for the reader and for the audience to hear. If that means you’re just making your writing into size 4 font, you’ve missed the point. It should be easy to understand it, it should look something like this. Maybe a little more words than this, but define the gap, show us some details so I can see where you’ve understood through your measure phase what the problem has been. Show me the process so I can understand the process a bit better. Show me what the potential causes you came up with. Show me how you got your root cause. Show me what ideas you came up with and what you’re gonna do about it, and show me what your results were. People learn this, people will go, oh wow maybe I should do that. If they can understand it properly. If it’s a long page with all writing, people are gonna tend to not read it, not look at it, and therefore not implement it. 

That’s great and I hear this all the time, it’s great but we’re busy. So something for you guys just to consider if one doesn’t have time to prevent problems reoccurring, we don’t have time to do root cause analysis cause we’re busy, where do we find the time to keep fixing them when they do occur? They occur every day and if we manage to fix them. So when they do occur how do we find the time to fix them if we don’t have the time to fix the problems properly? I don’t have a magic solution for that, but it’s good food for thought. 
I’ll quickly go through this, this will all be on the website if you guys have a look at after the session but a couple of key points – coaching through the problem solving – make sure we manage the process not the outcome, and manage enthusiasm to jump ahead. Remember, and be acutely aware that people are gonna want to jump ahead to the countermeasure, to this solution. Manage that enthusiasm. Hold back on the bit and stop people jumping forward too quickly. The key parts of the problem solving  are problem definition, and cause and effect investigation. They’re the same risk and the risk is, the bias. If we can’t properly define a problem, don’t allow a problem to progress, because what will happen is we’ll start solving problems that don’t exist. And for any of you who have been through a change process where there hasn’t been a clear problem, and you haven’t really solved anything, you’ll understand what that does to the – to our own departments and our staff when we make a change but there’s no real problem that we try to solve. Make sure we create and follow a schedule and we’re disciplined in terms of following up on that. And this is a little bit detail about those two key points so I won’t go through them but they’re there. 

So here’s our key steps of problem solving that we’ve gone through today, define, measure, analyse, improve, half of improve, all of that is our plan, if we are using the PDSA. Then we got our do, so our D – back end of improving, and then our S and A are in here. Our study and act are through here, perhaps then back into defining another problem to go again. Right, so that’s the structure of problem solving and incredibly quick and we weren’t able to go into too much detail about many of those particular aspects of particular tools but at least now we’ll know what those stages are and what we need to understand and what those steps need to be so I’m sure a lot of that was familiar, but hopefully there was something out of that you can grab as well.   

I said at the start that I want to focus on not only the structure of problem solving but also around the environmental conditions if you like, that enable problem solving to happen. If we have an environmental condition, an organisational environmental condition that is hostile to problem solving, hostile to improvement, the fact is unfortunately we won’t improve. The problem solving will die a slow death and we’ll never get anything done. So, here are our thoughts on the key things that are required from an improvement point of view.

One of my favourite books, Team of Teams, general Stanley McChrystal, ideas are cheap, plenty of armchair generals have proposals for winning wars, some of them are quite clever, but only those who can shape and manage a force capable of doing the job ultimately succeed. What we’re talking about here is that ideas are cheap. Everyone’s got ideas. And we don’t want to be the people who are sitting around talking about our ideas, we want to be the people who have successfully implemented our ideas. Standardised, maintained, and grown our ideas. We need to manage a force that’s capable of succeeding. That force is our organisation. Our organisation needs to be capable of succeeding here, and not individuals in the organisation. 

So we talk about sustaining change, we got our performances and some time, we go along, we do our problem solving and we get a jump in performance, it might be length of stay, it might be quality, it might be whatever it is, we get an improvement. And that’s great, but if we zoom this out, so this is on a timescale of weeks, if we zoom this out to a timescale of years, what does it look like? It now looks like a blip on the radar. It’s nothing. Instead of here, it’s – we made a change, and we sustained it, which was great. The conversation now is, oh, couple years ago we did something. It’s completely uninspiring, it’s not really what we’re looking for. So, when we talking about sustaining change, this is not what we’re talking about. This, should be assured through the controlled process of problem solving. So this should be controlled within a problem solving. When we talk about sustaining change, we’re talking about the trajectory of improvement, the direction of improvement, not the discrete individual improvements, but the fact that we can continue to improve. This is what’s important as an organisation. 

Some of you might have seen the iceberg of success before. What we see, is we see success and we think, oh wow, that’s excellent, look at that hospital. They’ve been able to implement that, and look at where they’re at. What we don’t see is the mess that’s underneath the water. The things that people have had to wade through to get there, particularly the failures. For every success, there’s been multiple failures. But there’s been a persistence and a discipline to maintain course, that has resulted in the ultimate success. We also need capability from our organisation and critically we need leadership to provide us with direction. There’s three main aspects if you like, and in a really high level and quick way we’re gonna go through the key ingredients to providing an environment that is susceptible and supportive of, leading and sustaining change. So, in an organisation we need to provide direction, we need to have capability, and we need to have control. And in here, is where improvement and innovation culture lives. If we have direction, and we have capability, what happens is we continually jump and try to improve, but then we fall back. And then we’ll jump and improve, and we’ll fall back, and then we’ll jump and improve, and then we’ll fall back. If we have direction and control, we’ll never improve, but we’ll be very steady and we’ll never go backwards. If we have capability and control but no direction, if we have capability and control, we’ll improve but not always in the right direction. So, we might improve in an area which from our patients’ point of view or from an organisational point of view, is actually not really helping the bigger picture. So we need all three things for sustaining change or sustaining improvement trajectory. What it looks like is leadership organisational capability in daily management. These are what, if we like, these broad vague terms are, this is what it looks like in an organisation. So I’ll go through them one by one. I’m just conscious of time, so I’m gonna zoom through these ones. 

Leadership. We need to know where we’re going. We need to have a set of organisational behaviours that are accepted. We need to be able to set targets that are clear and appropriate. We need to trust the processes, leaders, we need to trust the process, and as leaders we need to have an appropriate style, and there’s an appropriate style to the way we lead and sustain change. So we’re not talking about leadership of the organisation more generally, but within the context of change and improvement, there’re particular leadership style which is important. So firstly where are we going? Taking that step up is not always gonna help if it leads to a dead end. We need to know that where we’re going is appropriate. Most organisations will have a vision or a purpose or a mission perhaps, and there’ll be strategic plans, and there should be operational plans. And, for the most people in the organisation this is the important bit, these operational plans. And they are the most important but they are completely uninspiring without an awareness of this bigger picture. Leadership’s role is to provide visibility of this bigger picture and providing our true north, if you like, and the why we’re here discussion and frame to make this useful to us as leaders of change. Our organisational behaviours – there’s a much overused word in improvement – in the improvement world of culture and I think it’s much overused not because it’s not important, but because I don’t think it is well understood. I don’t think it’s understood well enough and people use the word culture as a proxy for a bunch of things. Culture is about the way we do things, it’s about the way we work. Establishing organisational behaviours can help us create the how – the how do we go about it. The way we work. And if we do that well enough, we can act our way towards a culture. Only if we live it though. Leadership plays a critical role in establishing and maintaining them. Now, my background’s Toyota, so I’ll just give you an example of some organisational behaviours that Toyota use. Now I’m not suggesting we need to use these, or should use these, a lot of organisations that go down the LEAN journey do use these, but it’s not to say that you have to, but the key point is, these are discussed, people are quite aware of it. Start of projects and start of meetings within teams, they’re acutely aware of these, and they’ll refer back to them when people breach the organisational behaviours. So, they challenge the status quo. So people are invited and expected to challenge the way they work. There’s a concept of continuous improvement, where anyone can come over to anyone, and the expectation is they can explain what they’ve done in the last day, week, month to improve the way that they work. There’s a concept of go see study that if we don’t understand something we don’t discuss it in a board room, we don’t discuss it at a – over the phone, we go and see for ourselves to see if we really understand what we’re talking about. There’s a fundamental respect for each other, not just writing kind regards in the bottom of our emails, but actual respect which is borne out of making sure we go and see and thoroughly understand. And out of that respect comes teamwork. Now I’m not suggesting we have to use these, I’m not suggesting we should use these. I’ve used these a lot and I like them, but the idea is that an organisation can establish a culture or lead a culture through establishing and actively referring to an acting – against a certain set of behaviours. So think about your organisation, do you have a set of behaviours? If you do, are people aware of them, and do you all – do you refer to them and challenge each other when we are breaking those or violating those behaviours? 

Targets. One of my favourite sayings is you get what you measure, and you do. And if I was to measure a HR manager purely on time to fill vacancies, and I really strongly measured the HR manager on that, and I linked his remuneration with how long it took him to fill vacancies, I’m gonna achieve that target. And if that means that HR manager needs to be out on the street dragging the next person who walks past and put him in a chair and say, if Simon comes up to you, tell him you work here, that’s what we’ll get. So, we need to be careful that you get what you measure, but it is a double-edged sword. We can use that in your role as well. 
From an improvement point of view, we want to think about what targets are appropriate based on where we are on our journey of improvement. So when we’re starting out, we have low capability. Just be honest about it, so if we have low capability, focusing on the quality of our results is the worst thing we can do. Certainly we wanna achieve results, but focusing on results means that if someone because they have low capability, or a team has low capability, aren’t able to achieve a good result, we aren’t able to celebrate it, they don’t achieve it, it’s hard. So early on we might wanna focus on things like quantity of activity or engagements – how many people are involved in things, how many big projects are currently happening, how many ideas are being received. Over time, we might then transition across to the quality of our results or whether we’re achieving outcomes. Remember targets will drive activity, so if you have a high capability, and you didn’t drive results, you drove quantity, sorry, if we were high capability and we drove quantity, all you’re gonna do is drive people to just come up with ideas and not focus on quality. 
Skipping through these pretty quickly guys so if there’s any questions, please feel free to ask. Next one is leadership needs to trust the process, and again us as project leaders or subject matter experts need to trust the process but also our senior management need to trust the process. Our old friend Deming, every system is perfectly designed to get the results it gets. The idea being that that process that we have in place is perfectly designed to get the results it gets, and so if we wanna change our results, we change our system. 

Trust the process. Only by focussing on the process can we change or affect the outcome and when we become entirely focused on the outcome we become firefighters. And worse still, organisations often reward the firefighters and the firefighters are held up as the great saviours of our organisations and they should be. It’s important that people who are able to fix problems and remedy outcomes are recognised and rewarded and they are very important to our organisation but we need to have that same focus on the people who in more methodical ways are fixing problems before they occur or trying to access and address root causes. 
If we look at our PDSA cycle, there’s only one bit of that which is outcome focused and really all that is is they check process to make sure that we are on the right track. We plan, we study what we’re doing, we look at our current situation and really deeply understand what’s happening, we do by understanding what’s currently, by implementing what we’ve agreed to do. Once we’ve done that, we study – just really quickly, has that worked? And based on what happens here, we then go back to either starting again, or spreading, you know planning to spread it out across the organisation. Bu the process focus is here, the outcome focus is here. By focusing on outcome only, you put very little weight on this. Very little weight on this and that becomes a big problem. 

Leadership style and again I’m not talking about leadership of organisation, more generally but in terms of organisation improvement there are particular leadership styles that are important to make sure we encourage and indeed foster improvement. Ultimately when we’re doing leading projects, improvement projects, we have to lead as if we have no power. The easiest way to think about that is, a manager might say, you need to do this. Directive type of approach, you need to look at that. As a leader, people don’t learn when this happens and if we’re trying to build capability and ongoing sustainability, we need to grow people and the way we do that is we ask questions and as a coach, maybe the easiest rule you can think of is you never make a statement, you only ever ask a question. So when we’re leading projects, especially subject matter experts within your hospitals, try and ask questions of the team rather than providing answers or directions for the team. If you put a question mark on the end of all of your sentences you’re gonna grow people cause they’re gonna have to think about it. So, leadership through our projects should be considered as a coach or a teacher and the way we do that is we ask questions. 

Won’t have a look at this too much but this is our leadership style which is top down or bottom up, and whether we are a functional high level general focused or deep and thorough focused, we need to be up here. A deep thorough understanding where we are focused on bottom up and bringing, dragging ideas from our frontline guys up and that’s how we build capability. 

Some of you might have seen this emotional curve of change, and this is important and from a leadership point of view we need to be acutely aware of it so this is our team’s mood if you like and at the start, our team tends to be ignorantly optimistic. They don’t know what they don’t know and we are sold on how great the world’s gonna be when we fix this problem. It’s a good point to start because we can form a team around that optimism. But invariably what happens is, as we unpack the current situation, we enter this pit of informed pessimism. We need to borrow courage to get people out of that pessimism and the way we do that is leadership, lend that courage to the team. What can happen is without leadership is, we flatten out after this. 

Organisational capability, we’ve got about two minutes left so I’ll probably take a bit more than that but we’ll try and quickly get through it. Organisational capability – we’ve got our framework, won’t talk about that too much, our organisational knowledge, time and reward and recognition so our framework which we’ve spoken about all morning is about people need to know what to do when they identify a problem, so if we provide a DMAIC process, we can step them through and tell them what they need, what they’re gonna predict or what they can expect to happen. So say for an improvement idea, if they need help who do they go to.
There is a bit of a balancing act between control if you like, and ease of use. So our quality or governance structure over here, we need to have control and standardisation and alignment, we can’t have people just doing whatever they want, but we need to balance that against ease of use, autonomy and flexibility. So, if you compromise one of these sides to the expense of the other, you’re gonna compromise the outcome. So for instance you can make it super easy and anyone can kinda do anything, people will be engaged because they feel they can do things, but your control and governance is gonna be out of control. And you’re gonna cause more problems than it’s worth, but if you control things too tightly and make it hard for people to make change, people just won’t do it. Or, there’ll be a black market of change which no one ever knows about, which will then affect this. 

Organisational knowledge – I’ll jump through that slide and go to this one here. We have our contributors, they are people who – who – in our teams, we have those active contributors and they’re the guys who are the leaders and they’re the really enthusiastic people and drag people along with them. We have our leaders and they’re the guys who are leading our projects, then we have our SMEs, our subject matter experts and redesign teams and quality and improvement staff. Deliberately shown this upside down because, from the bottom up, these people, their job is to support the leader. The leader’s job is to support these active contributors. And we want our active contributors to support and lead our more general contributors. It’s not the other way around, when we think about the other way around we think about as the leader’s job to do what the SMEs say and the contributors is to do what the leaders say. Think about it the other way around. These are the guys who we are supporting, these contributors, our leaders support them, and SMEs support our leaders. 

Time, let’s not sugar coat it, improvement’s not for free, there is a return in investment in improvement, and certainly in – ultimately that’s what we’re all after but there has to be an investment up front. Things like data collection, team problem solving, training, doesn’t come for free and if we don’t have that, investment, it makes it very difficult for improvement to happen. If you speak to a lot of people about why improvement doesn’t happen, a common thread I often hear is, we just don’t have time. So there has to be dedicated time. 

And reward and recognition, I won’t speak about this but this is what we spoke about before with the firefighter versus a structured improvement. We need to reward, as a health service, as an organisation, we need to reward structured approaches and successful improvements. 

Last thing is daily management. And this is the single biggest thing, my background being LEAN, we’re all about standardisation, daily management, is super important. So let’s just quickly go through that. Standardisation are our bricks and mortar. The minimum amount of standardisation is what we’re aiming for, as long as that ensures we can consistently achieve the right result. So we don’t wanna over-standardise, particularly in health service, we’re full of intelligent people who are able to make intelligent, informed decisions, but there are certain things that we need to make sure that we standardise to make sure that we are predictable, that we are reliable, and that we can train people.

Standardisation also allows us to see when a problem occurs. If everyone does everything differently, everything’s a problem and nothing’s a problem. So if you can’t see problems, you can’t fix problems. All these are examples of standardisation. Progress notes, 5S all, ward awards, patient communication boards, clinical investigation, guidelines, daily meetings, they’re all examples of standardisation. 

Next we need to have an appetite for problems. A part of our daily management needs to be hunting for problems. Failure is not an option, is a rubbish saying. Failure is a must cause if we’re not failing it means our targets are wrong. If our targets are wrong, we don’t have gaps to our target, if we don’t have gaps to our target, we don’t have problems, and therefore we don’t improve. So, we have to fail to be able to find where the improvements are. So step one is, accept that problems happen. We know that these kind of things lead to frustration in our staff. But it gets worse than that. Hopefully you guys will see, or hopefully or hopefully not. But I’m sure you guys will see some examples of this in your own working lives. We see problems as an organisation but we’re too busy to improve. Ultimately that will then lead to frustration, people become frustrated because problems haven’t been fixed and there’s recurring problems. At some point that frustration tips over into apathy and that’s dangerous because what happens when we become apathetic is, we slacken off and lose focus on other things which then leads to more problems, and then those problems then don’t get fixed, leads to more frustration and you’re in this horrible cycle of problems and problems not being fixed. What happens is it starts to rip through things like morale, quality, and improvement. In this kind of world, these things can’t exist. They don’t work at all. And instead of people talking about what we can do to improve, the discussion around the lunch table is about how bad this joint is and we have these long running jokes about, oh, this place is a joke and that department is hopeless and we have these little in-jokes about how bad a place it is to work. And I’m sure you will have seen that before. Lots of organisations fall into this trap, and even specific departments within organisations can fall into this trap. Now there’s only one way out of this. You can’t fix frustration, you can’t address frustration or apathy because the root cause is here when we do our own problem solving on this. Our root cause here is problems that aren’t being addressed. So we break that cycle. We identify problems, we celebrate the identification of problems, as silly as that sounds, we celebrate the identification of problems, we then actively address them through a structured approach, and that inspires confidence and it makes people wanna find another problem because they get addicted. We want these people in our organisation. And the way you do it is you lead by identifying problems and making it comfortable for people to identify problems. People identify problems and they can fix them, people like to win, they’ll be confident, they’ll go looking for the next one. They’ll go looking for the next problem and they can address them and win. 

Visual management – it’s all well and good to talk about identifying problems but if we can’t see the problems, you’re not gonna be able to address them. So visual management is a set of tools we use to quickly interpret our environment around us and help us decide what we need to do. You might – this might look familiar from our define stage in our problem solving, if we can understand, in a visual fashion, what the standard is, so what are target is if you like, what our current status is, and the gap and therefore the problem, we understand, we have a good visual management. Here’s an example of pressure gauge. It’s red around here so it’s very clearly if it’s in here it’s a problem, the standard’s green, and the current status is there, so I can see quickly, whether we have a problem or not. 
In health service, we’ve got many different, maybe not traffic lights but we’ve got our PAS systems or our patient journey boards, we have performance data, as long as you’ve got a target line, that’s the critical part, as long as you’ve got a target line, that’s visual management, if you don’t have a target line, that’s not visual management because you can’t establish where you should be so it’s not called visual management it’s just called wallpaper. And again, more visual management here. What these do is allow us to quickly and easily see when there’s a problem. Now if we can quickly and easily see where there’s a problem, we can then take our structured approach to fixing them. Now there’s two, obviously two parts to visual management the visual part’s easy, we can put something up on the wall, the hard part is the management, is often done poorly or not well, or regularly enough. So think about, it’s well and good to have these problems written on the wall, or in our computer system or wherever they are, but how do we know when they occur, and how do we address them.

Big problems start small and we’ve spoken about visual management, the cadence of management then becomes very important, so if we believe that big problems start small and they start to snowball, that then will inform the cadence of management. So let’s say we manage monthly, and this is not unusual we might have a monthly meeting and at the end of the month three weeks later we might have a review meeting. So that means that the data is seven weeks old by the time we’re actually looking at it. So we have all these problems occur during the month, do you think back to your month? The month just gone? You think about what the biggest problems were, you’d be able to think of some big problems, but you’re gonna miss these other little problems. If you think about the problems you’ve found yesterday, or what got in the way of you doing your work yesterday, you’re gonna think of a lot more problems. And we’ll see these small problems, smaller problems are easier to fix, they’re quicker to fix, and because they’re quicker to fix, you’ll be able to fix more problems. Really it’s from going to a reactive effort of what happened and how do we stop it happening again, through to a proactive effort of wait a second, we can see a problem coming here, let’s get in front of it and fix it before it becomes a problem. If you like, the best analogy I’ve got for it is if you wanna make sure that you don’t speed, you’ve got two ways of managing it. One, you can stand by your letterbox and look for speeding fines to come through, and when they start to come through you think oh maybe I’m speeding I’ll need to stop, reduce my speed when I’m driving around, or you can just watch your speedo as you’re driving around. And from time to time, you’ll go over the speed limit, but as long as you see it quickly enough, it won’t always turn into a fine. But as health services, and not just health services, but a lot of organisations, they manage with this style. They don’t manage the daily, they don’t look at when we’re going over the speed limit, they just wait for the fine to come through and then sit down and talk about why did that fine come through and how do we make sure that fine doesn’t happen in the future. 

And finally front line awareness. Here’s a nice cheesy photo of some front line staff. Front line staff are the people who are providing care to our patients. As an organisation, we need to be highly aware of what they’re doing, because they’re the ones who are adding the value. Our understanding increases as we spend more time down here and this is looking for ourselves so walking our process, spending time on the ward, or spending time in the unit with the people from the units. And spending time on the floor and this is probably more aimed at senior management, shouldn’t be a Contiki tour, it shouldn’t be something you do as a bit of a, as a monthly thing, it’s something that we should be spending our time, every day on the floor, cause what that’ll do, is that’ll help us identify where our problems are, because we can see them for ourselves. Again, the same theme of where are our problems and what do we need to do about them. 

So there’s our very quick half an hour overview of the environmental conditions within an organisation that we need to lead and sustain change. Now, that’s incredibly quick and even the stuff that I did have there, we skipped through reasonably quickly, so we’ll make this content available and certainly I’m available to answer any particular questions that anyone has once we send it out so we’ll send that – a link out to this content with my details there if you wanna have a chat to me about any of this. The only thing I do want to just, harp on about here is this problem solving skill is very important but it is just part of the puzzle. So by all means we need to focus on this and we need to make sure people understand this, but be aware of the rest of this because you can do this really well and it falls over. That’s all I’ve got for you today guys, I do appreciate your time. Hopefully you were able to get something out of it. Like I said this will be made available on our website and we’ll send out a link to you to everyone to make sure that everyone’s able to access that material. But till now – until then, I’ll say thank you very much and goodbye, have a great weekend, and enjoy. Thanks everyone.