{"id":2208,"date":"2012-10-20T11:01:54","date_gmt":"2012-10-20T11:01:54","guid":{"rendered":"http:\/\/www.saasoft.com\/blog\/?p=2208"},"modified":"2024-01-06T11:56:10","modified_gmt":"2024-01-06T11:56:10","slug":"look-out-for-the-time-trap","status":"publish","type":"post","link":"https:\/\/hcse.blog\/?p=2208","title":{"rendered":"Look Out For The Time Trap!"},"content":{"rendered":"

\"\"<\/a>There is a common\u00a0system ailment which\u00a0every\u00a0Improvement Scientist needs to know how to manage.<\/p>\n

In fact, it is probably the commonest.<\/p>\n

The\u00a0Symptoms: Disappointingly long waiting times and<\/strong> all resources running flat out<\/em>.<\/p>\n

The Diagnosis?\u00a0 90%+ of\u00a0managers say “It is obvious – lack of capacity!”.<\/p>\n

The Treatment? 90%+ of\u00a0managers say “It is obvious – more capacity!!”<\/p>\n

Intuitively obvious maybe – but unfortunately these are incorrect answers. Which\u00a0implies that 90%+ of managers\u00a0do not understand how their systems work. That is a bit of a worry.\u00a0 Lament not though – misunderstanding is a treatable symptom of an endemic system disease called agnosia <\/strong>(=not knowing).<\/p>\n

The\u00a0correct answer is\u00a0“I do not yet have enough information to make a diagnosis<\/em>“.<\/p>\n

This answer is more helpful than it looks because it prompts\u00a0four other questions:<\/p>\n

Q1. “What other possible system diagnoses are there that could cause this pattern of symptoms?”
\nQ2. “What do I need to know to distinguish these system diagnoses?”
\nQ3. “How would I treat the different ones?”
\nQ4. “What is the risk of making the wrong system diagnosis and applying the wrong treatment?”<\/p>\n

\n

Before we start\u00a0on this list we need to set\u00a0out a few ground rules that will protect us from\u00a0more intuitive errors (see last week).<\/p>\n

The first Rule is this:<\/p>\n

Rule #1: Data without context is meaningless.<\/strong><\/p>\n

For example 130<\/strong>\u00a0 is a number – it is data. 130<\/strong> what? 130<\/strong> mmHg. Ah ha! The “mmHg” is the units – it means millimetres of mercury<\/em> and it tells us this data is a pressure.\u00a0But what, where, when,who, how and why? We need more context.<\/p>\n

“The systolic blood pressure measured in the left arm of Joe Bloggs, a 52 year old\u00a0male, using an Omron\u00a0M2\u00a0oscillometric\u00a0manometer on\u00a0Saturday\u00a020th\u00a0October 2012 at 09:00 is 130<\/strong> mmHg”.<\/em><\/p>\n

The\u00a0extra context makes the data much more informative. The data has become information<\/strong>.<\/p>\n

To understand what\u00a0the information\u00a0actually means requires some prior knowledge<\/strong>.\u00a0We need to know what “systolic” means and what an “oscillometric manometer” is and the\u00a0relevance of the “52 year old male”.\u00a0 This\u00a0ability to extract meaning from\u00a0information has two parts – the ability to recognise the language – the syntax; and the ability to understand<\/strong> the concepts that the words are just labels for; the semantics.<\/p>\n

To use this deeper understanding to make a wise decision to do something (or not) requires something else. Exploring that would\u00a0\u00a0distract us from our current purpose. The point is made.<\/p>\n

Rule #1: Data without context is meaningless<\/em>.<\/p>\n

In fact it is worse than meaningless – it is dangerous<\/strong>. And it is dangerous because when the context is missing we rarely\u00a0stop and ask for it – we rush ahead and fill the context gaps with assumptions. We fill the context gaps with beliefs, prejudices, gossip, intuitive leaps, and sometimes even plain guesses.<\/p>\n

This is dangerous – because the same data in a different context\u00a0may have a completely\u00a0different meaning.<\/p>\n

To illustrate.\u00a0\u00a0If\u00a0we change one word in the context – if\u00a0we change “systolic” to “diastolic” then the whole\u00a0meaning changes from one of likely normality\u00a0that probably needs no action; to one of serious abnormality that definitely does.\u00a0 If we missed that critical word out then we are in danger of assuming that the data is systolic blood pressure – because that is the most likely given the number.\u00a0 And we run the risk of missing a common, potentially fatal and completely treatable disease called Stage 2 hypertension.<\/p>\n

There is a second rule that we must always<\/strong> apply when using data from systems. It is this:<\/p>\n

Rule #2:\u00a0Plot time-series data as a chart – a system behaviour chart (SBC).<\/strong><\/p>\n

The reason for the second rule is because the first question we always ask\u00a0about any system must be\u00a0“Is\u00a0our system stable?”<\/em><\/p>\n

Q: What do\u00a0we mean by the word “stable”? What is the concept that this word is a label for?<\/p>\n

A: Stable means predictable-within-limits<\/strong>.<\/p>\n

Q: What limits?<\/p>\n

A: The limits of natural variation over time.<\/p>\n

Q: What\u00a0does that mean?<\/p>\n

A: Let me show you.<\/p>\n

\"\"<\/a><\/p>\n

Joe Bloggs is disciplined. He measures his blood pressure almost every day and he plots the data on a chart together with some context .\u00a0 The chart shows that his systolic blood pressure is stable. That does not mean that it is\u00a0constant – it does vary from day to day. But over time a pattern emerges\u00a0from which\u00a0Joe Bloggs can see that, based on past behaviour,\u00a0there\u00a0is a range within which future behaviour is predicted to fall.\u00a0 And\u00a0Joe\u00a0Bloggs has drawn these limits on his chart as two red lines and he has called them\u00a0expectation lines<\/em>.\u00a0These are the limits of natural variation over time of his systolic blood pressure.<\/p>\n

If one day he measured his blood pressure and it fell outside that\u00a0expectation range \u00a0then he would say “I didn’t expect that!” and he could investigate further. Perhaps he\u00a0made an error in the measurement? Perhaps something else has changed that could explain the unexpected result. Perhaps it is higher than expected because he is under a lot of emotional stress a work? Perhaps it is lower than expected because he is relaxing on holiday?<\/p>\n

His chart does not tell him the cause – it just flags when to ask more “What might have caused that?”<\/em> questions.<\/p>\n

If you\u00a0arrive at a hospital in an ambulance as an emergency then the first two questions the emergency care team will need to know\u00a0the answer to are “How sick are you?”\u00a0<\/em>and\u00a0“How\u00a0stable are you<\/em>?”. If you are sick and getting sicker then the first task is to stabilise you, and that process is called resuscitation<\/strong>.\u00a0\u00a0There is no time to waste.<\/p>\n

\n

So how is all this relevant to the\u00a0common pattern of symptoms from\u00a0our sick system: disappointingly long waiting times and resources running flat out<\/em>?<\/p>\n

Using\u00a0Rule#1 and Rule#2:\u00a0\u00a0To start to establish\u00a0the diagnosis we need to add the context to the data and then plot our waiting time<\/em>\u00a0information as a time series chart and ask the “Is our system stable?” question.<\/p>\n

\"\"<\/a><\/p>\n

Suppose we do that and this is what we see. The context is that we are measuring the Referral-to-Treatment Time (RTT) for consecutive patients referred to a single service called X. We only know the actual RTT when the treatment happens\u00a0and we want to be able to set the expectation for new patients when they are referred\u00a0 – because we know that if patients know what to expect then they are less likely to be disappointed – so we plot\u00a0our retrospective\u00a0RTT information in the order of referral.\u00a0 With the Mark I Eyeball Test (i.e. look at the chart) we\u00a0form the subjective impression that our system is\u00a0stable. It is delivering a predictable-within-limits RTT with an average of about 15 weeks and an expected<\/strong> range of about\u00a010 to 20 weeks.<\/p>\n

So far so good.<\/p>\n

Unfortunately, the purchaser of our service has set a maximum<\/strong> limit for RTT of 18 weeks – a key performance indicator (KPI)\u00a0target – and they have decided to “motivate” us by withholding payment for every patient that we do not deliver on time.\u00a0We can now see from our chart\u00a0that failures to meet the RTT target are expected, so to avoid the inevitable loss of income we have to come up with an improvement\u00a0plan. Our jobs will depend on it!<\/p>\n

Now we have a problem – because when we look at the resources that are delivering the service they are running flat out – 100% utilisation. They have no spare flow-capacity to do the extra work needed to reduce the waiting list. Efficiency drives and exhortation have got us this far but cannot take us any further. We conclude that our only option is “more capacity”. But we cannot afford it because we are\u00a0operating very close to the edge. We are a not-for-profit organisation. The budgets are tight as a tick. Every penny is being spent. So spending more here will mean spending less somewhere else. And that will cause a big\u00a0argument.<\/p>\n

So\u00a0the only obvious option left to us is to change the system – and the easiest thing to do is to\u00a0monitor the waiting time closely on a patient-by-patient basis and if any patient starts to get close to the RTT Target then we bump them up the list so that they get priority. Obvious!<\/p>\n

WARNING: We are now treating the symptoms before we have diagnosed the underlying disease!<\/strong><\/p>\n

\"\"<\/a>In medicine that is a\u00a0dangerous strategy.\u00a0 Symptoms are often not-specific.\u00a0 Different diseases can cause the same symptoms.\u00a0 An early morning headache can be caused by a hangover after a long night\u00a0on the\u00a0town – it can also (much less commonly) be caused by a brain tumour. The risks are different and the treatment is different. Get that diagnosis wrong and\u00a0disappointment will follow.\u00a0 Do I need a hole in the head or will a paracetamol be enough?<\/p>\n

\n

Back to\u00a0our list of questions.<\/p>\n

What else can cause the same pattern of symptoms of a\u00a0stable\u00a0and disappointingly long waiting time and resources running at 100% utilisation<\/strong>?<\/p>\n

There are several other process diseases that cause this symptom pattern and none<\/strong> of them are caused\u00a0by lack of capacity.<\/p>\n

Which is annoying because it challenges our assumption that this pattern is\u00a0always<\/strong> caused by lack of capacity. Yes – that can sometimes\u00a0be the cause – but not always.<\/p>\n

But before\u00a0we explore what these other\u00a0system diseases\u00a0are we need to understand why our current belief is so entrenched.<\/p>\n

One reason is because we have learned, from experience, that if we throw flow-capacity at the problem then the waiting time will come down.\u00a0When we do “waiting list initiatives” for\u00a0example.\u00a0 So if adding flow-capacity reduces the waiting time then the cause must be lack of capacity? Intuitively obvious.<\/p>\n

Intuitively obvious it may be –\u00a0but incorrect too.\u00a0 We have been tricked again. This is flawed causal logic. It is called the illusion of causality<\/em>.<\/p>\n

To illustrate. If a patient\u00a0complains\u00a0of a headache and\u00a0we give them paracetamol then the headache will usually get better.\u00a0 That does not mean that the cause of headaches is a paracetamol deficiency.\u00a0\u00a0The headache\u00a0could be caused by lots of things and the\u00a0response to treatment does not reliably tell us which possible cause is the actual cause. And by suppressing the symptoms we run the risk\u00a0of missing the\u00a0actual diagnosis while at the same time deluding ourselves that we are doing a good job.<\/p>\n

If a system\u00a0complains of\u00a0 long waiting times and we add flow-capacity then the long waiting time will usually get better. That does not mean that the cause of long waiting time is lack of flow-capacity.\u00a0\u00a0The long waiting time\u00a0could be caused by lots of things. The response to treatment does not reliably tell us which\u00a0possible cause is the actual cause\u00a0– so by suppressing the symptoms we run the risk of missing the diagnosis while at the same time deluding ourselves that we are doing a good job.<\/p>\n

The similarity is not a co-incidence. All systems behave in similar ways.\u00a0Similar counter-intuitive<\/strong> ways.<\/p>\n

\n

So what other\u00a0system diseases can cause a stable and disappointingly long waiting time and high resource utilisation<\/em>?<\/p>\n

\"\"<\/a>The commonest system disease\u00a0that is associated with these symptoms is a time trap<\/strong> – and they have nothing to do with capacity or flow.<\/p>\n

They are part of the operational policy design of the system. And we actually design time traps into our systems deliberately! Oops!<\/p>\n

We create a time trap when we deliberately delay doing something that we could do immediately – perhaps to give the impression that we are very busy or even overworked!\u00a0 We create a time trap whenever we deferring until later something we could do\u00a0today.<\/p>\n

If the task does not seem\u00a0important or urgent for\u00a0us then it is a candidate for delaying with a time trap.<\/p>\n

Unfortunately it may be very important\u00a0and\u00a0urgent\u00a0for\u00a0someone else – and a delay could be\u00a0expensive for them.<\/p>\n

Creating time traps gives us a sense of power – and it is for that reason they are much loved by bureaucrats.<\/p>\n

To illustrate how time traps cause these symptoms consider the following scenario:<\/p>\n

Suppose\u00a0I have just enough resource-capacity to keep up with demand and flow is smooth and fault-free.\u00a0\u00a0My resources\u00a0are 100% utilised;\u00a0\u00a0the flow-in equals the flow-out; and my waiting time is stable.\u00a0 If I then add a time trap to my design then the waiting time will increase but over the long term nothing else will change: the flow-in,\u00a0\u00a0the flow-out,\u00a0\u00a0the resource-capacity, the cost and the utilisation of the resources will all remain stable.\u00a0\u00a0I have increased waiting time without adding or removing capacity. So\u00a0lack of resource-capacity is not always<\/strong> the cause of\u00a0a longer waiting time<\/em>.<\/p>\n

This new insight creates a new problem;\u00a0a BIG problem.<\/p>\n

Suppose\u00a0we are\u00a0measuring flow-in (demand) and flow-out (activity) and\u00a0time from-start-to-finish\u00a0(lead time) and the resource usage (utilisation)\u00a0and\u00a0we are\u00a0obeying Rule#1 and Rule#2 and plotting\u00a0our data with its context as system behaviour charts.\u00a0\u00a0If\u00a0we have a time trap in our\u00a0system then none<\/strong> of these charts will tell\u00a0us that a time-trap is the cause of\u00a0a longer-than-necessary lead time.<\/p>\n

Aw Shucks!<\/p>\n

And that is the primary reason why most systems are\u00a0infested with time traps. The commonly reported performance metrics we use do not tell us that they are there.\u00a0 We cannot improve what we cannot see.<\/p>\n

Well actually the system behaviour charts do hold the\u00a0clues we need\u00a0– but we need to understand how systems work\u00a0in order to know\u00a0how to use the charts to make the time trap\u00a0diagnosis.<\/p>\n

Q: Why bother though?<\/p>\n

A: Simple. It costs nothing to remove a time trap.\u00a0\u00a0We just design it out of the process. Our flow-in will stay the same; our flow-out will stay the same; the capacity we need will stay the same; the cost will stay the same; the revenue will stay the same\u00a0but the\u00a0lead-time will fall.<\/p>\n

Q: So how does that help me\u00a0reduce my costs? That is what I’m being nailed to the floor with as well!<\/p>\n

A:\u00a0If\u00a0a second process\u00a0requires the output of the process\u00a0that has a hidden time trap then the cost of the queue<\/em> in the second process is the indirect cost of the time trap.\u00a0 This is why time traps are such a fertile cause of excess cost – because they are hidden and because\u00a0their impact is felt in a different part of the system –\u00a0and\u00a0usually in a different budget.<\/p>\n

\"\"<\/a>To illustrate. Suppose that 60 patients per day are discharged from\u00a0our hospital and each one requires a prescription of to-take-out (TTO)\u00a0medications to be completed before they can leave.\u00a0 Suppose that there is a time trap in this\u00a0drug dispensing and delivery process. The time trap is a policy\u00a0where a porter is scheduled to collect and distribute all the prescriptions at\u00a05 pm. The porter is busy for the whole day and this policy ensures\u00a0that all the prescriptions for the day are ready before the porter arrives at 5 pm.\u00a0 Suppose we get the event data from our electronic prescribing system (EPS) and we plot it as a system behaviour chart and it shows most of the sixty prescriptions are generated over a\u00a0four hour period between 11 am and\u00a03 pm. These prescriptions are delivered on paper (by our busy porter) and the pharmacy\u00a0guarantees to complete each one within two hours\u00a0of receipt although most take less than 30 minutes to complete. What is the cost of this one-delivery-per-day-porter-policy time trap? Suppose our hospital\u00a0has 500 beds and the total\u00a0annual\u00a0expense is\u00a0\u00a3182 million – that is \u00a30.5 million per day.\u00a0 So\u00a0sixty patients are waiting for between\u00a02 and\u00a05 hours longer than necessary, because of the porter-policy-time-trap, and this adds up to about 5 bed-days per day – that is the cost of 5 beds – 1% of the total cost – about \u00a31.8 million.\u00a0 So the time trap is, indirectly, costing us the equivalent\u00a0of \u00a31.8 million per annum.\u00a0 It\u00a0would be much more cost-effective for the system<\/strong>\u00a0to have a dedicated porter working from 12 am to\u00a05 pm doing nothing else but delivering dispensed TTOs as soon as they are ready!\u00a0 And assuming that there are no other time traps in the decision-to-discharge process;\u00a0\u00a0such as the time trap created by batching all the TTO prescriptions to the end of the morning ward round; and the time trap created by the batch of delivered TTOs waiting for the nurses to distribute them to the queue of waiting patients!<\/em><\/p>\n

\n

Q:\u00a0So how do we\u00a0nail the diagnosis of a time trap and how do we differentiate it from a Batch or a Bottleneck or Carveout?<\/p>\n

A: To learn\u00a0how to do that will require a\u00a0bit more explanation of the physics of processes.<\/p>\n

And anyway if I just told you the answer you\u00a0would know how<\/strong>\u00a0but might not understand\u00a0why<\/strong> it is the answer. Knowledge and understanding are not the same thing. Wise decisions do not follow from just knowledge – they require understanding. Especially when trying to make wise decisions in unfamiliar scenarios.<\/p>\n

It is said that if we are shown we will understand 10%; if we can do we will understand 50%; and if we are able to teach then we will\u00a0understand 90%.<\/p>\n

So instead of showing how instead\u00a0I will\u00a0offer a hint<\/strong>. The\u00a0first step of the path to knowing how and understanding why is in\u00a0the following essay:<\/p>\n

A Study of the Relative Value of Different Time-series Charts for Proactive Process Monitoring. JOIS 2012;3<\/strong>:1-18<\/em><\/p>\n

Click here\u00a0to visit\u00a0JOIS<\/strong><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

There is a common\u00a0system ailment which\u00a0every\u00a0Improvement Scientist needs to know how to manage. In fact, it is probably the commonest. The\u00a0Symptoms: Disappointingly long waiting times and all resources running flat out. The Diagnosis?\u00a0 90%+ of\u00a0managers say “It is obvious – lack of capacity!”. The Treatment? 90%+ of\u00a0managers say “It is obvious – more capacity!!” Intuitively … <\/p>\n

Continue reading “Look Out For The Time Trap!”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,12,15,17,18,20,22,27,30,34,35,42,43,319,45],"tags":[57],"class_list":["post-2208","post","type-post","status-publish","format-standard","hentry","category-business","category-carveout","category-design","category-examples","category-finance","category-flow","category-healthcare","category-jois","category-operations","category-questions","category-reflections","category-how","category-why","category-time-trap","category-what","tag-baseline"],"_links":{"self":[{"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/posts\/2208","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hcse.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2208"}],"version-history":[{"count":1,"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/posts\/2208\/revisions"}],"predecessor-version":[{"id":6285,"href":"https:\/\/hcse.blog\/index.php?rest_route=\/wp\/v2\/posts\/2208\/revisions\/6285"}],"wp:attachment":[{"href":"https:\/\/hcse.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2208"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hcse.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2208"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hcse.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2208"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}