Category: Respect

Posted on

PDCA, A3 and Practical Problem Solving

Over the years, I have been party to at least three corporate-level efforts to bring “A3” or “Practical Problem Solving” into their toolbox. Sometimes it has other names, such as “Management by Fact” or such, but the approaches are all similar.

Typically these efforts, if they catch on at all, become exercises in filling out a form.

Actually, that shouldn’t be a surprise, because they are often taught that way – as process of filling in boxes in sequence, with a “module” for teaching each step.

Worse, it is often taught as an intellectual exercise, and once you are done with the three day class, you’ve been “taught.”

The various classes mention PDCA as being a crucial part of this process, but nobody really practices it.

People are sometimes taught that this process should be coached, but the “coaching” they get is typically organized as management reviews via PowerPoint.

The “problem solving team” shows their analysis and their “implementation plan” that is a list of tasks, and a timeline to get them done. The meetings become status reviews.

Sometimes the “coaches” offer suggestions and speculation about the problem, symptoms, or actions that might be taken. They rarely (if ever) get into the quality of the PDCA thinking.

This is one of the challenges we have in the west (and especially in the USA) where our culture is more one of “go it alone then get approval” rather than true teamwork with the boss. This often turns the “A3” into an exercise of getting approval for a proposal rather than a learning process.

Worse, it does nothing to teach the problem solvers to be better problem solvers.

Note that sometimes an A3 is used for a proposal, but the process of creating it is still coached, and part of the process is the consensus-building that happens before there is any meeting. But here in the west, we still seem to like to spring these things on a leadership team without a lot of that background work ahead of time.

Mike Rother and the “Toyota Kata” community have been discussing this gap lately, and working to close it.

The latest iteration is this SlideShare that Rother sent around today:

He clearly points out what people have been missing: The “A3” is really just another method to document the “improvement kata.”

The “Implementation” box, rather than representing an action item lists, is where the problem solver captures her PDCA cycles, what is being tried, what is being learned, as she drives toward the target condition.

The other boxes are capturing her understanding of the current condition, the target condition, and the impact of various problems and obstacles in the way of closing the gap.

One thing that makes this extraordinarily difficult: We are talking about more than the mechanics of problem solving here. We are talking about shifting the default, habitual structure of the interaction between people. That is culture, which is notoriously hard to change. Not impossible, but unless people are up front that they are actually trying to change at this level, there are a lot of obstacles in the way. This can’t be delegated.

Posted on

Eliminating Key Points

TWI Job Instruction is a structured process for breaking a job or task into teachable elements, and a 4 step process for teaching that job to someone.

I am not going to try to explain everything about breaking down a job here, this post is primarily for people who use job breakdowns and job instruction already.

The process of breaking down a job involves:

  • Identifying the Important Steps – the sub-tasks that materially advance the work.
  • Then identifying Key Points within important steps. These are things which the team member must pay special attention to, or perform a specific way. The guideline is that a key point is something which:
    • Is a safety issue – could injure the worker, or someone else.
    • Would “make or break the job” – critical to quality or the outcome of the work.
    • Is a “knack” or special technique that an experienced team member would use to make the job easier to do.

Breaking down a job this way takes practice, but it is a great way to identify the elements that are critical to safely getting a quality job done, and ensuring that the team member understands them.

But I want to propose this is only the first step.

Every key point is something the team member must remember in order to to not get hurt (or hurt others); to avoid scrapping or damaging something; to perform at the level you need.

Take it to the next level.

Think of these key points and the training that they drive as temporary countermeasures.  They are stop gaps you have in place until you can do something more robust.

Take one key point at a time. Why is it necessary? Why is it possible to do this step any way but the best way?

Can you alter the work environment – the product, the process, the equipment, the visual controls to reduce the things the team member has to remember (and you have to remember to teach)?

Can you make it impossible to perform that step in any way other than the way it should be done?

If you can’t, can you make it impossible to proceed until the error is corrected, before any harm is done?

If you can’t, can you make it so obvious that it is impossible to miss?

If you can’t, can you put in a robust reminder? (Signs and placards generally DON’T WORK for this unless they are especially “sticky.”

Every key point is something you have identified as critical to doing the job directly. Therefore every key point should drive a focused effort to mistake-proof the work.

You want to have as few as possible… but no fewer.

Posted on

The Value of Mistake Proofing

Most companies use some version of the words “respect for people” in their HR mantras. But how is that respect demonstrated?

A team member made a mistake today. He is building a sub-assembly on a mixed model line. He picked a part from a small blue bin with a divider in it.

On one side of that divider is the part he should have picked and installed.

On the other side of the divider is a very similar part.

Guess which one ended up in his hand?

The issue wasn’t caught until a couple of positions down line. When it was caught, it was quickly reworked and corrected.

This particular team member is coming up on the end of his 90 day probationary employment period.

He has seen co-workers who “didn’t make it” (not cut out for assembly work). But he is a smart guy, hard worker, has participated in a lot of improvements for the work he is doing.

Nevertheless, he is worried about the consequences of making this mistake so close to his 90 day evaluation. He just wrote, it seems, what he hopes is his last COBRA check* that will cover him and his wife until his health insurance kicks in at the end of the month.

What is the value of mistake-proofing this operation?

Actually, the consequences of this error are minor. It is easily caught and quickly corrected in a subsequent operation. It is very, very rare. You could make the argument that there are better returns spending the limited problem solving time on bigger issues, and you’d be right… to a point.

But what if this team member’s experience was to see attention focused, not on him, but on what it was about the layout of the work area, about the presentation of parts, about the structure of the work, made it possible to make this error.

What if they acknowledged, overtly, that this kind of mistake is a consequence of being a human being, and that it was only that he happened to be the one standing there when the random chance generator came up?

What if he saw the team leader and supervisor engage him in conversation about what might be done to at least eliminate some of those possibilities? (We don’t really know what happened, though there are some likely guesses.)

What if he was also asked to look for other similar error opportunities, even in his co-worker’s areas, and help eliminate those as well?

What would be the return?

Might this team member work just a little harder to make things even better in the future?

Maybe he would help turn around a cynical or skeptical co-worker.

Maybe he would feel a bit appreciated for what he is contributing instead of losing sleep about his job.

Maybe, at some point in the future, when he is a shop steward, he might remember that “they” are all to human as well.

Who knows.

Before you say “it isn’t worth it” remember what Deming pointed out – “Management’s real job is to manage the unmeasurable.”

Good news – in this (real life) case, they are, for sure, eliminating the split bin and separating the two similar parts from one another; plus likely separating two other bins holding similar bolts. Maybe more, there are some ideas being kicked around.

In the end, though, consider if you will the ROI on team members knowing you will support them in their quest to succeed every day.

*For my non-US readers: COBRA is a program where someone can continue employer-provided health care after termination of employment for up to 18 months by paying the cost yourself. This is sometimes cheaper than purchasing private health insurance.

Posted on

Obstacles vs. Lists of Tools

I have been noticing a significant linguistic difference between those who still embrace the “implement the tools” paradigm, and a much smaller (but growing) group are are adopting the PDCA thinking structure as a framework for everything else.

It comes down to how a problem is stated.

We were looking at an operation with a lot of variation from one team member to another, both in terms of performance, and actually, what precisely was being done.

When asked what the obstacle was, the immediate reply was “Lack of standard work.”

While this may have been true, it is not a statement of the problem. Rather, it is defining the problem as “lack of a specific solution.”

This may seem to be an semantic discussion, but consider what the responsible supervisor hears, and interprets, from these two statements:

“There isn’t any standard work.”

or

“There is a lot of variation from one operator to another.”

In the first case, we are telling the supervisor what she isn’t doing, hasn’t done, needs to do. It isn’t even teaching.

In the second case, we are pointing out something that we can both agree on. I haven’t even said it is a problem, and honestly, in some cases it might not be (yet). It is a simple observation.

If, then, we agree that this variation is leading to some undesirable effect, then we can talk about countermeasures. That might include trying to capture a baseline, teach it to a few of the team members, and see if that helps. We can name it later.

Which of those approaches is more likely to enlist the support of the supervisor, which is more likely to put her on the defensive?

Lean thinking is not a checklist of which tools are in place. It is a step-by-step convergence on smoother flow, dealing with observed obstacles and problems.

This isn’t to say that the coach doesn’t have intimate knowledge and experience with flow, with standard work, and everything else. But the approach must be respectful of the people who are struggling with the real world issues every day. Saying “You need to implement standard work” isn’t helpful no matter how much logical justification is wrapped around it.

Teaching someone to observe the impact of variation on the process might seem slower, but it will get them there much faster because it engages their curiosity.

Posted on

Visual Key Points

(Apologies for this post being “Password Protected” – I posted it from my smart phone, and obviously need to mistake-proof  something in the interface.) – MR

A key element of TWI Job Instruction is breaking down the job into important steps, key points, and reasons why.

An important step advances the work.
A key point is a critical aspect of the work that would:

  • injure the worker (or anyone else).
  • make or break the job.
  • make the job easier to do (a knack or technique that an experienced operator knows).

If it is worth making a key point over, it is worth putting a visual cue in the workplace.

If the key point is about something that would injure the worker, or make or break the job, you have a rich opportunity for mistake proofing.

In other words, a key point is something you are asking the team member to remember.

Help him out by reminding him or even better, engineering the work so that he doesn’t have to remember.

Posted on

Struggling to Learn

One of the challenges of teaching and consulting is resisting the temptation to give people the answers. Honestly, I like giving people the answers. It feels genuinely helpful, and it provides a nice ego boost.

But according to this article on Time’s “Time Ideas” site by Anne Murphy Paul titled “Why Floundering is Good,” that isn’t the best way to teach.

In fact, it can hinder learning.

The key point is summarized at the end:

… we need to “design [teaching] for productive failure” by building it into the learning process. Kapur has identified three conditions that promote this kind of beneficial struggle. First, choose problems to work on that “challenge but do not frustrate.” Second, provide learners with opportunities to explain and elaborate on what they’re doing. Third, give learners the chance to compare and contrast good and bad solutions to the problems.

Right now we are (hopefully) in the midst of a paradigm shift in how lean practitioners and teachers go about what we do.

Traditionally, a lot of us have simply given people the answers, or at least strong suggestions. Given the time constraints and overly ambitious targets of a typical 5 day event, that is understandable.

But now we are starting to see these events as skill building, which means learning, which means the teams need time to muddle through.

I have been structuring my approach quite differently for about a year now. I’ll be the first to admit that I, too, am figuring it out, reinforcing what works well, altering what needs to work better. These days I am far more comfortable letting things move through this struggle in order to set up deeper understanding once the light does come on.

The trick is to let them fail small, and not let them fail big. The problem has to have a solution that is within reach, or they will only come away frustrated.

Thus, teaching is becoming a matter of judging the knowledge and skill threshold and making sure they don’t take on too much at once. That is part of respect for people.

One problem at a time. Single factor experiments.

A great deal of the power in the “Coaching Kata” is turning out to be the question “Which *one* [obstacle] are you addressing now?” as it rules out working on everything at once.

Posted on

Decisions, Decisions

How many “If-Then” steps do your team members have to deal with in the course of their routine work?

Every one of those branch points is a decision. It is a point where the team member must memorize decision criteria and the correct choice(s).

Each “If-Then” in the process flow potentially doubles the number of possible paths the process can take.

Each decision is an opportunity to make a mistake.

The more complex a process, the more time and experience the team member requires to master it.

Mental bandwidth is limited.

The more attention they must expend to do it right, the less they can devote to thinking about how it could be done better.

How complicated a world do you create for people trying to do the work?

The more “flexible” your human interface with the process, the more complicated it is for the person who has to use it.

Do they have to enter ad-hoc query criteria into computers to pull information they routinely need every day?

How many decision criteria are things that people “just know?”

How often does someone encounter a problem or new situation and get a verbal instruction from the supervisor on how to handle it? What happens then? Maybe a general announcement at the next team meeting, if you’re lucky?

Go down to your work area.

Watch how people interact with the routine work.

Each of those decision points is an opportunity to simplify your process flow and make life a little less stressful for all of you.