Tag Archive | PDCA

PDCA: is it REALLY important?

PDCA (Plan-Do-Check-Act) cycles are one of the most important parts of lean, because improvement is a cycle (learn more here).

I am often asked if all steps are really important or if the sequence truly matters. The short answer is YES. The long answer is YES, because:

  • No “Plan” –> you are working without a goal. This creates useless tasks, repetitive and redundant testing and, even worse, nobody will really know if things are going ok or not. If you don’t have a goal, there is no standard definition of “good” or “success”. In other words, you don’t have a hypothesis. It is also difficult to have a motivated investigation team if they don’t have a clue of the goal of their work.
  • No “Do” –> you might have great plans and a very clear goal, but you will not learn until you do experiments and prove/refute your hypothesis (learn more here). This problem usually happens with very complex issues, inexperienced people or high-risk situations (“I’m scared to try”). The effect is often called “paralysis by analysis”.
  • No “Check” –> testing results are incompletely or not analyzed at all. Learning will not happen and/or conclusions will be wrong.
  • No “Act” –> working standards are not updated. Knowledge is not incorporated to regular work and the company is condemned to repeat the same errors again and again.

As a summary:


Lean Principle #7: Lead by Example

Lead by example

I liked very much this article by Justin Bariso at http://www.inc.com because it highlights the most important Lean leadership principle: Lead by example. The “Do what I say, not what I do” motto has never been valid, and it will be a total killer when applying Lean or any other continuous improvement methodology.

Lead by example is easy to say and difficult to do. I’ve seen this error happen over and over, but there are certain situations when it is extremely common:

  • Starting a Lean transformation: Some think Lean can happen even if the leader is not present. This is wrong. No Leader, no Lean.
  • Creating a learning culture: When problems arise and Lean looks like a bad decision, it is easy to look for someone to blame. Leaders must be the first who keep calm, promote real problem solving and avoid witch-hunts.
  • Involving others: If, as a leader, you take all important decisions, how will you teach your people to trust and cooperate with others? Delegate, create an environment where testing is welcome and focus more in “how can I help?” and less in “how can I control?”
  • Outsourcing Lean work: Lean might be considered as something an external consultant can do for you with your team. Wrong. Consultants share knowledge, leaders make change happen.

A final thought:

Example is not the main thing in influencing others. It’s the only thing.

Albert Schweizer

Lean principle #6: The right speed


One frequent question when working with Lean is “are we going too fast/too slow”? Changing is always uncomfortable and it is normal to question yourself if things are going as they are supposed to be. Well, speed matters in Lean but, as usual, there is no “right” or “wrong” answer here. Each situation is different and needs different approaches, so what to do? Let’s see the problem from its 2 sides:

  • The risks if change goes too slow: people feel that problems are not solved, people feel their work is not bearing fruit, higher probability of rumors, higher probability of “I told you it wouldn’t work” and other similar sentences. In summary, Lean loses momentum and looks like “the improvement initiative of the month”
  • The risks if change goes too fast: people feel that things are changed with too little analysis, risk looks is higher, there is a higher feeling on improvisation, the valuable ideas of those who don’t speak up easily (introverts, new employees…) may be lost. In summary, Lean looks like something imposed from top management.

Yes, practicing Lean might be complicated. My proposal is to move “as fast as possible”. Start slowly to make sure a) everybody is on board and b) the first “projects” are a success. Then increase speed incrementally. When everybody has been exposed to the cultural part of Lean (we all know people will be respected, lay-offs will be the last option, speaking up is safe…), it is better to go a little bit too fast than a little bit too slow because speed will help create quicker PDCA cycles and learning happens (obviously) also quicker. Change will be evident and everybody will feel it. Always get people’s feedback: the sweet spot is where people feel challenged without being scared.

Lean Speed

Lean is like riding a bike: moving either too slow or too fast will make you hit the ground. Start slowly and increase risk and speed as you gain experience.



Root cause analysis Rule #3


This week I’ve seen a problem that happens (sadly) all the time.

Imagine a company / department / team that has a problem (e. g. equipment failure that could impact the product quality). People who work at the work center and their immediate supervision meet at the gemba and agree how to investigate the problem. Some ask their managers if it is ok if they investigate, management says “of course, we believe in people, you are the experts, we trust you”. The team thinks, develops ideas, tests, learns together (e.g. “what are the equipment failure modes?”, “how could we detect them?”, “how can we know is this error has happened?”, “how can we prove our hypothesis right or wrong?”, “how can we evaluate if the product is still good?”). They discover the root cause of the problem and develop an action plan to avoid it in the future.

They call a meeting to share their learning with the site directors and then….. shit happened. I’ll list the sad list of problems:

  • Directors came to the meeting with their own root cause analysis (of course, none of them had been at the work center or had spoken with any of the workers). It was a nice PowerPoint Ishikawa.
  • Directors developed their own action plan. It was a wonderful MS Project file.
  • The first time a team member talked at the meeting was 15 minutes after the meeting had started.
  • The team’s improvement ideas were ignored. No director asked about their analysis or improvement action plan. The team had spent more than 20 hours in 2 days doing their investigation.
  • Most of the meeting time was used by management to show why their ideas were great. 2 team members tried to talk and make a point about their ideas, but they were ignored. The team stayed in silence the rest of the meeting.
  • One director finished the meeting asking: “But, what do you think about this?” Another one said she was very happy to see the team working together. Nobody else said a word.
  • When leaving the meeting, one worker said “I’ve learned something. Never think by yourself.”

Meeting minutes:

always right 2

Director actions were implemented and the problem happened again 3 days afterwards.

This story is an example of one of the most important questions about problem solving: “what is the role of management in problem solving?” The tricky part is to see the difference between “supporting” and “doing somebody else’s job”. Remember rule #3: Problems must be solved by those who do the job. How can we do this? Let’s listen to the experts:

Management must move from “telling what to do” to “asking questions that provoke the right thinking”. Telling people what to do takes away responsibility from the person. Management main goals are a) find and frame problems by observing (at the gemba) front line learning and b) challenge, enable and remove obstacles for front line while they are solving problems.

Daniel T. Jones, Lean Conference 2014

The most important question from the management side is “What are your problems?” Management work is not to solve problems by themselves, but to develop problem solvers. Otherwise, you’ll become a manager like this:


Principles of visual management

Visual 1

This week I’ve heard a person describing visual management like “putting our Excel spreadsheet on the wall”. Sadly visual management tools are many times just an illusion and consist in a simple copy of previous management systems (spreadsheets, agendas, calendars…) made with paper or magnets hanging somewhere.

Yes, visual management must be “visual” (in graphic form) and “public” (everyone can see it) but that’s not really the point of it. Visual management must follow these principles to have the right to use that name:

  • Defines the standard condition
  • Highlights problems
  • Creates alignment
  • Drives action & learning

Visual management sin titulo

Defining the standard condition means that visual management is a prediction of how things will go on. We base the prediction on our standards. Visual management helps everybody understand what is expected to happen. Then we check how things go and a) celebrate that our prediction was right or b) discover that our prediction was wrong. In the second case, we have found a problem (assuming that our standards are correct. If they are not, the problem is that our standards are inaccurate). Visual tools make sure that information is shared and aligns team members. Then the team decides what to do to understand the problem and learn, find out the root cause of the problem and put solutions in place.

Visual management can be summarized as: “We see together, we know together, we act together” (see Al Norval’s post at Lean Pathways blog: link )

Don’t forget that Visual Management can’t work alone. It needs Leader Standard Work and Standard Accountability Processes to run properly.

Pictures from:

Best of @leanvoodoo 2015

This is a list of the most read articles of 2015. Enjoy!

















Thank you for your time and support!

See you in 2016!


The rules to improve anything


This picture is an old-time classic about communication. Originally made as a joke about how software is developed, it has many different layers which represent very well many of the problems of lean deployments:

  • “What the customer really needs”: First rule: listen to your customer and make the goal clear. No goal = no way to know how success looks like. Simple.
  • “How the customer explained it”: Second rule: go to the gemba. Customers are typically good at explaining their pains and setting a goal (e.g. “ship my product quicker”) but they are not always so good at explaining why things happen (e.g. “you don’t have enough trucks, my product waits too long. You should buy more trucks to be able to ship product quicker”). The best (and only) why to find out what to do is observing the process. Do it.
  • “How the business consultant described it”: Third rule: improvement must be developed by those who really do the job. Experts are ok and can give great value to your thinking process. However, the solution must be owned by whoever runs the process. Hiring somebody and asking him “solve this problem for me” simply does not work in the long term.
  • “How the process was documented”: Fourth rule: standardize. This does not mean “document everything” or “create human robots”. Standards are instructions to make the job in the best way possible known. They are made based on the experience of everybody. Standards must be fair and easy to change. This a great explanation by the Lean Management Institute:


  • “How the project leader, analyst, programmer understood it”: Five rule: communication. Poor communication is the main root cause of project failure (interesting article here). The impact is even higher in Lean or 6 sigma. Keep communication in mind. Tell others what you are doing and why.
  • “How it was supported”. Last rule: be ready to fail. Failing is bad, failing and not being ready for it is catastrophic. Change is mostly based in PDCA, each test proves or refutes something, so being wrong ( = making an hypothesis that was proved wrong) is part of the game. Don’t panic and just be ready for it.


Are these rules enough to succeed? No, unfortunately. But keeping them in mind can increase your chances of success!