If I had more time, I would have written a shorter letter.
The philosopher John Locke, the statesman Benjamin Franklin, the transcendentalist Henry David Thoreau, and the President Woodrow Wilson all presented statements matching this theme (learn more here). All of them knew that simplicity is a final state that requires hard work and clear ideas. Work executed without proper reflexion tends to be erratic, messy, partial. Only time and work can develop a concept and present it pure and clear.
It is no surprise that one of the most important Lean ideas is looking for simplicity: simple solutions, simple management rules, simple visuals. And, ironically, simplicity is not simple. It takes time, practice and patience. The first solution / panel / management system you put in place is rarely good. It typically needs time for testing and for development based on customer feedback.
Give time to simplicity.
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.
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.”
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:
Efficiency and effectiveness are two terms widely used in operational excellence and Lean. They are used indistinctly many times, but their meaning is really different:
Efficiency is doing the thing right. Effectiveness is doing the right thing.
Effectiveness is related with the Critical Quality Attributes of the product: those features and characteristics that your customer expects and is willing to pay for. A process is effective only if it provides what the customer wants. Efficiency is linked to Performance: how work is done and how well are the available resources used.
All combinations of effective/ineffective – efficient/inefficient are possible, even the counter-intuitive “efficient & ineffective” (well, some people think that effective is a prerequisite for efficient. This means that a process not doing the right things – therefore, ineffective – can not be considered efficient. It’s a valid point but I’ll consider effectiveness and efficiency independent from now on). Let’s see an example. Imagine I want a portion of pizza for dinner. Four things can happen:
- The taste and temperature of the pizza is perfect (effective) and I get it very quick (efficient)
- The taste and temperature of the pizza is perfect (effective) but I have to wait too long (inefficient)
- I get a cup of coffee instead of pizza (ineffective) but very quick (efficient)
- I get cold pizza (ineffective) and I have to wait too long (inefficient)
Please note that in this example we are assuming that a quick process is an effective process. This is not necessarily true for several reasons. First, speed can be accomplished assigning excessive resources to do a job. This would lead to high speed but also to high costs, which is absolutely not efficient. Second, speed is often a Critical Quality Attribute, more related with effectiveness than with efficiency. However the “speed = efficiency” assumption is a fair simplification for this example.
Efficiency is important; effectiveness is absolutely critical. Ineffective processes are constantly producing things your customers will not buy: this destroys the company reputation and economy. Always solve effectiveness problems immediately. Then, when you know you are doing the right things, it’s time to start thinking how to improve them.
There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.
Measuring work is not enough. You have to measure value.
We forget this too often!
Scrap doesn’t come for free, we pay someone to make it.
So sad, so true.
A good decision is based on knowledge and not on numbers.
And that’s why “a group of experts who solve your problems for you” is a wrong Lean approach
“Doubt is an uncomfortable condition, but certainty is a ridiculous one.”
- Problem one: management is not sharing the needed information with the shop floor. Managers who find everything crystal clear may honestly think that they are doing a great job sharing the critical information (e.g. what process step is causing most complaints). He/she can not understand why others don’t get it. The process may be truly very easy to understand but the information is not available where the work is really done. A gemba walk can be a great solution for this, so that this person sees in what conditions the work takes place. Once the real situation is clear, excellent next steps can be the implementation of standard work & visual management to make information available and make sure that it reaches every part of the process.
- Problem two: management is not getting the needed information from the shop floor. In this case, managers are oversimplifying (on purpose or not) a situation that is really more complex than they might think. Again, gemba walks and talking to process experts will work as an eye-opening experience. After this, standard work & visual management will help now too, but in this case you need to focus in making problems visible to everybody, agree actions to solve them as a team and make leaders go to the gemba regularly and track results.
People who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year.
One of the basic concepts of PDCA (Plan-Do-Check-Act) is that you should plan your improvement work before you actually start doing it. In many cases taking baseline data, talking to experts and, of course, going to the gemba is needed for a good “plan” phase.
But unfortunately some people stop here and data is taken as if having a check sheet or an excel file is enough. It is NOT. The plan phase has to be done looking for subsequent action. In other words, get the data you need to move to action in a meaningful way with a controlled level of risk.
Two notes on this:
- “Meaningful” does not mean “be sure that you will be right”. It means “be sure that you’ll learn something”. Don’t do useless tests just because you forgot to measure a critical parameter. Sometimes you are lucky enough to prove the root cause of your problem. Hurrah! But proving some hypothesis wrong can be even more important.
- Every change has a certain level of risk. There is not such a thing as “no risk”. I’m serious. The good thing (?) is that doing nothing can be even more risky. Not being scared of trying (controlling risk, of course) is key. Creating an environment for safe testing is fundamental.
Once the Plan-Do is done, it’s time to Check and Adjust as needed!
Plans are nothing; planning is everything.
Dwight D. Eisenhower
Standards are just like plans, their power is not in their existence (they are, of course, fundamental to reduce variability and great tools for training, but this is another story). A standard work sheet by itself means nothing. It will not improve anything. However, standardizing is critical because it forces you to think what is the best way of doing the work. Then it helps identify when something in the process is not working as it should; they set a baseline to make problems visible. A process without a standard is very difficult (impossible?) to improve. If anything is valid, how will you know if things are going wrong? Standards are the keystone for continuous improvement.
Standards are nothing, standardizing is everything.
P.D. If after reading this post you still agree with the message on the mug , you can buy it here:
“To improve is to change; to be perfect is to change often.”
Incremental and frequent change is often the key to success. Incremental because small changes are notably easy to accept and their risk is more controllable. Frequent because they help create a “culture of continuous improvement” and everybody gets used to both success and failure without taking them too seriously.