Archive for the ‘ISP’ Category

teamwork_puzzle_build_PA_150_wht_2341[Bing bong]. The sound heralded Lesley logging on to the weekly Webex coaching session with Bob, an experienced Improvement Science Practitioner.

<Bob> Good afternoon Lesley.  How has your week been and what topic shall we explore today?

<Lesley> Hi Bob. Well in a nutshell, the bit of the system that I have control over feels like a fragile oasis of calm in a perpetual desert of chaos.  It is hard work keeping the oasis clear of the toxic sand that blows in!

<Bob> A compelling metaphor. I can just picture it.  Maintaining order amidst chaos requires energy. So what would you like to talk about?

<Lesley> Well, I have a small shoal of FISHees who I am guiding  through the foundation shallows and they are getting stuck on Little’s Law.  I confess I am not very good at explaining it and that suggests to me that I do not really understand it well enough either.

<Bob> OK. So shall we link those two theme – chaos and Little’s Law?

<Lesley> That sounds like an excellent plan!

<Bob> OK. So let us refresh the foundation knowledge. What is Little’s Law?

<Lesley>It is a fundamental Law of process physics that relates flow, with lead time and work in progress.

<Bob> Good. And specifically?

<Lesley> Average lead time is equal to the average flow multiplied by the average work in progress.

<Bob>Yes. And what are the units of flow in your equation?

<Lesley> Ah yes! That is  a trap for the unwary. We need to be clear how we express flow. The usual way is to state it as number of tasks in a defined period of time, such as patients admitted per day.  In Little’s Law the convention is to use the inverse of that which is the average interval between consecutive flow events. This is an unfamiliar way to present flow to most people.

<Bob> Good. And what is the reason that we use the ‘interval between events’ form?

<Leslie> Because it is easier to compare it with two critically important  flow metrics … the takt time and the cycle time.

<Bob> And what is the takt time?

<Leslie> It is the average interval between new tasks arriving … the average demand interval.

<Bob> And the cycle time?

<Leslie> It is the shortest average interval between tasks departing …. and is determined by the design of the flow constraint step.

<Bob> Excellent. And what is the essence of a stable flow design?

<Lesley> That the cycle time is less than the takt time.

<Bob>Why less than? Why not equal to?

<Leslie> Because all realistic systems need some flow resilience to exhibit stable and predictable-within-limits behaviour.

<Bob> Excellent. Now describe the design requirements for creating chronically chaotic system behaviour?

<Leslie> This is a bit trickier to explain. The essence is that for chronically chaotic behaviour to happen then there must be two feedback loops – a destabilising loop and a stabilising loop.  The destabilising loop creates the chaos, the stabilising loop ensures it is chronic.

<Bob> Good … so can you give me an example of a destabilising feedback loop?

<Leslie> A common one that I see is when there is a long delay between detecting a safety risk and the diagnosis, decision and corrective action.  The risks are often transitory so if the corrective action arrives long after the root cause has gone away then it can actually destabilise the process and paradoxically increase the risk of harm.

<Bob> Can you give me an example?

<Leslie>Yes. Suppose a safety risk is exposed by a near miss.  A delay in communicating the niggle and a root cause analysis means that the specific combination of factors that led to the near miss has gone. The holes in the Swiss cheese are not static … they move about in the chaos.  So the action that follows the accumulation of many undiagnosed near misses is usually the non-specific mantra of adding yet another safety-check to the already burgeoning check-list. The longer check-list takes more time to do, and is often repeated many times, so the whole flow slows down, queues grow bigger, waiting times get longer and as pressure comes from the delivery targets corners start being cut, and new near misses start to occur; on top of the other ones. So more checks are added and so on.

<Bob> An excellent example! And what is the outcome?

<Leslie> Chronic chaos which is more dangerous, more disordered and more expensive. Lose lose lose.

<Bob> And how do the people feel who work in the system?

<Leslie> Chronically naffed off! Angry. Demotivated. Cynical.

<Bob>And those feelings are the key symptoms.  Niggles are not only symptoms of poor process design, they are also symptoms of a much deeper problem: a violation of values.

<Leslie> I get the first bit about poor design; but what is that second bit about values?

<Bob>  We all have a set of values that we learned when we were very young and that have bee shaped by life experience.  They are our source of emotional energy, and our guiding lights in an uncertain world. Our internal unconscious check-list.  So when one of our values is violated we know because we feel angry. How that anger is directed varies from person to person … some internalise it and some externalise it.

<Leslie> OK. That explains the commonest emotion that people report when they feel a niggle … frustration which is the same as anger.

<Bob>Yes.  And we reveal our values by uncovering the specific root causes of our niggles.  For example if I value ‘Hard Work’ then I will be niggled by laziness. If you value ‘Experimentation’ then you may be niggled by ‘Rigid Rules’.  If someone else values ‘Safety’ then they may value ‘Rigid Rules’ and be niggled by ‘Innovation’ which they interpret as risky.

<Leslie> Ahhhh! Yes, I see.  This explains why there is so much impassioned discussion when we do a 4N Chart! But if this behaviour is so innate then it must be impossible to resolve!

<Bob> Understanding  how our values motivate us actually helps a lot because we are naturally attracted to others who share the same values – because we have learned that it reduces conflict and stress and improves our chance of survival. We are tribal and tribes share the same values.

<Leslie> Is that why different  departments appear to have different cultures and behaviours and why they fight each other?

<Bob> It is one factor in the Silo Wars that are a characteristic of some large organisations.  But Silo Wars are not inevitable.

<Leslie> So how are they avoided?

<Bob> By everyone knowing what common purpose of the organisation is and by being clear about what values are aligned with that purpose.

<Leslie> So in the healthcare context one purpose is avoidance of harm … primum non nocere … so ‘safety’ is a core value.  Which implies anything that is felt to be unsafe generates niggles and well-intended but potentially self-destructive negative behaviour.

<Bob> Indeed so, as you described very well.

<Leslie> So how does all this link to Little’s Law?

<Bob>Let us go back to the foundation knowledge. What are the four interdependent dimensions of system improvement?

<Leslie> Safety, Flow, Quality and Productivity.

<Bob> And one measure of  productivity is profit.  So organisations that have only short term profit as their primary goal are at risk of making poor long term safety, flow and quality decisions.

<Leslie> And flow is the key dimension – because profit is just  the difference between two cash flows: income and expenses.

<Bob> Exactly. One way or another it all comes down to flow … and Little’s Law is a fundamental Law of flow physics. So if you want all the other outcomes … without the emotionally painful disorder and chaos … then you cannot avoid learning to use Little’s Law.

<Leslie> Wow!  That is a profound insight.  I will need to lie down in a darkened room and meditate on that!

<Bob> An oasis of calm is the perfect place to pause, rest and reflect.

wacky_languageAll innovative ideas are inevitably associated with new language.

Familiar words used in an unfamiliar context so that the language sounds ‘wacky’ to those in the current paradigm.

Improvement science is no different.

A problem arises when familiar words are used in a new context and therefore with a different meaning. Confusion.

So we try to avoid this cognitive confusion by inventing new words, or by using foreign words that are ‘correct’ but unfamiliar.

This use of novel and foreign language exposes us to another danger: the evolution of a clique of self-appointed experts who speak the new and ‘wacky’ language.

This self-appointed expert clique can actually hinder change because it can result yet another us-and-them division.  Another tribe. More discussion. More confusion. Less improvement.


So it is important for an effective facilitator-of-improvement to define any new language using the language of the current paradigm.  This can be achieved by sharing examples of new concepts and their language in familiar contexts and with familiar words, because we learn what words mean from their use-in-context.

For example:

The word ‘capacity’ is familiar and we all know what we think it means.  So when we link it to another familiar word, ‘demand’, then we feel comfortable that we understand what the phrase ‘demand-and-capacity’ means.

But do we?

The act of recognising a word is a use of memory or knowledge. Understanding what a word means requires more … it requires knowing the context in which the word is used.  It means understanding the concept that the word is a label for.

To a practitioner of flow science the word ‘capacity’ is confusing – because it is too fuzzy.  There are many different forms of capacity: flow-capacity, space-capacity, time-capacity, and so on.  Each has a different unit and they are not interchangeable. So the unqualified term ‘capacity’ will trigger the question:

What sort of capacity are you referring to?

[And if that is not the reaction then you may be talking to someone who has little understanding of flow science].


Then there are the foreign words that are used as new labels for old concepts.

Lean zealots seem particularly fond of peppering their monologues with Japanese words that are meaningless to anyone else but other Lean zealots.  Words like muda and muri and mura which are labels for important and useful flow science concepts … but the foreign name gives no clue as to what that essential concept is!

[And for a bit of harmless sport ask a Lean zealot to explain what these three words actually mean but only using  language that you understand. If they cannot to your satisfaction then you have exposed the niggle. And if they can then it is worth asking ‘What is the added value of the foreign language?’]

And for those who are curious to know the essential concepts that these four-letter M words refer to:

muda means ‘waste’ and refers to the effects of poor process design in terms of the extra time (and cost) required for the process to achieve its intended purpose.  A linked concept is a ‘niggle’ which is the negative emotional effect of a poor process design.

muri means ‘overburdening’ and can be illustrated  with an example.  Suppose you work in a system where there is always a big backlog of work waiting to be done … a large queue of patients in the waiting room … a big heap of notes on the trolley. That ‘burden’ generates stress and leads to other risky behaviours such as rushing, corner-cutting, deflection and overspill. It is also an outcome of poor process design, so  is avoidable.

mura means variation or uncertainty. Again an example helps. Suppose we are running an emergency service then, by definition, a we have no idea what medical problem the next patient that comes through the door will present us with. It could be trivial or life-threatening. That is unplanned and expected variation and is part of the what we need our service to be designed to handle.  Suppose when we arrive for our shift that we have no idea how many staff will be available to do the work because people phone in sick at the last minute and there is no resilience on the staffing capacity.  Our day could be calm-and-capable (and rewarding) or chaotic-and-incapable (and unrewarding).  It is the stress of not knowing that creates the emotional and cultural damage, and is the expected outcome of incompetent process design. And is avoidable.


And finally we come to words that are not foreign but are not very familiar either.

Words like praxis.

This sounds like ‘practice’ but is not spelt the same. So is the the same?

And it sounds like a medical condition called dyspraxia which means:  poor coordination of movement.

And when we look up praxis in an English dictionary we discover that one definition is:

the practice and practical side of a profession or field of study, as opposed to theory.

Ah ah! So praxis is a label for the the concept of ‘how to’ … and someone who has this ‘know how’ is called a practitioner.  That makes sense.

On deeper reflection we might then describe our poor collective process design capability as dyspraxic or uncoordinated. That feels about right too.


An improvement science practitioner (ISP) is someone who knows the science of improvement; and can demonstrate their know-how in practice; and can explain the principles that underpin their praxis using the language of the learner. Without any wacky language.

So if we want to diagnose and treat our organisational dyspraxia;

… and if we want smooth and efficient services (i.e. elimination of chaos and reduction of cost);

… and if we want to learn this know-how,  practice or praxis;

… then we could study the Foundations of Improvement Science in Healthcare (FISH);

… and we could seek the wisdom of  the growing Community of Healthcare Improvement Practitioners (CHIPs).


FISH & CHIPs … a new use for a familiar phrase?

cardiogram_heart_signal_150_wht_5748[Beep] It was time for the weekly e-mentoring session so Bob switched on his laptop, logged in to the virtual meeting site and found that Lesley was already there.

<Bob> Hi Lesley. What shall we talk about today?

<Lesley> Hello Bob. Another old chestnut I am afraid. Queues.  I keep hitting the same barrier where people who are fed up with the perpetual queue chaos have only one mantra “If you want to avoid long waiting times then we need more capacity.

<Bob> So what is the problem? You know that is not the cause of chronic queues.

<Lesley> Yes, I know that mantra is incorrect – but I do not yet understand how to respectfully challenge it and how to demonstrate why it is incorrect and what the alternative is.

<Bob> OK. I understand. So could you outline a real example that we can work with.

<Lesley> Yes. Another old chestnut: the Emergency Department 4-hour breaches.

<Bob> Do you remember the Myth of Sisyphus?

<Leslie> No, I do not remember that being mentioned in the FISH course.

<Bob> Ho ho! No indeed,  it is much older. In Greek mythology Sisyphus was a king of Ephyra who was punished by the Gods for chronic deceitfulness by being compelled to roll an immense boulder up a hill, only to watch it roll back down, and then to repeat this action forever.

Sisyphus_Cartoon

<Lesley> Ah! I see the link. Yes, that is exactly how people in the ED feel.  Everyday it feels like they are pushing a heavy boulder uphill – only to have to repeat the same labour the next day. And they do not believe it can ever be any better with the resources they have.

<Bob> A rather depressing conclusion! Perhaps a better metaphor is the story in the film  “Ground Hog Day” where Bill Murray plays the part of a rather arrogant newsreader who enters a recurring nightmare where the same day is repeated, over and over. He seems powerless to prevent it.  He does eventually escape when he learns the power of humility and learns how to behave differently.

<Lesley> So the message is that there is a way out of this daily torture – if we are humble enough to learn the ‘how’.

<Bob> Well put. So shall we start?

<Lesley> Yes please!

<Bob> OK. As you know very well it is important not to use the unqualified term ‘capacity’.  We must always state if we are referring to flow-capacity or space-capacity.

<Lesley> Because they have different units and because they are intimately related to lead time by Little’s Law.

<Bob> Yes.  Little’s Law is mathematically proven Law of flow physics – it is not negotiable.

<Lesley> OK. I know that but how does it solve problem we started with?

<Bob> Little’s Law is necessary but it is not sufficient. Little’s Law relates to averages – and is therefore just the foundation. We now need to build the next level of understanding.

<Lesley> So you mean we need to introduce variation?

<Bob> Yes. And the tool we need for this is a particular form of time-series chart called a Vitals Chart.

<Lesley> And I am assuming that will show the relationship between flow, lead time and work in progress … over time ?

<Bob> Exactly. It is the temporal patterns on the Vitals Chart that point to the root causes of the Sisyphean Chaos. The flow design flaws.

<Lesley> Which are not lack of flow-capacity or space-capacity.

<Bob> Correct. If the chaos is chronic then there must already be enough space-capacity and flow-capacity. Little’s Law shows that, because if there were not the system would have failed completely a long time ago. The usual design flaw in a chronically chaotic system is one or more misaligned policies.  It is as if the system hardware is OK but the operating software is not.

<Lesley> So to escape from the Sisyphean Recurring ED 4-Hour Breach Nightmare we just need enough humility and enough time to learn how to diagnose and redesign some of our ED system operating software? Some of our own policies? Some of our own mantras?

<Bob> Yup.  And not very much actually. Most of the software is OK. We need to focus on the flaws.

<Lesley> So where do I start?

<Bob> You need to do the ISP-1 challenge that is called Brainteaser 104.  That is where you learn how to create a Vitals Chart.

<Lesley> OK. Now I see what I need to do and the reason:  understanding how to do that will help me explain it to others. And you are not going to just give me the answer.

<Bob> Correct. I am not going to just give you the answer. You will not fully understand unless you are able to build your own Vitals Chart generator. You will not be able to explain the how to others unless you demonstrate it to yourself first.

<Lesley> And what else do I need to do that?

<Bob> A spreadsheet and your raw start and finish event data.

<Lesley> But we have tried that before and neither I nor the database experts in our Performance Department could work out how to get the real time work in progress from the events – so we assumed we would have to do a head count or a bed count every hour which is impractical.

<Bob> It is indeed possible as you are about to discover for yourself. The fact that we do not know how to do something does not prove that it is impossible … humility means accepting our inevitable ignorance and being open to learning. Those who lack humility will continue to live the Sisyphean Nightmare of ED Ground Hog Day. The choice to escape is ours.

<Lesley> I choose to learn. Please send me BT104.

<Bob> It is on its way …

6MDesignJigsawSystems are made of interdependent parts that link together – rather like a jigsaw.

If pieces are distorted, missing, or in the wrong place then the picture is distorted and the system does not work as well as it could.

And if pieces of one jigsaw are mixed up with those of another then it is even more difficult to see any clear picture.

A system of improvement is just the same.

There are many improvement jigsaws each of which have pieces that fit well together and form a synergistic whole. Lean, Six Sigma, and Theory of Constraints are three well known ones.

Each improvement jigsaw evolved in a different context so naturally the picture that emerges is from a particular perspective: such as manufacturing.

So when the improvement context changes then the familiar jigsaws may not work as well: such as when we shift context from products to services, and from commercial to public.

A public service such as healthcare requires a modified improvement jigsaw … so how do we go about getting that?


One way is to ‘evolve’ an old jigsaw into a new context. That is tricky because it means adding new pieces and changing old pieces and the ‘zealots’ do not like changing their familiar jigsaw so they resist.

Another way is to ‘combine’ several old jigsaws in the hope that together they will provide enough perspectives. That is even more tricky because now you have several tribes of zealots who resist having their familiar jigsaws modified.

What about starting with a blank canvas and painting a new picture from scratch? Well it is actually very difficult to create a blank canvas for learning because we cannot erase what we already know. Our current mental model is the context we need for learning new knowledge.


So what about using a combination of the above?

What about first learning a new creative approach called design? And within that framework we can then create a new improvement jigsaw that better suits our specific context using some of the pieces of the existing ones. We may need to modify the pieces a bit to allow them to fit better together, and we may need to fashion new pieces to fill the gaps that we expose. But that is part of the fun.


6MDesignJigsawThe improvement jigsaw shown here is a new hybrid.

It has been created from a combination of existing improvement knowledge and some innovative stuff.

Pareto analysis was described by Vilfredo Pareto over 100 years ago.  So that is tried and tested!

Time-series charts were invented by Walter Shewhart almost 100 years ago. So they are tried and tested too!

The combination of Pareto and Shewhart tools have been used very effectively for over 50 years. The combination is well proven.

The other two pieces are innovative. They have different parents and different pedigrees. And different purposes.

The Niggle-o-Gram® is related to 2-by-2, FMEA and EIQ and the 4N Chart®.  It is the synthesis of them that creates a powerful lens for focussing our improvement efforts on where the greatest return-on-investment will be.

The Right-2-Left Map® is a descendent of the Design family and has been crossed with Graph Theory and Causal Network exemplars to introduce their best features.  Its purpose is to expose errors of omission.

The emergent system is synergistic … much more effective than each part individually … and more even than their linear sum.


So when learning this new Science of Improvement we have to focus first on learning about the individual pieces and we do that by seeing examples of them used in practice.  That in itself is illuminating!

As we learn about more pieces a fog of confusion starts to form and we run the risk of mutating into a ‘tool-head’.  We know about the pieces in detail but we still do not see the bigger picture.

To avoid the tool-head trap we must balance our learning wheel and ensure that we invest enough time in learning-by-doing.

Then one day something apparently random will happen that triggers a ‘click’.  Familiar pieces start to fit together in a unfamiliar way and as we see the relationships, the sequences, and the synergy – then a bigger picture will start to emerge. Slowly at first and then more quickly as more pieces aggregate.

Suddenly we feel a big CLICK as the final pieces fall into place.  The fog of confusion evaporates in the bright sunlight of a paradigm shift in our thinking.

The way forward that was previously obscured becomes clearly visible.

Ah ha!

And we are off on the next stage  of our purposeful journey of improvement.

egg_face_spooked_400_wht_13421There seems to be a belief among some people that the “optimum” average bed occupancy for a hospital is around 85%.

More than that risks running out of beds and admissions being blocked, 4 hour breaches appearing and patients being put at risk. Less than that is inefficient use of expensive resources. They claim there is a ‘magic sweet spot’ that we should aim for.

Unfortunately, this 85% optimum occupancy belief is a myth.

So, first we need to dispel it, then we need to understand where it came from, and then we are ready to learn how to actually prevent queues, delays, disappointment, avoidable harm and financial non-viability.


Disproving this myth is surprisingly easy.   A simple thought experiment is enough.

Suppose we have a policy where  we keep patients in hospital until someone needs their bed, then we discharge the patient with the longest length of stay and admit the new one into the still warm bed – like a baton pass.  There would be no patients turned away – 0% breaches.  And all our the beds would always be full – 100% occupancy. Perfection!

And it does not matter if the number of admissions arriving per day is varying – as it will.

And it does not matter if the length of stay is varying from patient to patient – as it will.

We have disproved the hypothesis that a maximum 85% average occupancy is required to achieve 0% breaches.


The source of this specific myth appears to be a paper published in the British Medical Journal in 1999 called “Dynamics of bed use in accommodating emergency admissions: stochastic simulation model

So it appears that this myth was cooked up by academic health economists using a computer model.

And then amateur queue theory zealots jump on the band-wagon to defend this meaningless mantra and create a smoke-screen by bamboozling the mathematical muggles with tales of Poisson processes and Erlang equations.

And they are sort-of correct … the theoretical behaviour of the “ideal” stochastic demand process was described by Poisson and the equations that describe the theoretical behaviour were described by Agner Krarup Erlang.  Over 100 years ago before we had computers.

BUT …

The academics and amateurs conveniently omit one minor, but annoying,  fact … that real world systems have people in them … and people are irrational … and people cook up policies that ride roughshod over the mathematics, the statistics and the simplistic, stochastic mathematical and computer models.

And when creative people start meddling then just about anything can happen!


So what went wrong here?

One problem is that the academic hefalumps unwittingly stumbled into a whole minefield of pragmatic process design traps.

Here are just some of them …

1. Occupancy is a ratio – it is a meaningless number without its context – the flow parameters.

2. Using linear, stochastic models is dangerous – they ignore the non-linear complex system behaviours (chaos to you and me).

3. Occupancy relates to space-capacity and says nothing about the flow-capacity or the space-capacity and flow-capacity scheduling.

4. Space-capacity utilisation (i.e. occupancy) and systemic operational efficiency are not equivalent.

5. Queue theory is a simplification of reality that is needed to make the mathematics manageable.

6. Ignoring the fact that our real systems are both complex and adaptive implies that blind application of basic queue theory rhetoric is dangerous.

And if we recognise and avoid these traps and we re-examine the problem a little more pragmatically then we discover something very  useful:

That the maximum space capacity requirement (the number of beds needed to avoid breaches) is actually easily predictable.

It does not need a black-magic-box full of scary queue theory equations or rather complicated stochastic simulation models to do this … all we need is our tried-and-trusted tool … a spreadsheet.

And we need something else … some flow science training and some simulation model design discipline.

When we do that we discover something else …. that the expected average occupancy is not 85%  … or 65%, or 99%, or 95%.

There is no one-size-fits-all optimum occupancy number.

And as we explore further we discover that:

The expected average occupancy is context dependent.

And when we remember that our real system is adaptive, and it is staffed with well-intended, well-educated, creative people (who may have become rather addicted to reactive fire-fighting),  then we begin to see why the behaviour of real systems seems to defy the predictions of the 85% optimum occupancy myth:

Our hospitals seem to work better-than-predicted at much higher occupancy rates.

And then we realise that we might actually be able to design proactive policies that are better able to manage unpredictable variation; better than the simplistic maximum 85% average occupancy mantra.

And finally another penny drops … average occupancy is an output of the system …. not an input. It is an effect.

And so is average length of stay.

Which implies that setting these output effects as causal inputs to our bed model creates a meaningless, self-fulfilling, self-justifying delusion.

Ooops!


Now our challenge is clear … we need to learn proactive and adaptive flow policy design … and using that understanding we have the potential to deliver zero delays and high productivity at the same time.

And doing that requires a bit more than a spreadsheet … but it is possible.

lightning_strike_150_wht_5809[Drrrrring Drrrrring]

<Bob> Hi Lesley! How are you today?

<Leslie> Hi Bob.  Really good.  I have just got back from a well earned holiday so I am feeling refreshed and re-energised.

<Bob> That is good to hear.  It has been a bit stormy here over the past few weeks.  Apparently lots of  hot air hitting cold reality and forming a fog of disillusionment and storms of protest.

<Leslie> Is that a metaphor?

<Bob> Yes!  A good one do you think? And it leads us into our topic for this week. Perfect storms.

<Leslie> I am looking forward to it.  Can you be a bit more specific?

<Bob> Sure.  Remember the ISP exercise where I asked you to build a ‘chaos generator’?

<Leslie> I sure do. That was an eye-opener!  I had no idea how easy it is to create chaotic performance in a system – just by making the Flaw of Averages error and adding a pinch of variation. Booom!

<Bob> Good. We are going to use that model to demonstrate another facet of system design.  How to steer out of chaos.

<Leslie> OK – what do I need to do.

<Bob> Start up that model and set the cycle time to 10 minutes with a sigma of 1.5 minutes.

<Leslie> OK.

<Bob> Now set the demand interval to 10 minutes and the sigma of that to 2.0 minutes.

<Leslie> OK. That is what I had before.

<Bob> Set the lead time upper specification limit to 30 minutes. Run that 12 times and record the failure rate.

<Leslie> OK.  That gives a chaotic picture!  All over the place.

<Bob> OK now change just the average of the demand interval.  Start with a value of 8 minutes, run 12 times, and then increase to 8.5 minutes and repeat that up to 12 minutes.

<Leslie> OK. That will repeat the run for 10 minutes. Is that OK.

<Bob> Yes.

<Leslie> OK … it will take me a few minutes to run all these.  Do you want to get a cup of tea while I do that?

<Bob> Good idea.

[5 minutes later]

<Leslie> OK I have done all that – 108 data points. Do I plot that as a run chart?

<Bob> You could.  I suggest plotting as a scattergram.

<Leslie> With the average demand interval on the X axis and the Failure % on the  Y axis?

<Bob> Yes. Exactly so. And just the dots, no lines.

<Leslie> OK. Wow! That is amazing!  Now I see why you get so worked up about the Flaw of Averages!

<Bob> What you are looking at is called a performance curve.  Notice how steep and fuzzy it is. That is called a chaotic transition. The perfect storm.  And when fall into the Flaw of Averages trap we design our systems to be smack in the middle of it.

<Leslie> Yes I see what you are getting at.  And that implies that to calm the chaos we do not need very much resilient flow capacity … and we could probably release that just from a few minor design tweaks.

<Bob> Yup.

<Leslie> That is so cool. I cannot wait to share this with the team. Thanks again Bob.

pirate_flag_anim_150_wht_12881[Drrring Drrring] The phone heralded the start of the weekly ISP mentoring session.

<Bob> Hi Leslie, how are you today?

<Leslie> Hi Bob. To be honest I am not good. I am drowning. Drowning in data!

<Bob> Oh dear! I am sorry to hear that. Can I help? What led up to this?

<Leslie> Well, it was sort of triggered by our last chat and after you opened my eyes to the fact that we habitually throw most of our valuable information away by thresholding, aggregating and normalising.  Then we wonder why we make poor decisions … and then we get frustrated because nothing seems to improve.

<Bob> OK. What happened next?

<Leslie> I phoned our Performance Team and asked for some raw data. Three months worth.

<Bob> And what was their reaction?

<Leslie> They said “OK, here you go!” and sent me a twenty megabyte Excel spreadsheet that clogged my email inbox!  I did manage to unclog it eventually by deleting loads of old junk.  But I could swear that I heard the whole office laughing as they hung up the phone! Maybe I am paranoid?

<Bob> OK. And what happened next?

<Leslie> I started drowning!  The mega-file had a row of data for every patient that has attended A&E for the last three months as I had requested, but there were dozens of columns!  Trying to slice-and-dice it was a nightmare! My computer was smoking and each step took ages for it to complete.  In the end I gave up in frustration.  I now have a lot more respect for the Performance Team I can tell you! They do this for a living?

<Bob> OK.  It sounds like you are ready for a Stab At the Vitals.

<Leslie> What?  That sounds rather piratical!  Are you making fun of my slicing-and-dicing metaphor?

<Bob> No indeed.  I am deadly serious!  Before we leap into the data ocean we need to be able to swim; and we also need a raft that will keep us afloat;  and we need a sail to power our raft; and we need a way to navigate our raft to our desired destination.

<Leslie> OK. I like the nautical metaphor but how does it help?

<Bob> Let me translate. Learning to use system behaviour charts is equivalent to learning the skill of swimming. We have to do that first and practice until we are competent and confident.  Let us call our raft “ISP” – you are already aboard.  The sail you also have already – your Excel software.  The navigation aid is what I refer to as Vitals. So we need to have a “stab at the vitals”.

<Leslie> Do you mean we use a combination of time-series charts, ISP and Excel to create a navigation aid that helps avoid the Depths of Data and the Rocks of DRAT?

<Bob> Exactly.

<Leslie> Can you demonstrate with an example?

<Bob> Sure. Send me some of your data … just the arrival and departure events for one day – a typical one.

<Leslie> OK … give me a minute!  …  It is on its way.  How long will it take for you to analyse it?

<Bob> About 2 seconds. OK, here is your email … um … copy … paste … copy … reply

Vitals_Charts<Leslie> What the ****? That was quick! Let me see what this is … the top left chart is the demand, activity and work-in-progress for each hour; the top right chart is the lead time by patient plotted in discharge order; the table bottom left includes the 4 hour breach rate.  Those I do recognise. What is the chart on the bottom right?

<Bob> It is a histogram of the lead times … and it shows a problem.  Can you see the spike at 225 to 240 minutes?

<Leslie> Is that the fabled Horned Gaussian?

<Bob> Yes.  That is the sign that the 4-hour performance target is distorting the behaviour of the system.  And this is yet another reason why the  Breach Rate is a dangerous management metric. The adaptive reaction it triggers amplifies the variation and fuels the chaos.

<Leslie> Wow! And you did all that in Excel using my data in two seconds?  That must need a whole host of clever macros and code!

<Bob> “Yes” it was done in Excel and “No” it does not need any macros or code.  It is all done using simple formulae.

<Leslie> That is fantastic! Can you send me a copy of your Excel file?

<Bob> Nope.

<Leslie>Whaaaat? Why not? Is this some sort of evil piratical game?

<Bob> Nope. You are going to learn how to do this yourself – you are going to build your own Vitals Chart Generator – because that is the only way to really understand how it works.

<Leslie> Phew! You had me going for a second there! Bring it on! What do I do next?

<Bob> I will send you the step-by-step instructions of how to build, test and use a Vitals Chart Generator.

<Leslie> Thanks Bob. I cannot wait to get started! Weigh anchor and set the sails! Ha’ harrrr me hearties.

We_Need_Small_HospitalsThis was an interesting headline to see on the front page of a newspaper yesterday!

The Top Man of the NHS is openly challenging the current Centralisation-is-The-Only-Way-Forward Mantra;  and for good reason.

Mass centralisation is poor system design – very poor.

Q: So what is driving the centralisation agenda?

A: Money.

Or to be more precise – rather simplistic thinking about money.

The misguided money logic goes like this:

1. Resources (such as highly trained doctors, nurses and AHPs) cost a lot of money to provide.
[Yes].

2. So we want all these resources to be fully-utilised to get value-for-money.
[No, not all – just the most expensive].

3. So we will gather all the most expensive resources into one place to get the Economy-of-Scale.
[No, not all the most expensive – just the most specialised]

4. And we will suck /push all the work through these super-hubs to keep our expensive specialist resources busy all the time.
[No, what about the growing population of older folks who just need a bit of expert healthcare support, quickly, and close to home?]

This flawed logic confuses two complementary ways to achieve higher system productivity/economy/value-for-money without  sacrificing safety:

Economies of Scale (EoS) and Economies of Flow (EoF).

Of the two the EoF is the more important because by using EoF principles we can increase productivity in huge leaps at almost no cost; and without causing harm and disappointment. EoS are always destructive.

But that is impossible. You are talking rubbish … because if it were possible we would be doing it!

It is not impossible and we are doing it … but not at scale and pace in healthcare … and the reason for that is we are not trained in Economy-of-Flow methods.

And those who are trained and who have have experienced the effects of EoF would not do it any other way.

Example:

In a recent EoF exercise an ISP (Improvement Science Practitioner) helped a surgical team to increase their operating theatre productivity by 30% overnight at no cost.  The productivity improvement was measured and sustained for most of the last year. [it did dip a bit when the waiting list evaporated because of the higher throughput, and again after some meddlesome middle management madness was triggered by end-of-financial-year target chasing].  The team achieved the improvement using Economy of Flow principles and by re-designing some historical scheduling policies. The new policies  were less antagonistic. They were designed to line the ducks up and as a result the flow improved.


So the specific issue of  Super Hospitals vs Small Hospitals is actually an Economy of Flow design challenge.

But there is another critical factor to take into account.

Specialisation.

Medicine has become super-specialised for a simple reason: it is believed that to get ‘good enough’ at something you have to have a lot of practice. And to get the practice you have to have high volumes of the same stuff – so you need to specialise and then to sort undifferentiated work into separate ‘speciologist’ streams or sequence the work through separate speciologist stages.

Generalists are relegated to second-class-citizen status; mere tripe-skimmers and sign-posters.

Specialisation is certainly one way to get ‘good enough’ at doing something … but it is not the only way.

Another way to learn the key-essentials from someone who already knows (and can teach) and then to continuously improve using feedback on what works and what does not – feedback from everywhere.

This second approach is actually a much more effective and efficient way to develop expertise – but we have not been taught this way.  We have only learned the scrape-the-burned-toast-by-suck-and-see method.

We need to experience another way.

We need to experience rapid acquisition of expertise!

And being able to gain expertise quickly means that we can become expert generalists.

There is good evidence that the broader our skill-set the more resilient we are to change, and the more innovative we are when faced with novel challenges.

In the Navy of the 1800’s sailors were “Jacks of All Trades and Master of One” because if only one person knew how to navigate and they got shot or died of scurvy the whole ship was doomed.  Survival required resilience and that meant multi-skilled teams who were good enough at everything to keep the ship afloat – literally.


Specialisation has another big drawback – it is very expensive and on many dimensions. Not just Finance.

Example:

Suppose we have six-step process and we have specialised to the point where an individual can only do one step to the required level of performance (safety/flow/quality/productivity).  The minimum number of people we need is six and the process only flows when we have all six people. Our minimum costs are high and they do not scale with flow.

If any one of the six are not there then the whole process stops. There is no flow.  So queues build up and smooth flow is sacrificed.

Out system behaves in an unstable and chaotic feast-or-famine manner and rapidly shifting priorities create what is technically called ‘thrashing’.

And the special-six do not like the constant battering.

And the special-six have the power to individually hold the whole system to ransom – they do not even need to agree.

And then we aggravate the problem by paying them the high salary that it is independent of how much they collectively achieve.

We now have the perfect recipe for a bigger problem!  A bunch of grumpy, highly-paid specialists who blame each other for the chaos and who incessantly clamour for ‘more resources’ at every step.

This is not financially viable and so creates the drive for economy-of-scale thinking in which to get us ‘flow resilience’ we need more than one specialist at each of the six steps so that if one is on holiday or off sick then the process can still flow.  Let us call these tribes of ‘speciologists’ there own names and budgets, and now we need to put all these departments somewhere – so we will need a big hospital to fit them in – along with the queues of waiting work that they need.

Now we make an even bigger design blunder.  We assume the ‘efficiency’ of our system is the same as the average utilisation of all the departments – so we trim budgets until everyone’s utilisation is high; and we suck any-old work in to ensure there is always something to do to keep everyone busy.

And in so doing we sacrifice all our Economy of Flow opportunities and we then scratch our heads and wonder why our total costs and queues are escalating,  safety and quality are falling, the chaos continues, and our tribes of highly-paid specialists are as grumpy as ever they were!   It must be an impossible-to-solve problem!


Now contrast that with having a pool of generalists – all of whom are multi-skilled and can do any of the six steps to the required level of expertise.  A pool of generalists is a much more resilient-flow design.

And the key phrase here is ‘to the required level of expertise‘.

That is how to achieve Economy-of-Flow on a small scale without compromising either safety or quality.

Yes, there is still a need for a super-level of expertise to tackle the small number of complex problems – but that expertise is better delivered as a collective-expertise to an individual problem-focused process.  That is a completely different design.

Designing and delivering a system that that can achieve the synergy of the pool-of-generalists and team-of-specialists model requires addressing a key error of omission first: we are not trained how to do this.

We are not trained in Complex-Adaptive-System Improvement-by-Design.

So that is where we must start.

 

writing_on_the_wallThe writing is on the wall for the NHS.

It is called the Francis Report and there is a lot of it. Just the 290 recommendations runs to 30 pages. It would need a very big wall and very small writing to put it all up there for all to see.

So predictably the speed-readers have latched onto specific words – such as “Inspectors“.

Recommendation 137Inspection should remain the central method for monitoring compliance with fundamental standards.”

And it goes further by recommending “A specialist cadre of hospital inspectors should be established …”

A predictable wail of anguish rose from the ranks “Not more inspectors! The last lot did not do much good!”

The word “cadre” is not one that is used in common parlance so I looked it up:

Cadre: 1. a core group of people at the center of an organization, especially military; 2. a small group of highly trained people, often part of a political movement.

So it has a military, centralist, specialist, political flavour. No wonder there was a wail of anguish! Perhaps this “cadre of inspectors” has been unconsciously labelled with another name? Persecutors.

Of more interest is the “highly trained” phrase. Trained to do what? Trained by whom? Clearly none of the existing schools of NHS management who have allowed the fiasco to happen in the first place. So who – exactly? Are these inspectors intended to be protectors, persecutors, or educators?

And what would they inspect?

And how would they use the output of such an inspection?

Would the fear of the inspection and its possible unpleasant consequences be the stick to motivate compliance?

Is the language of the Francis Report going to create another brick wall of resistance from the rubble of the ruins of the reputation of the NHS?  Many self-appointed experts are already saying that implementing 290 recommendations is impossible.

They are incorrect.

The number of recommendations is a measure of the breadth and depth of the rot. So the critical-to-success factor is to implement them in a well-designed order. Get the first few in place and working and the rest will follow naturally.  Get the order wrong and the radical cure will kill the patient.

So where do we start?

Let us look at the inspection question again.  Why would we fear an external inspection? What are we resisting? There are three facets to this: first we do not know what is expected of us;  second we do not know if we can satisfy the expectation; and third we fear being persecuted for failing to achieve the impossible.

W Edwards Deming used a very effective demonstration of the dangers of well-intended but badly-implemented quality improvement by inspection: it was called the Red Bead Game.  The purpose of the game was to illustrate how to design an inspection system that actually helps to achieve the intended goal. Sustained improvement.

This is applied Improvement Science and I will illustrate how it is done with a real and current example.


I am assisting a department in a large NHS hospital to improve the quality of their service. I have been sent in as an external inspector.  The specific quality metric they have been tasked to improve is the turnaround time of the specialist work that they do. This is a flow metric because a patient cannot leave hospital until this work is complete – and more importantly it is a flow and quality metric because when the hospital is full then another patient, one who urgently needs to be admitted, will be waiting for the bed to be vacated. One in one out.

The department have been set a standard to meet, a target, a specification, a goal. It is very clear and it is easily measurable. They have to turnaround each job of work in less than 2 hours.  This is called a lead time specification and it is arbitrary.  But it is not unreasonable from the perspective of the patient waiting to leave and for the patient waiting to be admitted. Neither want to wait.

The department has a sophisticated IT system that measures their performance. They use it to record when each job starts and when each job is finished and from those two events the software calculates the lead time for each job in real-time. At the end of each day the IT system counts how many jobs were completed in less than 2 hours and compares this with how many were done in total and calculates a ratio which it presents as a percentage in the range of 0 and 100. This is called the process yield.  The department are dedicated and they work hard and they do all the work that arrives each day the same day – no matter how long it takes. And at the end of each day they have their score for that day. And it is almost never 100%.  Not never. Almost never. But it is not good enough and they are being blamed for it. In turn they blame others for making their job more difficult. It is a blame-game and it has been going on for years.

So how does an experienced Improvement Science-trained Inspector approach this sort of “wicked” problem?

First we need to get the writing on the wall – we need to see the reality – we need to “plot the dots” – we need to see what the performance is doing over time – we need to see the voice of the process. And that requires only their data, a pencil, some paper and for the chart to be put on the on the wall where everyone can see it.

Chart_1This is what their daily % yield data for three consecutive weeks looked like as a time-series chart. The thin blue line is the 100% yield target.

The 100% target was only achieved on three days – and they were all Sundays. On the other Sunday it was zero (which may mean that there was no data to calculate a ratio from).

There is wide variation from one day to the next and it is the variation as well as the average that is of interest to an improvement scientist. What is the source of the variation it? If 100% yield can be achieved some days then what is different about those days?

Chart_2

So our Improvement science-trained Inspector will now re-plot the data in a different way – as rational groups. This exposes the issue clearly. The variation on Weekends is very wide and the performance during the Weekdays is much less variable.  What this says is that the weekend system and the weekday system are different. This means that it is invalid to combine the data for both.

It also raises the question of why there is such high variation in yield only at weekends?  The chart cannot answer the question, so our IS-trained Inspector digs a bit deeper and discovers that the volume of work done at the weekend is low, the staffing of the department is different, and that the recording of the events is less reliable. In short – we cannot even trust the weekend data – so we have two reasons to justify excluding it from our chart and just focusing on what happens during the week.

Chart_3We re-plot our chart, marking the excluded weekend data as not for analysis.

We can now see that the weekday performance of our system is visible, less variable, and the average is a long way from 100%.

The team are working hard and still only achieving mediocre performance. That must mean that they need something that is missing. Motivating maybe. More people maybe. More technology maybe.  But there is no more money for more people or technology and traditional JFDI motivation does not seem to have helped.

This looks like an impossible task!

Chart_4

So what does our Inspector do now? Mark their paper with a FAIL and put them on the To Be Sacked for Failing to Meet an Externally Imposed Standard heap?

Nope.

Our IS-trained Inspector calculates the limits of expected performance from the data  and plots these limits on the chart – the red lines.  The computation is not difficult – it can be done with a calculator and the appropriate formula. It does not need a sophisticated IT system.

What this chart now says is “The current design of this process is capable of delivering between 40% and 85% yield. To expect it do do better is unrealistic”.  The implication for action is “If we want 100% yield then the process needs to be re-designed.” Persecution will not work. Blame will not work. Hoping-for-the-best will not work. The process must be redesigned.

Our improvement scientist then takes off the Inspector’s hat and dons the Designer’s overalls and gets to work. There is a method to this and it is called 6M Design®.

Chart_5

First we need to have a way of knowing if any future design changes have a statistically significant impact – for better or for worse. To do this the chart is extended into the future and the red lines are projected forwards in time as the black lines called locked-limits.  The new data is compared with this projected baseline as it comes in.  The weekends and bank holidays are excluded because we know that they are a different system. On one day (20/12/2012) the yield was surprisingly high. Not 100% but more than the expected upper limit of 85%.

Chart_6The alerts us to investigate and we found that it was a ‘hospital bed crisis’ and an ‘all hands to the pumps’ distress call went out.

Extra capacity was pulled to the process and less urgent work was delayed until later.  It is the habitual reaction-to-a-crisis behaviour called “expediting” or “firefighting”.  So after the crisis had waned and the excitement diminished the performance returned to the expected range. A week later the chart signals us again and we investigate but this time the cause was different. It was an unusually quiet day and there was more than enough hands on the pumps.

Both of these days are atypically good and we have an explanation for each of them. This is called an assignable cause. So we are justified in excluding these points from our measure of the typical baseline capability of our process – the performance the current design can be expected to deliver.

An inexperienced manager might conclude from these lessons that what is needed is more capacity. That sounds and feels intuitively obvious and it is correct that adding more capacity may improve the yield – but that does not prove that lack of capacity is the primary cause.  There are many other causes of long lead times  just as there are many causes of headaches other than brain tumours! So before we can decide the best treatment for our under-performing design we need to establish the design diagnosis. And that is done by inspecting the process in detail. And we need to know what we are looking for; the errors of design commission and the errors of design omission. The design flaws.

Only a trained and experienced process designer can spot the flaws in a process design. Intuition will trick the untrained and inexperienced.


Once the design diagnosis is established then the redesign stage can commence. Design always works to a specification and in this case it was clear – to significantly improve the yield to over 90% at no cost.  In other words without needing more people, more skills, more equipment, more space, more anything. The design assignment was made trickier by the fact that the department claimed that it was impossible to achieve significant improvement without adding extra capacity. That is why the Inspector had been sent in. To evaluate that claim.

The design inspection revealed a complex adaptive system – not a linear, deterministic, production-line that manufactures widgets.  The department had to cope with wide variation in demand, wide variation in quality of request, wide variation in job complexity, and wide variation in urgency – all at the same time.  But that is the nature of healthcare and acute hospital work. That is the expected context.

The analysis of the current design revealed that it was not well suited for this requirement – and the low yield was entirely predictable. The analysis also revealed that the root cause of the low yield was not lack of either flow-capacity or space-capacity.

This insight led to the suggestion that it would be possible to improve yield without increasing cost. The department were polite but they did not believe it was possible. They had never seen it, so why should they be expected to just accept this on faith?

Chart_7So, the next step was to develop, test and demonstrate a new design and that was done in three stages. The final stage was the Reality Test – the actual process design was changed for just one day – and the yield measured and compared with the predicted improvement.

This was the validity test – the proof of the design pudding. And to visualise the impact we used the same technique as before – extending the baseline of our time-series chart, locking the limits, and comparing the “after” with the “before”.

The yellow point marks the day of the design test. The measured yield was well above the upper limit which suggested that the design change had made a significant improvement. A statistically significant improvement.  There was no more capacity than usual and the day was not unusually quiet. At the end of the day we held a team huddle.

Our first question was “How did the new design feel?” The consensus was “Calmer, smoother, fewer interruptions” and best of all “We finished on time – there was no frantic catch up at the end of the day and no one had to stay late to complete the days work!”

The next question was “Do we want to continue tomorrow with this new design or revert back to the old one?” The answer was clear “Keep going with the new design. It feels better.”

The same chart was used to show what happened over the next few days – excluding the weekends as before. The improvement was sustained – it did not revert to the original because the process design had been changed. Same work, same capacity, different process – higher yield. The red flags on the charts mark the statistically significant evidence of change and the cluster of red flags is very strong statistical evidence that the improvement is not due to chance.

The next phase of the 6M Design® method is to continue to monitor the new process to establish the new baseline of expectation. That will require at least twelve data points and it is in progress. But we have enough evidence of a significant improvement. This means that we have no credible justification to return to the old design, and it also implies that it is no longer valid to compare the new data against the old projected limits. Our chart tells us that we need to split the data into before-and-after and to calculate new averages and limits for each segment separately. We have changed the voice of the process by changing the design.

Chart_8And when we split the data at the point-of-change then the red flags disappear – which means that our new design is stable. And it has a new capability – a better one. We have moved closer to our goal of 100% yield. It is still early days and we do not really have enough data to calculate the new capability.

What we can say is that we have improved average quality yield from 63% to about 90% at no cost using a sequence of process diagnose, design, deliver.  Study-Plan-Do.

And we have hard evidence that disproves the impossibility hypothesis.


And that was the goal of the first design change – it was not to achieve 100% yield in one jump. Our design simulation had predicted an improvement to about 90%.  And there are other design changes to follow that need this stable foundation to build on.  The order of implementation is critical – and each change needs time to bed in before the next change is made. That is the nature of the challenge of improving a complex adaptive system.

The cost to the department was zero but the benefit was huge.  The bigger benefit to the organisation was felt elsewhere – the ‘customers’ saw a higher quality, quicker process – and there will be a financial benefit for the whole system. It will be difficult to measure with our current financial monitoring systems but it will be real and it will be there – lurking in the data.

The improvement required a trained and experienced Inspector/Designer/Educator to start the wheel of change turning. There are not many of these in the NHS – but the good news is that the first level of this training is now available.

What this means for the post-Francis Report II NHS is that those who want to can choose to leap over the wall of resistance that is being erected by the massing legions of noisy cynics. It means we can all become our own inspectors. It means we can all become our own improvers. It means we can all learn to redesign our systems so that they deliver higher safety, better quality, more quickly and at no extra one-off or recurring cost.  We all can have nothing to fear from the Specialist Cadre of Hospital Inspectors.

The writing is on the wall.


15/02/2013 – Two weeks in and still going strong. The yield has improved from 63% to 92% and is stable. Improvement-by-design works.

10/03/2013 – Six weeks in and a good time to test if the improvement has been sustained.

TTO_Yield_WeeklyThe chart is the weekly performance plotted for 17 weeks before the change and for 5 weeks after. The advantage of weekly aggregated data is that it removes the weekend/weekday 7-day cycle and reduces the effect of day-to-day variation.

The improvement is obvious, significant and has been sustained. This is the objective improvement. More important is the subjective improvement.

Here is what Chris M (departmental operational manager) wrote in an email this week (quoted with permission):

Hi Simon

It is I who need to thank you for explaining to me how to turn our pharmacy performance around and ultimately improve the day to day work for the pharmacy team (and the trust staff). This will increase job satisfaction and make pharmacy a worthwhile career again instead of working in constant pressure with a lack of achievement that had made the team feel rather disheartened and depressed. I feel we can now move onwards and upwards so thanks for the confidence boost.

Best wishes and many thanks

Chris

This is what Improvement Science is all about!