Scatter - Our Nemesis

By Pascal Dennis (bio)

Big Company Disease has many causes.

One of the most subtle is our inability to ‘wrap our arms around’ the PDCA cycle.

Myriad improvement cycles begin – but they become fragmented:

• Group A develops the Plan,
• Group B deploys,
• Group C checks the Plan, and
• Group D adjusts it.

I call this Scatter, with a deep bow to the late, great Al Ward – friend, colleague & profound Lean thinker.

Al described this syndrome to me over lunch a decade ago, and then again in his splendid book Lean Product & Process Design.

Improvement, whether a Kaizen Workshop, Problem Solving cycle or Strategy A3, requires complete PDCA cycles

One person (or team) needs to wrap her arms around the cycle, and thereby develop the profound, sympathetic knowledge central to breakthrough.

Thereby, our entire brains start firing – Left, Right, prefrontal cortex etc.

The countermeasures we select are usually simple and clear.

There’s usually a sense of release. “Of course! Why didn’t we see it before!”

As opposed to the ponderous, countermeasure-by-committee stuff that blights so many report outs.

So how to reduce Scatter?

Lean fundamentals like visual management and Leader standard work are a good start.

Veteran Lean companies like Toyota have developed the Chief Engineer role in Design, and Key Thinker (aka Deployment Leader or Pacemaker) role in Strategy Deployment.

Their job is to oversee & manage broad PDCA cycles – and to record & share the learning.

There are all a good place to start in your never-ending battle with Scatter.

Best regards,

Pascal



In case you missed our last few blogs... please feel free to have another look…

The Biggest Weakness is Contemporary Business Culture?
What Makes a Great Sensei?
Beware Prizes, Belts & Self-appointed Experts
Aikido & Lean – It’s All the Same

On Big Data

By Pascal Dennis (bio)

Big data is all the rage these days. Big consulting houses and IT touts assure us that the next big breakthrough is just around the corner.

And all we need is self-appointed experts and super computers that crunch through all our ‘data’ and make sense of everything for us.

Don’t’ want to be misunderstood. There is a place for experts and for super computers, and the wise are always open to new thinking.

But do we really believe that Big Data is going to solve our problems?

Do we even understand our ‘small data’? In other words, do we understand our current condition? Stuff like:

• Purpose
• Core metrics
• Targets versus Actual
• Trends & patterns

• Top 3 acute problems
• Top 3 chronic problems
• Degree of engagement of our teams
• Problem solving capability of our teams
• Overall capability of our team members
• Capability of our machines & equipment
• Capability of our processes

And these questions, of course, apply at each level of our management system from Level 1 – front line on up.

Comparatively few organizations can answer these questions in the affirmative.

Truth be told, many (most?) organizations flounder about in the fog of Big Company Disease [The Remedy], no?

It’s not incompetence or ill will. It is the nature of large organizations, organisms that are still comparative newcomers to the human scene.

It takes great skill and tenacity to disperse the fog, and keep it from seeping back in. Companies that thereby understand their ‘small data’ are akin to the one-eyed man in the kingdom of the blind.

So before we grasp at the straws of Big Data, let’s build our management systems so we can understand our ‘small data’ – like the world’s best organizations do.

Regards,

Pascal



In case you missed our last few blogs... please feel free to have another look…

Why Lean Outside the Factory?
Too Often, Power Means the Power to Do Stupid Things
When You’re Convinced You’re Right, You’ve Lost Your Ability to Learn
On Labels – ‘Expert, Master, Sensei’ and the like

Problem Solving and the Worlds of Reflection & Experience

By Pascal Dennis (bio)

Good problem solving entails moving fluidly between the worlds of Reflection & Experience.

Go See (genchi genbutsu) is central to the latter. Analytical tools like the famous Q7 Quality Tools are abstractions that exist in the world of Reflection.

Problem solving begins in the world of Experience.

What is actually happening right now? Go See the defect the moment you hear about it.

Or stand in a circle, as Taiichi Ohno suggested, until you see it in real time.

We then move to the world of Reflection to define What Is Actually Happening & What Should Be Happening.

Problem solving, of course, concludes in the world of Experience - otherwise it's just 'academic'.

This pattern -- experience - reflection - experience is central to practical problem solving and to Lean as a whole.

Lean thinkers are comfortable in both worlds.

My mental image: a person with one hand deeply embedded in the ground, and the other reaching for the sky.

Reflect, then get your butt to the gemba.

Reflection without action is lifeless. Action without reflection is aimless.

Best,

Pascal




In case you missed our last few blogs... please feel free to have another look…

Learning How to Manage
Bozos and HR
Strategy and the Worlds of Thought & Experience
PDCA in the Trades

Practical Problem Solving – Proving Cause & Effect

By Pascal Dennis (bio)

"Improvement is endless and eternal" – Taiichi Ohno

At Toyota I learned the following problem solving drill:

1. Do I have a problem?
2. Do I know the cause?
3. Have I proven cause & effect?
4. Have I confirmed the countermeasure?

Question 3 is a common failure point. Humans are wired to jump to countermeasures. Testing cause and effect, by contrast, takes time. You have to develop a hypothesis, then run experiments to prove, or disprove it.

Recently, our family had the interesting opportunity to apply the drill.

1. Do we have a Problem?

Yes - an annoying rattle coming from the dashboard of our RX 350 Lexus truck. (Very surprising for a vehicle built by the splendid Toyota team in Cambridge Ontario.)


2. Do we know the cause?

After looking under the hood, driving at different speeds, on different kinds of ground, we were unable to locate the source.

Lexus technicians also checked, but detected no evidence of a rattle in the cabin. But soon after, there it was again!

My wife, always alert, then made an interesting observation. “Hmmm, the truck never rattles when you’re wearing your sun glasses.”

And sure enough, when the truck was with Lexus maintenance, I’d taken my sun glasses with me.

You can imagine our next steps. We ran a number of variations on the following experiments:

• Sun glasses in storage position
• Sun glasses on Pascal’s head

The result?

• Sun glasses in storage position – rattle
• Sun glasses on Pascal’s head – no rattle

Thereby, we were able to turn the problem on and off, the ultimate test of cause and effect.

Countermeasures, for our family at least, are clear. But what’s the countermeasure for Lexus, whose marketing extols the world’s ‘quietest cabin’?

An unanticipated failure mode! So it goes. That’s why we say, improvement is endless and eternal!

I have great faith in Lexus. Vibration absorption in the sun glasses storage area comes to mind.

(As for a rattling head, no comment.)

Best,

Pascal




In case you missed our last few blogs... please feel free to have another look…

Lean Means Don’t Be a Dumb-Ass
Lean – So ‘Easy’, It’s Hard
“Failing to Plan is Planning to Fail”
Building Quality into the Process

Why Do We Learn More from What Did Not Work?

By Pascal Dennis (bio)

Building on Al's recent blog, why do we learn from more failure than success?

Seems to me, it's because failure illuminates more of the design space than success.

Supposing we're testing the structural integrity of say, a hard hat, by dropping a heavy weight on it.

If we test to the standard, (say 20 kg) and the hard hat remains intact, you've learned something about what sort of blow it can sustain.

But suppose we keep dropping heavier & heavier weights, and vary the angle of the blows - until the hard hat shatters.

Our analysis of the fragments, breakage pattern, of the slow motion video and so on, will teach us far more about the nature of hard hats.

That's why experienced labs & design teams test to failure.

A caveat, as Al suggests, is that we fail quick & fail often, (to minimize hassle & transaction cost.)

A second caveat: our failures are controlled & buffered so nobody gets hurt!

These same principles apply in strategy, product & process design and problem solving.

That's why we say 'problems are gold'.

We have to be comfortable, of course, with experimentation & ambiguity.

In my experience, the best leaders create a sense of free-wheeling energy & opportunity.

"Let's try some stuff -- and see what happens!"

"Holy cow, who would have thought...!?"

Best,

Pascal


In case you missed our last few blogs... please feel free to have another look…

Failure is a Requirement for Innovation
KAIZEN – Small Changes vs. Monster Projects
Is Inventory a waste or a cover-up of deeper waste?
7 Basic Quality Tools – Are they underrated?

How Do Adults Learn?

By Al Norval (bio)

Adults learn very differently from children.

Children are sponges. Every day is a new adventure in which new things are learned. Somewhere along the way this all changes and we mature and become adults.

Adults on the other hand, only learn what they feel they need to learn. Adult learning is very practical. If I can’t see how this will help me now, then the true understanding and retention rate of the learning will be very low. I’m sure we can all remember the blah, blah, blah of college professors droning on about some mundane topic that was soon forgotten after the final exam was written.

So, what does this mean?

Adult learning focuses on solving problems. More concretely, realistic problems that people have right now.

When teams have problems, leaders have an opportunity to teach and use the problem to raise the capability of their Team Members. This is the power and magic behind kaizen.

We solve problems and learn in the very process of doing so. This is also the basis of Mental model #1 – Leader as a Teacher. Not to teach like a college professor but to teach Socratically by asking question to build the teams capability and guide the Team through the problem solving process.

Cheers

Al

In case you missed our last few blogs... please feel free to have another look…

Back to Basics – Visual Management
Back to Basics – Visual Order
Back to Basics – Employee Engagement
Back to Basics – Customer Value

Scatter - Our Nemesis

By Pascal Dennis (bio)

Big Company Disease has many causes.

One of the most subtle is our inability to ‘wrap our arms around’ the PDCA cycle.

Myriad improvement cycles begin – but they become fragmented:

• Group A develops the Plan,
• Group B deploys,
• Group C checks the Plan, and
• Group D adjusts it.

I call this Scatter, with a deep bow to the late, great Al Ward – friend, colleague & profound Lean thinker.

Al described this syndrome to me over lunch a decade ago, and then again in his splendid book Lean Product & Process Design.

Improvement, whether a Kaizen Workshop, Problem Solving cycle or Strategy A3, requires complete PDCA cycles

One person (or team) needs to wrap her arms around the cycle, and thereby develop the profound, sympathetic knowledge central to breakthrough.

Thereby, our entire brains start firing – Left, Right, prefrontal cortex etc.

The countermeasures we select are usually simple and clear.

There’s usually a sense of release. “Of course! Why didn’t we see it before!”

As opposed to the ponderous, countermeasure-by-committee stuff that blights so many report outs.

So how to reduce Scatter?

Lean fundamentals like visual management and Leader standard work are a good start.

Veteran Lean companies like Toyota have developed the Chief Engineer role in Design, and Key Thinker (aka Deployment Leader or Pacemaker) role in Strategy Deployment.

Their job is to oversee & manage broad PDCA cycles – and to record & share the learning.

There are all a good place to start in your never-ending battle with Scatter.

Best regards,

Pascal

Is Five Why Analysis Too Simplistic for Complex Problems?

By Pascal Dennis (bio)

A common question, especially in industries that are just now learning the Lean Business System.

Problem solving is a kata - a set of core forms that we practice over & over, hopefully under the guidance of a capable sensei.

When practicing the problem solving kata, we pull in the tools we need including, Five Why, Ishikawa, Process Flow Diagrams, SIPOC etc.

It's a mistake to structure any problem solving discussion in either/or terms.

It's not Five Why OR Ishikawa OR Process Flow Diagram OR FMEA.

To paraphrase Hemingway, "it's all true." We pull in what we need.

Another common mistake is underestimating Five Why.

"Five Why is too simple for me. I want a more complex tool, because this is a complex problem. (And I am a very complex guy!)"

In consulting practice we've used Five Why to get to the root cause of complex design, supply chain and organizational problems.

Five Why is especially helpful when we've clearly defined a Direct Cause.

Often there are multiple causes, and we need to apply Five Why sequentially to get to the root cause of each.

A common failure mode is not understanding the three types of Root Causes - Inadequate Standard, Inadequate Adherence to Standard, Inadequate System.

These are derived from the splendid NASA and Loss Control literature & are invaluable because they point to actionable root causes.

In summary, problem solving is a kata and not unlike trying to hit a curve ball, shoot hoops, or hit a golf ball.

(All of which baffle me...)

You practice, practice, practice the core skills & movements.

Then, if you're very lucky, the day comes you can do it unconsciously.

Best regards,

Pascal

On Big Data

By Pascal Dennis (bio)

Big data is all the rage these days. Big consulting houses and IT touts assure us that the next big breakthrough is just around the corner.

And all we need is self-appointed experts and super computers that crunch through all our ‘data’ and make sense of everything for us.

Don’t’ want to be misunderstood. There is a place for experts and for super computers, and the wise are always open to new thinking.

But do we really believe that Big Data is going to solve our problems?

Do we even understand our ‘small data’? In other words, do we understand our current condition? Stuff like:

• Purpose
• Core metrics
• Targets versus Actual
• Trends & patterns

• Top 3 acute problems
• Top 3 chronic problems
• Degree of engagement of our teams
• Problem solving capability of our teams
• Overall capability of our team members
• Capability of our machines & equipment
• Capability of our processes

And these questions, of course, apply at each level of our management system from Level 1 – front line on up.

Comparatively few organizations can answer these questions in the affirmative.

Truth be told, many (most?) organizations flounder about in the fog of Big Company Disease [The Remedy], no?

It’s not incompetence or ill will. It is the nature of large organizations, organisms that are still comparative newcomers to the human scene.

It takes great skill and tenacity to disperse the fog, and keep it from seeping back in. Companies that thereby understand their ‘small data’ are akin to the one-eyed man in the kingdom of the blind.

So before we grasp at the straws of Big Data, let’s build our management systems so we can understand our ‘small data’ – like the world’s best organizations do.

Regards,

Pascal

Problem Solving and the Worlds of Reflection & Experience

By Pascal Dennis

Good problem solving entails moving fluidly between the worlds of Reflection & Experience.

Go See (genchi genbutsu) is central to the latter. Analytical tools like the famous Q7 Quality Tools are abstractions that exist in the world of Reflection.

Problem solving begins in the world of Experience.

What is actually happening right now? Go See the defect the moment you hear about it.

Or stand in a circle, as Taiichi Ohno suggested, until you see it in real time.

We then move to the world of Reflection to define What Is Actually Happening & What Should Be Happening.

Problem solving, of course, concludes in the world of Experience - otherwise it's just 'academic'.

This pattern -- experience - reflection - experience is central to practical problem solving and to Lean as a whole.

Lean thinkers are comfortable in both worlds.

My mental image: a person with one hand deeply embedded in the ground, and the other reaching for the sky.

Reflect, then get your butt to the gemba.

Reflection without action is lifeless. Action without reflection is aimless.

Best,

Pascal

Pascal Dennis Bio

Quality in the Hospital Laboratory Process?

By Pascal Dennis

“We’re sorry…” CEO Toronto Hospital for Sick Children

Terrible story, folks, out of the Hospital for Sick Children. Sick Kids apologizes for drug-test failings.

Flaws in the Motherisk laboratory’s hair-strand drug and alcohol testing process might have caused some parents to lose custody of their children. Other parents might face unjust criminal convictions.

Children’s Aid Societies use the results of such tests to make decisions on custody and so on. After months of denial and deflection, the hospital has finally accepted responsibility and apologized.

Cold comfort to the victims, though. How many lives have been damaged?

As always, there are learning points. What are possible causes of this laboratory disasters?

Layout?

• Poor overall layouts result in chaotic work pathways, which increase contamination risk
• Work Area Layout – are all the items technicians needs to do their work within easy reach, or do they have hunt and peck?

5S & Visual Management

• Are reagents, equipment, slides and the rest easy to find? Is it easy to tell, ‘what is it?’, ‘where is it?’ and ‘how many?’

All of these increase contamination risk.

Standardized Work?

• Are there simple, visual standards for the lab’s core ‘recipes’?
• Are standards checked and updated regularly, and ‘owned’ by team members?

Team Member Training Process?

• Are lab team members trained in core standards using robust methods (e.g. TWI)?
• Are team members cross-trained to build capability and ensure requisite skills are in abundance

Daily Accountability?

• Does the hospital’s management system include daily stand up meetings in front of team boards wherein team members are encouraged to make problems visible?

Team Member Involvement and Problem Solving?

• Are team members trained in fundamentals like standardized work, visual management, and problem solving?
• Do leaders at all levels actively support total involvement and daily problem solving?
• Does the Human Resources system support and promote such leaders?

Hard questions, all.

My heart goes out to the victims.

Best regards,

Pascal

Pascal Dennis Bio

Practical Problem Solving – Proving Cause & Effect

By Pascal Dennis

"Improvement is endless and eternal" – Taiichi Ohno

At Toyota I learned the following problem solving drill:

1. Do I have a problem?
2. Do I know the cause?
3. Have I proven cause & effect?
4. Have I confirmed the countermeasure?

Question 3 is a common failure point. Humans are wired to jump to countermeasures. Testing cause and effect, by contrast, takes time. You have to develop a hypothesis, then run experiments to prove, or disprove it.

Recently, our family had the interesting opportunity to apply the drill.

1. Do we have a Problem?

Yes - an annoying rattle coming from the dashboard of our RX 350 Lexus truck. (Very surprising for a vehicle built by the splendid Toyota team in Cambridge Ontario.)


2. Do we know the cause?

After looking under the hood, driving at different speeds, on different kinds of ground, we were unable to locate the source.

(My teenage daughter Katie drolly suggested the rattling was coming from my head, but let’s put that aside.)

Lexus technicians also checked, but detected no evidence of a rattle in the cabin. But soon after, there it was again!

My wife, always alert, then made an interesting observation. “Hmmm, the truck never rattles when you’re wearing your sun glasses.”

And sure enough, when the truck was with Lexus maintenance, I’d taken my sun glasses with me.

You can imagine our next steps. We ran a number of variations on the following experiments:

• Sun glasses in storage position
• Sun glasses on Pascal’s head

The result?

• Sun glasses in storage position – rattle
• Sun glasses on Pascal’s head – no rattle

Thereby, we were able to turn the problem on and off, the ultimate test of cause and effect.

Countermeasures, for our family at least, are clear. But what’s the countermeasure for Lexus, whose marketing extols the world’s ‘quietest cabin’?

An unanticipated failure mode! So it goes. That’s why we say, improvement is endless and eternal!

I have great faith in Lexus. Vibration absorption in the sun glasses storage area comes to mind.

(As for a rattling head, no comment.)

Best,

Pascal

Pascal Dennis Bio

Scatter - Our Nemesis

LPI Back to Basics Series

By Pascal Dennis

Big Company Disease has many causes.

One of the most subtle is our inability to ‘wrap our arms around’ the PDCA cycle.

Myriad improvement cycles begin – but they become fragmented:

• Group A develops the Plan,
• Group B deploys,
• Group C checks the Plan, and
• Group D adjusts it.

I call this Scatter, with a deep bow to the late, great Al Ward – friend, colleague & profound Lean thinker.

Al described this syndrome to me over lunch a decade ago, and then again in his splendid book Lean Product & Process Design.

Improvement, whether a Kaizen Workshop, Problem Solving cycle or Strategy A3, requires complete PDCA cycles

One person (or team) needs to wrap her arms around the cycle, and thereby develop the profound, sympathetic knowledge central to breakthrough.

Thereby, our entire brains start firing – Left, Right, prefrontal cortex etc.

The countermeasures we select are usually simple and clear.

There’s usually a sense of release. “Of course! Why didn’t we see it before!”

As opposed to the ponderous, countermeasure-by-committee stuff that blights so many report outs.

So how to reduce Scatter?

Lean fundamentals like visual management and Leader standard work are a good start.

Veteran Lean companies like Toyota have developed the Chief Engineer role in Design, and Key Thinker (aka Deployment Leader or Pacemaker) role in Strategy Deployment.

Their job is to oversee & manage broad PDCA cycles – and to record & share the learning.

There are all a good place to start in your never-ending battle with Scatter.

Best regards,

Pascal

Pascal Dennis Bio

Training is for Cats & Dogs; People Learn

By Al Norval

This is a great saying that I heard the other day. I wish I knew who said it first as I would give them credit for it. It struck a chord in me since I've been at a couple of problem solving sessions lately where the countermeasure to the problem is “More Training” or “Re-train the people”.

I’ve come to realize that training never addresses the root cause of the problem.

If the original training people received didn’t have them operating in a standard way, why would training them over again give any different results and solve the problem? Now if we changed the training process, then yes, we would expect different results and could run the new training process as an experiment to see if it did produce different results.

Why then do people keep coming to training as a countermeasure to the root cause of problems?

I believe it’s because they aren't at root cause and it’s a popular countermeasure that gives the illusion that we’re actually doing something. Never mind that what we’re doing won’t solve the problem.

When we train dogs and cats – we teach them what to do; tricks like – roll-over, put their paw up, fetch a ball and bark on command. When they do these well, our pets get rewarded with a biscuit and the behavior gets reinforced.

People on the other hand, have a basic need to learn and to understand the “why” behind the “what” to do. By learning why things must be done in a certain way, people increase their basic capability and understanding resulting in a much higher likelihood that the standard will be followed.

What’s the best way for people to learn the why? – it’s through being engaged in problem solving. Simple problem solving engages people in such a way that they learn.

The result is people who are performing tasks not by rote waiting for their behavior to be reinforced but because they have a deep understanding of the situation and why things must be done this way. People who then can use this deep understanding to drive faster improvements within an organization.

Training or learning - which organization would you prefer to be part of?

Cheers

Easy on the people, hard on the process

By Al Norval

One of the basic tenants of Lean is “Respect for People”. There is much history behind it which I won’t go into in this blog; I’ll save that for another day.

Another basic foundation of Lean is that we “Solve problems according to the scientific method”. That is, we take problems to root cause and put in countermeasures against those root causes. The countermeasures form a hypothesis that says - if we do these things then the root cause will be eliminated and the problem will not re-appear. Then we run experiments and test the hypothesis and learn from the results.

Putting these two ideas together we see that in problem solving, we need to look at the processes in which people do their work. We believe that people are basically good; it’s the processes they use that are causing the problems. The people are merely executing the broken processes.

In problem solving we keep asking “why” to get to the root cause of a problem, and many times we see the root cause is actually a process problem. We need to be hard on the process to understand what is it about the process that is broken and is allowing these problems to appear. We also need to be hard on the process in designing countermeasures so we build robust processes where it’s easy for people to execute them.

Contrast the “5 why” process of getting to root cause with one that asks the “5 who’s” in trying to get to root cause. That type of questioning is hard on the people and doesn’t get to a true root cause. What it does do is violate the lean pillar of “Respect for People” and so does a great job of turning people off and undermining any engagement of people in improvement work.

To engage people in improvement work, we need to create an environment that is conducive to problem solving, one where we engage both the hearts and mind of people, one where the problem solving is “Easy on the people and hard on the process”.

Cheers

You Respect Us

By Pascal Dennis

Egypt, a few years ago, working with a major client.

Just before the demonstrations in Tahrir Square that led to the Egyptian Spring.

My Egyptian colleagues were gracious, hospitable and hungry to learn.

Dozens of questions on standardized work, visual management, problem solving, strategy deployment.

I answered as best I could, pleased to have such eager students.

After each session, team members came up to shake my hand.

"We are so happy," a young fellow told me," to meet somebody like you."

"What do you mean - someone like me?" I asked.

"You respect us," he replied.

Somehow, sadly, this was an abnormality.

Lean principles, like Respect for People, seem to connect with fundamental human yearnings.

The desire for safety, security and respect.

The desire to have a hand in designing, and improving, your work, and to creating value for your customer (both internal & external).

The desire to be part of a team, in a great enterprise.

During the same trip, I asked the senior executive sponsoring our work, about extremism in the Middle East.

"Invest; give people decent jobs," he replied, "and all that crap would disappear in no time."

Best regards,