Shock Absorbers in an ER

In an Emergency Room, it's pretty hard to control the volume and acuity of patients coming in the door.  Variation is inevitable.  It's like riding down an old dirt road--you have some smooth spots and some bumpy spots.  That's why our cars come with shock absorbers.

What is our shock absorber in an ER?

How do we mitigate the effect of variation in patient volume and acuity?  Sometimes, we take the wasteful but safe approach of over-staffing.  Or, we might look at the measures of central tendency and variability in our patient volumes and acuity, and come up with a staffing model that is both statistically reliable and much less wasteful than blunt force over-staffing.

Being able to absorb the shock of uncontrollable patient volumes and acuities is especially critical if an ER is attempting to go to a cellular flow model.  In this model, you might try to even out the variation by distributing patients to the multiple cells evenly.  This works well as long as the cells are equipped for all patient types.

If, however, a certain type of patient can only be seen in a certain cell, and a bunch of those patients come in at the same time, then we have a big problem.  In this circumstance, we need a different kind of shock absorber, perhaps flex resources (doctors, nurses, etc.) that are not assigned to a single cell, but that can flow to where they're needed.  Of course, in the long-term, we should try to even out the capabilities of the cells so that this whole issue is moot.

Whether it's through blunt force over-staffing, statistically sound staffing, level loading to cells, flowing flex resources to unleveled cells, or evening out of cell capabilities, we absolutely must have a way to ride over the bumpy spots in the road.  We have to have a shock absorber.

3 Lean Coaching Tactics for Project Managers

I'm fortunate to be a project manager who works almost exclusively on lean/six sigma projects.  I say fortunate, because it gives me the chance to be a lean coach, as well as a project manager.  Of course, it's challenging to try to mix in lean coaching within a traditional project management setting.

Anybody who has sat for the PMP Exam or perused the PMBOK knows that traditional project management as a field of study is very, very light on lean/agile concepts.  So, as a project manager who loves lean coaching, I get to find creative ways to sprinkle in some lean learning throughout my projects.  Here are three tactics I utilize:

1. Genchi Genbutsu...In traditional project management, we might be tempted to accept whatever project assumptions are indicated on the project charter.  But as a lean coach, we should encourage our project team to go to the gemba and see for ourselves.  We don't rely on data either; we prefer facts, observed with our own eyes when possible.
2. Small-Batch PDCA...In traditional project management utilizing the 'waterfall' approach, we might be tempted to get a big batch of project planning done, then move into the project execution phase and execute a big batch of deliverables.  But as a lean coach, we should encourage our project team to instead perform many turns of the PDCA wheel, constantly testing, constantly iterating, in small batches of planning and execution.  This has all sorts of benefits, one of the biggest being we get a chance to uncover flaws in our plan much quicker than with 'waterfall.'
3. Visual Collaboration...In traditional project management, we might be tempted to conduct meetings the old-fashioned way, relying mostly on verbal discussion and taking notes down on paper.  But as a lean coach, we should encourage our project team to utilize visual collaboration techniques.  Use whiteboards, sticky notes, flip charts, etc. to visualize topics of discussion.  Once we visualize the discussion, we can structure it into affinity diagrams, fishbone diagrams, or whatever structure makes sense.  You can't do that if the discussion vanishes into thin air or is only captured on our individual note pads.

Utilizing these tactics and several others, we are able to sprinkle in a little lean into all of our projects.  This will not only help us project managers on our projects, but it will also help our project team members in their day-to-day.

When the Gemba is an ER

As any student of Toyota knows, going to the gemba is step one when investigating a problem.  This principle is often referred to as genchi genbutsu, and lean thinkers know why it's such a powerful and almost mandatory concept.

But what about when the gemba is an Emergency Room?

My first thought is that all workplaces are different, but what we're looking for pretty much stays the same.  In other words, a gemba is a gemba.  But, having spent enough time in ER's recently, I think there are a few differentiators that we can take into account:

1. The doctors are the touch labor.  Whereas in manufacturing, we sometimes see the problem of the touch labor employees not being respected and their voices not being heard, we sometimes have the opposite problem in healthcare.  Doctors are so well-respected, and sometimes so feared, that they can have an almost unwieldy amount of influence.
2. Everybody is at a computer.  No, they're not playing solitaire or checking Facebook.  They're working extremely hard to enter their patient encounter information into the system.  In modern healthcare, it feels like everything is dependent upon electronic information management.
3. Flow is hard to see.  Many ER's were not designed with one-piece flow in mind.  Or cellular flow.  Or pull systems.  Or level loading.  Or visual management.  Or any of the other concepts that help improve flow and make flow visible.  The structural design of many ER's can make it almost impossible to see the flow of patients through the system.

If you're a lean thinker looking to make the move to healthcare, these are just a couple of thoughts to keep in mind.  But, if you're a lean thinker, you've probably been to many gembas and you probably know that each one has their own set of differentiators.  An ER is still a gemba, just one that maybe requires a little extra patience and finesse.

3 Thoughts on Doctor/Nurse Teamwork

Photo courtesy of iStockphoto

Just three random thoughts on doctor/nurse teamwork:

1. If the doctor and nurse sit near each other, in the same area where the patients are roomed, communication is infinitely better.  We so often rely on technology to communicate with each other, when quick, natural face-to-face discussions are more effective.
2. If the doctor and nurse see the patient together, there is more opportunity for shared understanding, and potentially, even collaborative diagnosis and plan-of-care development...that is, if the culture in your hospital allows for that sort of thing.
3. If the doctor and nurse work side-by-side in similar attire, there is increased potential for confusion from patients on who is the doctor and who is the nurse.  Somewhat silly, but not a trivial point.

Your thoughts?

10 Complexities in Hospitals

Having worked in a hospital as a Lean Coach for about a year now, I've grown accustomed to dealing with a wide range of complexity related to healthcare, and hospitals in particular.  Here's a list of some of the types of complexity I've seen in the hospital (it's not an exhaustive list by any means, and is in no particular order)...

1. We often have no ability to control/level the volume going into the system, especially in an ER setting
2. We have seasonal, weekly, and daily volume fluctuations
3. We often have a wide range of acuity levels, which are high-mix, low-volume in nature
4. Clinical workflows are often controlled by complex computer systems, which makes some processes more inflexible that we'd prefer
5. The most highly-trained and often most powerful people in a hospital are the physicians, who are also the "touch labor" for our front-line processes
6. We have 24/7/365 business hours, making cross-shift collaboration a challenge sometimes
7. In pediatric hospitals, we have to design processes that accommodate the needs of both the patient and their family
8. In academic hospitals, we often have to design processes with educational needs in mind
9. The customer and the payer (insurance companies, Medicare, etc.) are often not the same entity
10. In places like Texas, we have huge language barriers that our processes have to accomodate

Every industry has its own sources of complexity.  Healthcare, and hospitals in particular, bring special types of complexity that are pretty challenging.  I personally love the challenge, but I also realize that I have a long way to go if I want to be a Lean Coach who is capable of overcoming the complexity found in hospital systems.

DMAIC, the Power Drill

In previous posts, I wrote about the virtues of "Quick PDCA" and "Barn-Raising Kaizen."  It's obvious I favor approaches that have a bias for action.  But does that mean I'm averse to more methodical approaches such as the DMAIC approach as practiced by Six Sigma Black Belts?  Absolutely not.

As I mentioned in the "Barn-Raising Kaizen" article:

"Some repairs call for a hammer, and others call for a power drill.  It depends on the problem we're trying to solve, the information that is available, the stakeholders involved, and a whole lot more.  My suggestion is that we should not lock ourselves into any one way of bringing about improvement.  Use what works for whatever situation is presented."

 I think DMAIC is an awesome approach in certain types of situations:

• Some problems are better analyzed through data analysis and statistics, something which is at the heart of DMAIC
• Some organizations require that any and all projects show a measurable and verifiable ROI...something which is embedded in the DMAIC approach
• Some managers want projects in their departments to have a formal structure and mandatory gate reviews...which also is embedded in the DMAIC approach

There are many situations that call for the power drill that is DMAIC instead of the hammer that is Quick PDCA/Barn-Raising Kaizen.  Of course, many situations can be handled just as well by either approach.  I just think we have to pick the tool that makes the most sense for the situation.

Stay open-minded.  Be flexible.  See the scientific method in both the hammer and the power drill.

Barn-Raising Kaizen

A good friend of mine has an approach to process improvement that he calls "Barn-Raising Kaizen."    If you don't know what barn-raising is, here's a quick excerpt from Wikipedia:

"A barn raising is an event during which a community comes together to assemble a barn for one or more of its households, particularly in 18th- and 19th-century rural North America."

It's all about community, teamwork, and just getting it done.  I love it.

My friend uses the barn-raising concept when facilitating improvements out on the shopfloor.  He'll gather the folks together, get some ideas flowing, and then implement changes right there on the spot.  Then they'll monitor the changes, check results, and make adjustments...again, right there on the spot.  It all happens in this informal, team-oriented atmosphere that resembles the barn-raising events of yesteryear.  No prolonged data collection, no measurement system analysis, no project charter, no gate reviews...just kaizen.

So, is "barn-raising" kaizen effective?

You certainly won't get your Six Sigma Black Belt using the barn-raising kaizen approach, but it can be incredibly effective.  Because the changes are made so quickly, we get more chances to iterate...more turns of the PDCA wheel.  With each iteration, we get a chance to learn what works and what doesn't.  We're not at our computer using Mini-Tab to produce a control chart; we're out at the gemba looking at the gembutsu.

Also, every time we do barn-raising kaizen, we get another chance to practice problem-solving and build our kaizen muscles.  Have you read Toyota Kata yet?

But, how do you know if you've improved?

The fear is that without having a data collection plan, measurement system analysis, etc., we'll be in the dark when it comes to proving whether the changes worked or not.  This probably has more to do with trying to show a good ROI than it does with actually understanding how a change impacted a process.  If we're out at the gemba, we can usually see the impact with our own eyes.  We don't always need data, except to show ROI on paper.

Are you saying a more thorough approach, like DMAIC, is a waste of time?

Not at all.  Some repairs call for a hammer, and others call for a power drill.  It depends on the problem we're trying to solve, the information that is available, the stakeholders involved, and a whole lot more.  My suggestion is that we should not lock ourselves into any one way of bringing about improvement.  Use what works for whatever situation is presented.

On a somewhat related topic, Pete Abilla at the Shmula blog compared the PDCA and DMAIC approaches (link).

Quick PDCA

Do you ever get impatient when process improvements take too long? I know I do, as do several of the stakeholders that I work with in healthcare. Why does improvement sometimes take so long? One theory is that we wait too long to initiate PDCA cycles.

The Normal, Slow Approach

On a big Black Belt-led improvement project utilizing the DMAIC approach, we don't get to testing countermeasures using PDCA until the Improve phase. On some projects, it can take quite a while to get to that point. Sometimes, it's because data is not readily available during the Measure phase. Other times, it might be that the project team is having difficulty coming to a consensus during the Analyze phase on which countermeasures to implement. Whatever the reason, there almost always comes a point when we need to display a bias for action.

The Quick PDCA Approach

In other words, sometimes we need to stop relying on data and brainstorming, and just go do an experiment. PDCA is our approach for doing these experiments. Plan the test, perform the test, check and study the results, and adjust based on what you learn. It's rigorous, scientific, and time-tested. But we can't enjoy the benefits of PDCA unless we use it. So, have a bias for action. If data is hard to come by, go to the Gemba, do a quick PDCA, and see with your own eyes what works and what doesn't. If the team can't come to a consensus on what the countermeasure should be, stop deliberating and go do a quick PDCA.

Bias for action. Experimentation. Iteration. Learning opportunities. Quick PDCA.