Most lean efforts begin with middle management (you know, the people with ‘bad attitudes’ that usually get the blame for lean failures … funny how that works … middle management typically learns about lean, spends years trying to convince senior management to support it … then when it fails with lukewarm senior management commitment, the blame is put on middle management … but I am getting away from the topic). This brief note is for the rare situation in which a senior manager gets lean fever and wants to know where to start.
The best and the easiest first step is to simply change from driving the organization to make monthly goals, to making weekly goals. Most companies conjure up a disproportionate percentage of production and make a disproportionate percentage of the shipments in the last week of the month. Plants have learned all of the tricks necessary to pull out all of the stops and overcome obstacles by brute force to make the numbers. All the senior guy has to do is to announce that he is no longer interested in monthly production, shipments and budget performance. Instead, he wants to measure everyone on their performance to each of four equal weeks.
There will be a great deal of pain as all of the routine problems come to the surface – poor vendor deliveries, long set ups, machine reliability problems, etc… But sooner or later, the plant will figure it out. When they do, change the measurement criteria to daily performance. Then hourly.
Every time you put pressure on the system to execute consistently in smaller time increments, you are forcing more variability in the processes to come to the surface. You can overcome a vendor shipping three days late if you have all month to do it – it’s impossible to overcome parts three days late if you have to make the week. It will not take long before the old tools – and the brute force approach – won’t get the job done. As is gets harder and harder to reduce set up times and fix quality problems, plant management will be more and more receptive to lean tools. You won’t have to convince anyone to learn SMED – they will be desperate to learn Shingo’s set up reduction techniques and principles.
I learned that from a guy who buys small, under-performing manufacturing companies and whips ’em into shape. He had neither the time nor the inclination to get hands on in driving lean transformations in all of these companies. Instead, he drove them to shorter performance intervals. When they squealed loud enough, he suggested that they go out and learn something about lean. Through this method, he created motivated management teams, eager to become lean, if for no other reason than to get him off of their backs.
It works.
ed says
I like that! What a marvelously simple device to reveal the devils in the details.
Mark Graban says
I think Deming would remind us, if he were still with us, that “tightening the screws” and pressuring people isn’t the best approach, whether it’s done monthly, weekly, or hourly. If you just put pressure on people, they might find a way to “look good” without really improving the system.
Management (leadership really) needs to do more than be an a-hole that the managers under them want to avoid and “Get off their backs.”
I think real lean leadership asks people “what can I fix for you?”
Yeah yeah, someone will say “well Ohno was a world-class jerk.” I don’t hear Gary Convis talking that way, about pressuring and hammering people. That’s the way old GM managers used to talk and it was never very effective.
GM managers would say “I need 60 parts an hour every hour” and the supervisors would fudge the numbers to report 60 and no more than 61 parts per hour, they would make 30, 90, 30, 90, but the report at the end of the day would say 60, 60, 60, 60.
It takes more than screaming and pressure to get the job done the right way. Remember that.
Bill Waddell says
It’s not about screaming and pressure. It is a simple means of gradually raising the bar. As execution requirements get more demanding, they reach the point that they cannot be met with traditional methods. The only way to meet the performance objectives is through lean methods.
Note that he was not asking for any more production than before – he simply wanted production leveled by ever smaller time increments. Eventually the time increment is too small for batch manufacturing to comply.
If this approach puts any pressure on production management, it is pressure to think about solving problems in a different manner.
If you think about it, Mark, you will realize that all he did was lead the lean effort with heijunka. By demanding mixed model/level flow, he forces improvement through lean methods.
Mark Graban says
I guess I still show my scars from my GM time and the “leadership” there. It surfaces once in a while and I project their screaming and bad attitudes onto others, including your friend who is “whipping” them into shape. And by “whipping” we mean coaching them and creating a learning organization :-)
Micheal Gardner says
I used to work for a manager who believed that he could be any kind of jerk he wanted as long as it was in the name of the lean transformation. That hurt our ability to get lean, it didn’t help it.
But, if leadership takes the correct approach, the method Bill illustrates can be very effective. However, if your customers don’t order in some kind of level manner you can’t very well ignore their desires in favor of your level system. If they order three times as much the lat week of the month as they do the first three weeks, make it for them.
JCatara says
Your writing is so on target. I really like this site. I learn alot.
As a team leader I have found that simply having the operators write down simple information works. What part? Where made? How many good? How many bad? Then take the numbers and make a graph and add a trend line. This is easy to do in excel. Review it at the daily team meeting. As we see progress we tend to strive for more success. Everyone likes to be on a winner, and I mean everyone.
Henrik Mårtensson says
I work with software development. The posting reminds me of a manager who did keep tightening the screws by asking for very frequent time estimates. The project I worked in was late. The manager got nervous, and decided he needed “accurate” information about project status. He told the developers to update their time estimates up to three times a day.
I measured how much time we spent on time estimates, and rework because key personel sat in meetings about the time estimates when the team worked on some rather difficult stuff. We spent about 75% of our work day on those estimates, every day.
Of course, the manager could have gotten automatic hourly updates of production data, if he had allowed us to set up a build machine. (A computer that automatically builds the system under production, runs tests, and reports how much of the functionality that has been implemented.)
Ultimately the project failed through a combination of bad project management, bad change control board management, bad mid level management, and bad upper level management. A few samples:
The change control board forbade reporting productivity data. The only metrics that were allowed were time estimates and worked hours. They also pushed for a corporate standard version management tool that ate up to five hours per week, per developer. That was out of the 25% development time that was left after the project manager had done his thing.
Mid level management supported both the project manager and the CCR, even though what they were doing clearly stood no chance of working.
Upper level management had put a very rigid functional organization in place. The development team was forced to use in-house tools for political reasons. At the same time, tools and techniques that might have helped, were forbidden.
The management did succeed in putting pressure on the developers, but that was all they succeeded in.