Gemba Coach by Michael Ballé

It seems that lean these days is all about learning and coaching. What about the good ol'-fashioned just-in-time stuff of the earlier days?

Wed, 02 May 2012 04:00:00 GMT

Dear Gemba Coach,

It seems that lean these days is all about learning and coaching. What about the good ole-fashioned just-in-time stuff of the earlier days?

Touché – and I plead guilty. The other day I was on the gemba of a plant that makes industrial equipment and had exactly the same discussion with the plant manager. This fellow has an excellent, intuitive grasp of respect and a deft touch with people. He’s really good at getting people to work together and has a gift for fostering both change and goodwill. But his corporate management is asking for immediate productivity results, by the book and by the numbers. Hmm.

Now, in a low-volume high-variety business run by an MRP, quick productivity results are hard to find. There is no high-runner cell with ten operators that can be quickly kaizen-ed down to five. There are a lot of grinding, turning, milling machines, a monument of a paint shop, a few craftsmen-like assembly stations, and many operators milling about according to where the supervisor needs them. Not surprisingly, on-time-delivery is a struggle, and productivity is poor. This is not seen as a problem since the margins per product are high, but we all know what senior execs are like when it comes to productivity figures (and their own bonuses).

To make matters worse, in a high-variety environment, any increase in volume means an increase of one part or component missing, which requires a schedule change, leading to less OTD and productivity … so we won’t be saved by volume. That sucks. The strategy then, is to ship on-time-as much as possible, in order to get cash in hand from the customers and pacify corporate with cash and bottom-line. But how?

Not with Safety Glasses
We need to look at the same situation with several different pairs of goggles. One, the respect glasses, reveals how everything we ask operators to do that does not add value or does not contribute to shipping products is a lack of respect. Guys are here to work, not to fill in paperwork or recount kanban cards. The more focused their work, the more productive, and the more likely we are to ship on time. But how can we focus on the right problems?

We use the other pair of glasses: the just-in-time system, and a view of the entire factory as if it was a mechanical engine. We were looking at the value-stream maps his team had been doing, and they had the usual flaw of detailing the material flow and sketching the information flow as an afterthought. Value-stream mapping (VSM) is part of a lead-time analysis, not a process analysis. So two critical aspects of VSM are:

The number of references made on each machine, since production lead-time is calculated as the time between the last part of A from the previous batch to the first part of A from the next batch (with batches of B, C, D, etc. in between).
The frequency at which information is updated in the information flow: once a week? Once a day? Every hour? Whenever something happens, and so on.

The main problem of a high-variety environment is that although everyone is busy working, they’re usually working on the wrong part. As we walked the shop floor we checked the work orders: either ahead (parts needed for next week, aka overproduction), or late (parts needed yesterday, aka waiting). So we tried to look at the production process as a dynamic system of information converted into action, and then into parts. What tells who to make what when. The more frequent – and the more regular – the update, the better chances of making the right stuff at the right time.

Want Fries with that Kanban?
Developing the dynamic vision of just-in-time is by no means intuitive, and it requires learning the techniques and discipline of a pull system. For instance, they’d set up a vague form of kanban with a launcher that had many, many cards in it. Now, any restaurant works with kanban. The front waiter takes the orders when people sit down, and then puts them in front of the cook to make in the same order. The cook picks up each order and either (1) it’s a today’s special so she takes it from the supermarket of ready dishes or (2) it’s à la carte and she makes the dish from scratch. Then it’s shipped. Like a complex product, a table has to receive several different dishes at the same time, but hey, restaurants mostly get it right – so why not factories?

Back at the gemba we looked at the launcher and we calculated that the machining team had orders for the next three days. This is massive overproduction of information, and leads to a number of problems. First, how likely is it that the kanban cards of three days in the future truly represent what will really be needed then? Secondly, with three days of cards ahead of you, how tempted would you be to pick and chose the ones you feel are urgent, or easier to make? Thirdly, and this is where just-in-time dovetails with involvement and engagement, with three days of work ahead of you, how determined would you feel to get the work down rather than have another smoke before changing the tool setting once more? How involved would you feel with the company’s determination to ship to its customers?

There is a sly underhand trick to pull: it completely changes frontline management’s job. The supervisor can no longer decide what to do when; she’s got to follow the cards, just like the cook. The supervisor must now focus on doing the job right, much like the cook again. Some supervisors will love it, feeling liberated from self-defeating decisions, and some will hate feeling technically challenged and losing petty boss’ power.

Furthermore, this also means that information management and material handling is taken away from the operators’ job and given to a specific logistic function: the train that delivers parts and picks up cards, cards which then need to be sorted and redistributed. When this happens we suddenly realize quite how many tasks operators have to perform that have nothing to do with making parts.

The difficulty, of course, is to walk on two feet – to hold the two different visions – just-in-time and respect-for-humanity – at the same time and slowly learn to figure out how they converge. This was, I believe, already the point of the very first paper on lean published by Toyota veterans back in 1977, although at that time much of the paper was devoted to calculating kanban cards. We’ve learned the hard way that respect is as important as kanban, but maybe we’ve now overcorrected. Without both a system-level and card-level understanding of JIT, respect becomes wishful thinking and will not satisfy any of our stakeholders: neither the operators (we’ll “respect” them on the wrong topics – they’re not fooled that easily, involvement comes from sharing the company’s objectives) and neither corporate. Never easy, but let’s face it, never boring either!

What's the difference between model lines and kaizen events?

Thu, 26 Apr 2012 04:00:00 GMT

Dear Gemba Coach

We used to do six sigma and are new to lean. Some consultants talk to us about model lines and others about kaizen events. Can you clarify the difference?

That’s a difficult question, and I’m not sure I have all the answers. The various formats for “doing” lean emerged from the work Toyota was doing with its suppliers in the eighties, and the way that consultants interpreted it to sell projects to customers. What we’ve learned since is that the challenge is to become lean, rather than to implement lean, and so the various consulting formats don’t necessarily apply to every business. Let me recount what my father and I have learned from his experience of becoming lean under Toyota’s guidance back in the 1990s.

At the time, Toyota was toying with the idea of developing suppliers in Europe as they’d done in Japan. The situation was rather different. In Japan, many of their suppliers were part of the keiretsu. Many of the supplier’s managers were ex-Toyota employees, and Toyota was a dominant customer of most of their target suppliers. Not surprisingly, the suppliers were, if not eager, at least open, to learn more about TPS and the Toyota Way. In Europe, Toyota was starting its first European plant in the UK, had no pre-established relationships with supplier’s management, and usually represented a very small volume in any one supplier’s plant.

My dad turned out to be a natural candidate because as a Renault top executive he’d previously developed a long-standing relationship with Toyota TPS experts, and now that he was Industrial VP of a supplier, it made sense to start with him and a few others. As far as I remember, Toyota did start with a model line. They focused on one part, the light indicator, in one factory and invested quite a bit of resource in turning this production line into a lean showcase: one or two Toyota engineers visited the line on a monthly, sometimes weekly basis to spur kaizen. From my notes at the time the big fights were fought over quality and flexibility. The aim of the Toyota engineers was to turn the usual long-changeover, long-run, production line into a flexible cell which would produce five containers of five parts and then change reference. This had many technical and ergonomic implications as it meant modifying the machinery so that the lady operators on the line were able to easily (because of the number of changes) make the change. When the work started, tool changes needed a specialized setter who could not be available for such a frequency of changes. More frequent changeovers also created more frequent quality problems, usually at the setting stage which needed to be resolved.

Over the course of two years, the line evolved into a real “model” for all the TPS main principles: single-piece-flow, small batches, standardized work, andon, etc. As corporate level VP, my father visited the line regularly with a very senior Toyota guy who had learned TPS working directly with Taiichi Ohno. The line made considerable improvements, and it was then assumed by my father and his CEO that the trick now lay in “deploying” what had happened on the model line. So they sought to devise a cookie-cutter methodology they could then apply across all the 70 plus plants of the group. The idea was that a 5-day “kaizen event” would be sufficient to introduce the key principles of lean to any new cell and then local management could pick it up from there. The logistics of it seemed daunting, but hey, we’re talking about automotive and these guys don’t scare easy. Did it work? Well, something happened, but it’s hard to evaluate what with hindsight because of a huge wrong assumption.

Lean Laboratory
The question Freddy and I asked ourselves much later was: what was Toyota after? They never asked for any compensation for all the time and effort during the project. Sure, they secured supplies at their standards from that line (in plain English, they colonized the line), but at a huge expense. Did they really intend the “model” line to serve as a replicable model that could be copied-and-pasted across the supplier? We don’t think so. Having talked it over for hours on end, we’ve come to see two large benefits to Toyota’s involvement:

30% total cost reduction (shared half and half) on the new product: sure there were productivity gains during the kaizen effort on the existing line, but nothing like the engineering impact of the learning from the kaizen on the next generation product. That was massive, and Toyota got out of it a 15% price reduction on the new product, with a supplier happy about it since they increased their margins as well: classic lean win-win.
My father’s education: with hindsight, we also believe that Toyota was not trying to develop the supplier as a company, but to educate my father, who, as a senior executive would then have a disproportionate impact on the company. The “model line” on which the local engineers sweated so many tears was only a support device to get my father to learn first-hand the lean principles. And, as it turned out, the plant’s plant manager refused to get interested, and the plant never became lean, but the company as a whole did.

The model line, in this sense, was not about creating a “model” that could be replicated everywhere else (which we really believed at the time), but a laboratory to show my father how far they could take lean concepts, and with what impact both on the product and the process. To be fair, the deployment efforts did pay back because of the sheer gap of process knowledge, but the company never acquired the kaizen spirit underlying the TPS. It progressed, but then when my father left the company to become CEO of another automotive supplier, all progress stopped.

By that time Freddy had a well-established relationship with his sensei, and they no longer did a single model line. They visited various plants, and each time the sensei highlighted one specific issue. My father’s job was then to figure out a kaizen event with the plant manager to address this issue. It wasn’t that hard because most typical kaizen tools were well-known by then: 5S for visual management, flow-and-layout for productivity, SMED for flexibility, QRQC for quality issues, TPM for OEE, and so forth. But, yet again we missed the point—we were still obsessed with deployment, despite the fact that my dad had moved on from a tool-based program to a roadmap-based program. He was still trying to “deploy” lean. Again, with hindsight, we now see that the sensei was highlighting specific issues and was expecting specific responses from the plant’s management, in order for them to learn, and again, educate the CEO.

Lean Practice Basics
Rightly or wrongly I now believe that lean is about learning, whereas Taylor-ism is about deploying. Six sigma projects involve a team of “experts” who will DMAIC a situation, come up with a solution and get the natives on the floor to execute. Lean, on the contrary is about learning-by-doing: specific events, whether model lines or kaizen events are designed to get local employees to learnt o solve issues and to educate senior management. The basic lean practice, I have learned is:

Visualize activities
Formulate problems
Seek root cause
Study countermeasures

The emphasis is on studying countermeasures: catch people doing something right, and more importantly, something they’ve not done before, check it, and learn.

To answer more directly, in this perspective, model lines serve as learning labs to see how far you can take an activity by applying all principles of lean in one area, whereas kaizen events are about tackling one typical issue repeatedly across various situations until one gets the hang of the typical solution, and a deep-felt intuition of the underlying principle.

Both model lines also illustrate a deeper aspect of lean, the spirit of challenge, facing one’s problems with creativity and courage. What we’ve learned is that rather than seeing both exercises as the consultant’s way to apply lean to whatever hapless team they’ve got their hands on, model lines and kaizen events are about striving to be better. Lean is not about pushing people to apply a process – it’s about giving them a faraway star to shoot for, getting them to build an ideal, and then see the gap with what we have and stretch themselves to figure out how to get there.

In other words, lean is about developing leaders, not followers. To develop followers, you will formulate a set methodology and get people to apply it, regardless of impact, by doing the P (Plan) and D (Do) of the PDCA. But to develop leaders, you get them first to do a kaizen to seek that frontier, that place where we perform better and then conduct a full PDCA cycle with check and act. To develop leaders, one shows them how far they can throw their javelin, and then ask them to figure out how to throw it that far every day, every hour, with every person. So both model lines and kaizen events are about making a special effort to see how good we can be if we try, so that we then figure out how to be this good every day, and then go further. Continuously.

Management has a bad case of investment loss aversion. What can I do?

Wed, 18 Apr 2012 04:00:00 GMT

Dear Gemba Coach

I’m in something of a situation and wondered whether you would have some advice. After turning around a facility with lean techniques (essentially creating small autonomous cells by using old equipment), I’ve been asked by the company to take over the corporate lean program. The company’s investment plan favors large high-speed equipment, which I’ve come to see as “monuments.” And yet I’ve been told in no uncertain terms by senior management that I can’t denigrate past investment commitments or cast doubts on those which are currently planned. I personally believe that large centralized machines are one of our biggest roadblocks to leaner processes. Yet I don’t know how to respond to my superiors. What do you suggest?

Tricky, and I’d rather not add to your troubles but you might be in a worse spot than you think. My top-of-the-head advice would be to toe the party line and live to fight another battle. This issue is not the one to make into a “cause célèbre,” it’s not worth becoming a lean martyr over. I have seen this type of battle many times, and, actually, such stories are common in Toyota’s own history of developing lean. Taiichi Ohno didn’t have a particularly easy time of getting his ideas across and he was challenged consistently. TPS evolved due to his perseverance AND Eiji Toyoda’s backing when it came to a crunch. But let’s examine the problem in more depth.

The unfortunate fact is that large companies, and to some extent societies, get stuck with the irrational choices of their leaders that keep committed to a course of action even when it’s long been proved to be a losing option. Wars are fought to the bitter end even when the outcome is certain. Companies go into bankruptcy without ever challenging their strategy. People keep making the same choices out of habit and consistency, seemingly indifferent to the outcomes (they’re not, actually, it stresses the hell out of them), and it usually takes a new team without the same commitments to change tacks. Companies are not democracies, and as long as the same management team is in place, management will place a premium on its consistency.

You Lose
From senior management’s point of view, this is like a Siberian dilemma: imagine you fall in the water in well-below freezing weather. You’ve got the choice of staying in and dying slowly of exposure, or getting out and freezing to death on the spot. For a management team it actually makes (kinda) sense to drive the company into the ground by sticking to their guns: they’ll get fired later when the results are not there, rather than get fired right away if they admit to having made a monumental misjudgment.

And so, in practical terms, I don’t have much advice to give other than not push this head-on. Try to be a wiser man than yours truly and don’t argue about solutions. The trick is in trying to attack the underlying logic of these choices, rather than the forgone conclusion. If it comes to a fight, you’re likely to lose out because the other, more powerful side simply can’t afford to let you win. This is how so many lean officers end up isolated (everyone else naturally aligns with the top dog, even if they understand the underdog’s case), bitter, and cranky. So, not much in the way of advice, but I might have a couple of gemba suggestions.

4 Suggestions
First, accept that the issue you’re facing is part of lean, not something extraneous. The first chapters of Taiichi Ohno’s seminal book on Workplace Management are: (I) “The Wise Mend Their Ways” (as in: “the wise should not hesitate to correct themselves”) (II) “If Your Are Wrong, Admit It,” (III) “Misconceptions Reduce Efficiency,” (IV) “Confirm Failures With Your Own Eyes,” (V) Misconceptions Hidden within Common Sense, (VI) The Blind Spot in Mathematical Calculations, and so on … you catch his drift. I have an old Toyota document retracing the evolution of kaizen at the Takaoka plant that states explicitly REFORM OF MANAGERS MIND as the goal of the kaizen process. So, rather than prove the rightness of your ideas, you could reframe your role as “reforming managers’ minds,” which opens a different box of questions: what does it mean? How do we do that? How do we know we’re progressing? etc.

Second, be better at the lean officer job. Again, Ohno is an excellent guide. If you follow his advice in the introduction of The Toyota Production System: “all we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing nonvalue-added waste.” And so, define your lean program as a lead-time reduction program, and things will look different. For instance, a monument may not appear as much of a problem if you’re not careful with lead-time on a VSM. But if you focus on lead-time analysis you can visualize that the lead-time for a part is the production time of that batch PLUS all the non-production time when all other batches are being produced. In this sense, a fast machine that makes all the references might be a plus in terms of production time, but the fact that all parts have to go through it also means that the non-production time for A (the time it takes to make B, C.. etc.) can be huge. So, define lead time as the time it takes to make the last A part of the batch to the first A part of the next batch. By framing the problem in this way systematically, you will eventually make your colleagues start seeing the problem with monuments, and so let them get to grips with the issue themselves. You can lead the horse to water, but you can’t make it drink. Rethink your job in terms of making them SEE the lead-time (and hence cash drain) cost of monuments.

Testing Investments
Thirdly, focus on the problem at hand. Other than their purchasing and maintenance expense, the main industrial problem posed by monuments is their inflexibility, which leads to (1) large lot size – and hence, stocks and cash drain; (2) low utilization, as small lots can’t be fitted in and since the equipment and change-over is typically difficult and takes time (3) and the larger and more complicated the machine is, the harder it is to maintain and keep running. There are no two ways around this: you need a vigorous, old-fashioned SMED program. This is also your best bet to get people to change their mind by being regularly confronted with the difficulties caused by the equipment. The trick is not to think in terms of one SMED exercise or two, but in terms of program: we’ll study one film per week. In one company I know, they have a monthly rhythm of flow-and-layout workshops, and the manufacturing engineering director always sends one or two of his engineers to participate. It’s amazing to see how quickly machine designs are changing in practice. People change what they do before they change their minds.

Fourthly, out of the previous work, formulate a test method for further investments. This is perfectly legitimate. Many investments are done on the basis of some ROI calculations and the fact that someone WANTS the machine. From the way current equipment operates, you can start formulating a one page checklist of what the next solution should fulfill to satisfy the people who use them: the plant managers. This is a neat lean trick which tends to considerably slow down irrational spending by getting people to think a bit further about what they intend doing without challenging the shape of their technical solutions – you’re not arguing against them, you’re helping them make the correct decision.

No debate that, from a lean point of view, you are absolutely correct; sometimes, doing things long enough we forget the early, basic lessons and yes, one of the keys to lean is to move from specialty shops to multi-process cells, as you’ve done. But I’m willing to bet you didn’t reach this conclusion right away. So rather than discuss conclusions, ask yourself how you can take others through the same learning. Most of my research work has been predicated on the idea of reproducing Toyota’s learning curve rather than trying to apply its current solutions. So, take it on the chin and face it: your job is precisely to change manager’s minds. Once we’ve stated it that way, we’re back in the lean world: what is the plan? How are you going to do it? How will you check? What actions will you draw from it to change your mind?

Should I Use Lean for Headcount Reduction?

Tue, 10 Apr 2012 04:00:00 GMT

Dear Gemba Coach,

My company wants to reduce its fixed costs. And as part of this my management has asked me to apply the lean techniques we’ve implemented in production to reduce headcount in engineering. I’m uneasy about doing this and wondered where I can find out more about lean in engineering departments.

Pull the andon chord! Stop the presses! Hold your horses! Think again! I realize it’s hard to ask one’s management to reconsider, but in this case it is worth expending some political capital to do so. Tell them that “reducing headcount in engineering” as an objective is going down a dangerous slope which might cost the company dearly if it’s not examined very, very carefully.

I’m not saying we should not be seeking productivity from engineering. As Orry Fiume once put it succinctly PRODUCTIVITY = WEALTH. The question, however, is to understand more fully what kind of productivity we’re seeking. In manufacturing, quite clearly, productivity is about increasing output and decreasing headcount. In lean, real productivity is even more specific since it’s about reducing headcount to produce the same number of products. As Ohno first noted (in the original Toyota Production System book), increasing output with the same number of workers doesn’t mean the sales are there, so it might be overproduction rather than productivity. And, improving efficiency by a fraction of a worker is not productivity because the person is still there. So productivity efforts in production comes down to reducing headcount while producing the same amount of products.

Engineering Value
Not so in engineering. The question to ask yourself is: what does individual productivity mean for an engineer? In product design or development, the issue is smarter solutions, not quantity of work. In other words, productivity is about shortening the lead-time to reaching the right solution. Increasing an engineer’s productivity is not about making him or her work longer or harder, but supporting her in reaching the right conclusions sooner. And back at the gemba, I’ve seen time and time again what applying cost cutting ratios to engineering departments can produce in terms of overworked engineers and terrible, terrible product decisions. As Jeff Liker points out, for a number of reasons, the moment your engineers are staffed at more than 80% capacity, your engineering department starts burning out, and your company will pay the high price of consequences on the market.

Let’s backtrack and think this through from a lean perspective. The overall aim of lean is complete customer satisfaction and complete elimination of waste. So what kind of waste are we talking about in the case of engineering? And how do we go about eliminating this kind of waste?

It’s often said that engineers cast the largest cost shadow because they have such an impact on the product, the manufacturing process and the entire supply chain. But engineers also cast the longest shadow on sales: great products sell themselves. The first and foremost aim of any company should be leading products. Indeed, Toyota didn’t transform itself from a near-bankrupt small town Japanese car company into today’s leading automotive manufacturer by simply reducing costs. It did so by designing and building cars people wanted to buy! In a saturated market, every car sold had to be taken away from one of the big 3 models—not an easy challenge. Toyota cars were not just cheaper. They were also better (no matter that the entire industry found them uglier as well, people bought them for their own reasons).

Right Product, Right Audience
The first waste we need to tackle is the waste to the customer: what are the cost of use and cost of ownership wastes that the engineering department creates through its technical choices? For instance, I was recently part of a post-mortem discussion about why a new product that was supposed to make a killing on the market turned out to be a spectacular failure. The product was a piece of a kit used by installers that work on heating systems. The new product is objectively better from both cost and performance point of views, but it’s harder to use and install, and necessitates new training for all the technicians. In this case, engineering made a cost/performance/usability trade-off that the market simply did not appreciate. Technicians preferred using their old widget, known products, rather than switch to the new one. Another way of looking at it is that the incremental gains of the new offering were not spectacular enough to compensate the switching cost. The company is doing fine and, in this instance, recovered well selling it’s old range, but in terms of engineering productivity this was a disaster as the engineering teams could have been working on something else instead.

The lean way of attacking this issue is the “chief engineer”: a heavy-weight project manager whose first role is to synthesize all known information of customer preferences, formulate a concept of the product, and translate this into engineering parameters. One classic Toyota story is that of chief engineer Yuji Yokoya being tasked with designing the new minivan model for the U.S. market. He chose to drive in every state of the U.S., northern Mexico, and Alaska to understand real customer usage conditions. Amongst the many things he learned, he realized that Americans will drive much longer distances with their kids than Japanese drivers ever would, and so the interior design of the car would be essential: "The other thing that really hit home is what I call the kid factor," Yokoya said. 'It's the kids who occupy the rear two-thirds of the vehicle. And it's the kids who are the most critical and the most appreciative of their environment" (to get the full story, read Andrea Wielgat’s great piece in Automotive Industries, March 2003). Yokoya concluded the Sienna would be defined by its convenience, flexibility, and interior comfort.

In this case, Toyota engineers also did a lot of kaizen. "The goal was not to slash costs," a manager clarified. "The goal was to achieve greatness at a great price and that meant rethinking, refining the entire development and manufacturing process."

And so the first source of engineering productivity is hitting upon the right product for the right audience. If you don’t get this right, anything else is irrelevant.

Justifying Costs
The second shadow of waste created in the engineering department is the actual cost of the product, first in terms of purchased parts and materials (about 70% of most assembled products), second in terms of capital expenditure to by the production equipment (huge fixed costs!) and third in terms of labor content itself. Think about it. Every time an engineer uses a new screw in the product, he creates a full supply chain: a supplier has to be identified, the parts have to be procured, stocked, etc.

The lean approach to this aspect of the cost shadow are engineering standards. In the lean world, each engineer is supposed to keep his or her book of knowledge with what he or she knows about technologies, processes, suppliers and so forth (for more on this check out an earlier column: engineering checklists). The French counterpart of Toyota’s chief engineer in the PSA/Toyota joint venture vehicle confessed to me that he was astonished to find that the chief engineer remembered issues with models long before his time, which is how he learned about each engineer’s responsibility to keep their own paper or computer files of validated learning: “standards” learned from empirical experience in previous development.

The most obvious place to start with this is a standard parts list for non-critical items. The idea is not to impose on engineers a rigid control stifling their creativity, but to have them justify when they want to use a part outside the list: it’s not forbidden, but it has to be explained. Reducing the number of parts used has a dramatic effect on the whole supply chain. Similarly, reducing the number of technical processes used where we can enables us to re-use old equipment and can reduce capital costs by a sizable fraction. Again, there is no point in constraining engineers, as complete customer satisfaction comes first, but to develop thoughtfulness about the impact of engineering choices on the rest of the value chain.

Milestones Into Millstones
Thirdly, a further form of waste can be seen in project issues that contribute to blowing milestones and consuming more man-hours than expected. One key target of lean development is “zero engineering changes after tooling” – as engineering changes late in the process can be incredibly wasteful in both capital (re-doing tools) and costs (engineering man-hours). Most engineering projects I come across have horrors stories about poor upstream decision-making with large consequences downstream. I’ve come to the conclusion that the best way to get your project to burn down in flames and crash is to answer any engineer’s request for an early management decision. What I’ve seen time and time again is that when an engineer asks for a spec-based management decision, he or she is usually facing a problem they don’t fully understand or don’t know how to solve. Rather than say upfront: I don’t know how to do this, they substitute to the problems solutions they are familiar with, and ask management to commit. As you can imagine, this rarely ends well and all sorts of delayed bombs go off as the project nears completion.

The lean approach is to decide as late as possible, but try to spot critical issues before drawing. The idea is to lock onto the few technical challenging problems and develop several alternatives that can be evaluated with all the stakeholders of the value chain. One way of visualizing this is to draw circles corresponding to engineering, marketing, production, purchasing, logistics, etc. and try to find which solution best (or least worst) fits within all the circles. Such “set-based concurrent engineering” is a core lean practice that is nonetheless difficult to learn as it requires enough upstream resources to develop solutions that won’t be used (in practice, that’s not quite true as many aspects of the discarded solutions are still used in the final development).

There are many more techniques in lean engineering of course (target costs, slow builds, supplier integration and so on), but the point is always the same: lean engineering is about creating a learning structure and learning events to help engineers better understand the consequences of their technical choices beyond their immediate development problems. As a result, headcount may – or may not come down. This is an outcome issue, not terribly relevant to the problem at hand: developing great products for customers at an affordable cost. In any case, whether engineering headcount increases or decreases, the objective of reducing engineering headcount to reduce fixed costs is plain silly. This is like saying that you aim to reduce yeast in baking bread because you’re using less flour. Engineering’s total percentage cost in the company’s P&L is rarely huge and, using engineers to reduce non-quality costs would be a much sounder effort.

I realize this answer might not help you much, but I can’t of any other way to go – this is a critical-to-company debate and if your management is going down that road, it’s a battle well worth fighting, as all your jobs might be at stake. I’ve witnessed first had what a poorly designed product can do to a business, and it ain’t pretty. As always, the entry point into lean is about getting agreement on the problem you’re trying to solve, rather than implementing the known solution. Hope it helps some, and don’t hesitate to continue this debate as this is an incredibly rich and sensitive topic we still have so much to learn about!