PDSA over PDCA

Karen Martin wrote an excellent post a while back on Mark Graban's Lean Blog, so there's really no need to write this post, but I'm going to do it anyway because it's fun in a really nerdy kind of way.

Study, not Check

Anyway, like Karen and Dr. Deming, I also agree that the third step of the Shewhart Cycle for Learning and Improvement should be 'Study' as opposed to 'Check.'  Let's play word association with these two words:

• When I think of 'Study' I think:  learning, impartial, scientist, curious, absorbing, methodical
• When I think of 'Check' I think:  just verifying, yep I got what I expected, let's move on quickly

Doing a check is better than the approach most people use, which consists of implementing blindly toward an end point that never seems to arrive or which disappoints when it finally does.  But, 'Check' does not encourage a scientific mentality our curious learner attitude the way 'Study' does.  Improvement activities in their finest form are examples of the scientific method being applied to everyday opportunities for improvement, and we so often fail to understand that.  Hence, the quick check on the way to finishing a PDCA cycle and no value given to the learning part of the Shewhart Cycle.

Act, not Adjust (maybe)

Where I might (not definitely but maybe) diverge from Karen's view is with my preference of 'Act' over 'Adjust' as the fourth step of the Shewhart Cycle.  After studying the results of an experiment, there are actions to be performed regardless of whether adjustments are needed or not.  In practice, this is a moot point because adjustments are always needed, but I like to send the message through the use of the word 'Act' that action is required regardless of the outcome we achieved.  Other than adjustment, what actions might be required?  Here's a short list:

• Sharing:  regardless of what we learned or what outcome we achieved, we should share our learning broadly across the organization i.e. yokoten.
• Standardizing:  even if a change is not perfect (and will require adjustment), we might benefit from implementing the change into our work through the use of standard work, job instruction training, etc.

Semantics Matter

Again, I can see why 'Adjust' might be better and I'm not averse to it the way I am with 'Check.'  And yes, in the end it's just semantics, but when we're trying to establish a True North for how we go about learning and improving (which I hope all the lean coaches out there are doing on a daily basis), semantics matter.  A lot!

Experiments as Nemawashi

Lean folks have heard the term nemawashi.  I've heard it described as preparing the roots of a plant for transport.  It's related to consensus-building, and is especially critical when we are proposing big changes to a process.

I started thinking about nemawashi last week when I was in Six Sigma training.  We were learning about Design of Experiments (DOE), which is a methodical and data-driven approach to testing future-state processes, potential countermeasures, etc.  Immediately, I started to compare and contrast the DOE approach to the less scientific Barn-Raising Kaizen and Quick PDCA approaches that have served me well in the past.  I wondered how we were able to achieve what we did without the rigor that DOE provides.  Then it dawned on me that one of the reasons for our success with these less rigorous and more action-biased approaches was that we were performing a type of nemawashi.

We have all probably seen this formula...

R = Q x A 

...which of course stands for...

  Results = Quality of the Countermeasure x Acceptance Level.

Whenever we test a new countermeasure, we are doing more than collecting data to check the quality of the countermeasure.  We are also impacting the acceptance level for change.  If done right, an experiment can help remove the fear of the unknown, send a message that change is coming, and bring out ideas that don't arise until we see a new process live in action.  These are all symptoms of nemawashi being performed.

Small-Batch PDCA

I'm a fan of small batches.  Partially, this is explained by my appreciation of the many fine single-barrel and small-batch bourbons produced in good ol' Kentucky.  But principally, my bias towards small batches is due to the positive impact that batch-size reduction has on process flow, quality, etc.

Normally, we associate batch-size reduction with process improvement.  But if we take a step back and look at our process for conducting process improvement, batch-size reduction is equally as applicable.  Specifically, the way we go about testing countermeasures via PDCA can be enhanced by batch-size reduction.  I call this principle Small-Batch PDCA.

What is Small Batch PDCA?

When we're in the planning phase of of PDCA, we have to decide how many countermeasures we want to test during the current PDCA cycle.  There's a trade-off between the number of countermeasures we test and the amount of time, effort, and resources that will be required to conduct the test.  More countermeasures equals more testing complexity.  In order to properly execute a complex test, we might feel the need to utilize a complex tool such as Design of Experiments (DOE).  My bias is to avoid this testing complexity by testing in smaller batches when possible.

By reducing the complexity involved with carrying out a test, Small-Batch PDCA allows us to compress the lead time from idea generation to idea testing.  This gives us the chance to perform more iterations of PDCA, which in turn gives us a chance to adjust our model more frequently.

Is there a downside to Small-Batch PDCA?

One of the drawbacks of Small-Batch PDCA is that we don't get to test the future-state in a holistic manner, at least not during the first few rounds of testing.  This means that any data we collect early on might not show the dramatic improvement we want, and in fact, it may be impossible to detect any statistically significant changes in performance.  This is a valid concern, but this drawback is partially mitigated by the fact that if we are willing to go to the gemba and observe the test with our own eyes, we don't have to rely on data as much.

Plus, there are some important things that just can't be measured, so we usually need to go to the gemba regardless.  In other words, data isn't everything.  Subjective feedback from those involved with the process can be extremely valuable.  Insights gained from direct observation can also be extremely valuable.  Small-Batch PDCA provides us with most of the feedback we need to effectively carry out process improvements, even if the data is not as perfect as we would like.

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.

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.