Monday, September 21, 2020

“Failing to Plan is Planning to Fail”

By Al Norval (bio)

This is one of my all-time favorite quotes by John Wooden, legendary basketball coach at UCLA where he won 10 NCAA national basketball championships over a 12 year period including an incredible 7 in a row.

I like this quote not only because it’s a nice play on words but more deeply because it’s simple, it’s obvious and painfully true.

Given that, why do so many organizations fail to plan?

Are they really planning to fail?

Granted most organizations have some semblance of a strategic plan. It may take the form of a financial plan or a 900 slide PowerPoint presentation commonly referred to as “PowerPoint Junk”. True story – even the executive version was 90 slides long and completely incomprehensible.

True planning means taking the time to grasp the situation and think deeply about the issues, then determining countermeasures that are testable. It means deploying these countermeasures by focussing the organizations resources on these countermeasures and aligning the organization to their execution. It means having a quick check/ adjust process for when things go off plan.


In reality most organizations actually do have a plan, it’s just that outside the leadership team no one knows what it is or how the work they do contributes to it and therefore people don’t follow it and don’t impact it.

So the reality is – they are planning to fail.

Cheers

Al



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

Building Quality into the Process
Standardized Work for Knowledge Workers
Difference between Hansei and a Post-mortem
TPS and Agile



Monday, September 7, 2020

Building Quality into the Process

By Pascal Dennis (bio)

Jidoka is lovely Japanese word with multiple meanings:
  • Automation with a human touch,
  • Humanized or intelligent automation

Essentially, Jidoka entails giving processes, automated and otherwise, sufficient ‘awareness’ so they can:
  • Detect process malfunctions or product defects
  • Stop, and
  • Alert the operator

Perhaps the simplest definition is ‘to build quality into process using embedded, binary tests’.


Here is a charming example: when our son Matthew was younger, and shooting up like a bean sprout, there were frequent checks on the ‘clothing situation’.

As far as I can tell, the process steps include:
  1. Put questionable trousers, shirts and sweaters on top of Matthew’s bed,
  2. Matthew tries on each piece, and
  3. We keep or discard said piece based on a series of tests.

Here are the tests my wife & Matthew have devised for shirts and sweaters:
  1. Can Matthew get it over his noggin?
  2. Do the sleeves come up above the wrist?
  3. When he raises his arms, can you see his belly button?

These are applied in sequence, of course. You’ll notice they are binary and therefore, self-diagnostic.

The process is very effective – I’d estimate the first time through (FTT) is 100%. It also generates big laughs for the whole family.

Especially ridiculous fits trigger a droll Matthew parade. “Hey everyone, look at this one!”

Best regards,

Pascal


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

Standardized Work for Knowledge Workers
Difference between Hansei and a Post-mortem
TPS and Agile
Beware INITIATIVES



Monday, August 24, 2020

Standardized Work for Knowledge Workers

By Pascal Dennis (bio)

Standardized work (STW) is fundamental to the Lean Business System.

What's the best way we know - right now?

How do we summarize our current best way one, simple, visual page?

How do we engage our team in continuing to improve our best way?

These are core questions.

At Toyota I learned that STW comprises:
  1. Content
  2. Sequence
  3. Time
  4. Expected outcome
Embedded tests that signal Good/No Good are also critical.

Does this recipe apply outside the factory?

The embedded tests concept applies universally.

As for the other elements - yes and no.

Yes - in short cycle time, repetitive knowledge work e.g. a pharmacy or laboratory analyzing high sample volumes.

No - in long cycle time, non-repetitive knowledge work e.g. a surgery, engineering or design process.

STW confers all its customary benefits - if applied with finesse.

A good example is the Checksheet - which is simply a list of embedded tests that tell us whether we're okay or not.


Atul Gawande's fine book The Checklist Manifesto illustrates how we might apply STW to knowledge with finesse.

Translation will be vital as we move the profound Lean principles upstream & downstream of the factory, and into entirely new field of work.

(The Remedy is my humble attempt to illustrate what this might look like.)

The worlds awaits Lean thinkers with finesse.

Best regards,

Pascal


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

Difference between Hansei and a Post-mortem
TPS and Agile
Beware INITIATIVES
Point, Flow & System Improvement



Monday, August 10, 2020

Difference between Hansei and a Post-mortem

By Al Norval (bio)

Imagine a situation that has two possible outcomes:

  1. The solution is delivered on time and on budget with very positive Customer feedback
  2. The solution is delivered late, over budget and doesn’t meet the needs of the Customer


What typically happens?

In the first case we celebrate and pop the corks on bottles of champagne.

In the second case we call for a post-mortem, an exercise that is mostly fault finding and look for whose blame. Typically, we don’t look into process issues that caused the problems and ask Why? Result - no real learning and no improvements.

Even in the first case, with no review there is no shared learning. In this case the review should be on what went well and Why? What have we learned? What do we need to do to lock this learning into standards that can be used next time?

In both cases we want to ask the basic questions:

  • What should be happening?
  • What actually happened?
  • Why are there differences?

This drill will help us improve even if the results are very good since sometimes the results were good because we got lucky. I don’t know of any leader who wants to rely on luck as a management technique since it has a habit of turning next time.

There are always things that go wrong and all processes have waste. Kaizen is the relentless drive to remove this waste and to strengthen the health of our processes. But before we can kaizen our processes, we need to use Hansei to truly reflect upon the situation, and upon the health of our processes. Hansei is used to truly Grasp the Situation and requires honest, deep reflection and thought, both when things go well and when they don’t. Design reviews, gate reviews and post launch reviews are opportunities for leaders to zoom out and assess the health of the underlying process and look for improvements. Hansei leading to kaizen.

Cheers

Al


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

TPS and Agile
Beware INITIATIVES
Point, Flow & System Improvement
Andon – Putting Quality at the Forefront