Dear Gemba Coach,
My boss has hired a consultant to do value engineering, who has us looking for design opportunities to reduce the costs of components and materials – is that it?
Yes and no. See, value is function over cost so any cost reduction opportunity is value engineering, but not if it’s at the expense of function. The first step to value engineering is to accept – and I mean, really accept, with the heart, not just the mind – that these are two mysteries: the mystery of function (what do customers really do with it and what do they like about it?) and the mystery of cost (what is really costly about this in the end?). The fundamental premise of value engineering is that these two steps will remain mysterious, so we need to keep exploring them all the time.
Value engineering is not about the designs themselves. It’s about the mind of the engineer. The engineer is indeed seeking opportunities to either enhance performance or reduce costs, but because this is engineering, she can be doing so in a variety of ways. There are essentially two paths to value engineering:
- The low road: List cost reduction opportunities and hit them one after the other until you reach the cost target, and hope for the best.
- The high road: Understand more deeply what customers do, think and feel about the product, and how it’s made, to find value-enhancing opportunities.
Think of the CD player in your car. When designing the next generation product, should we:
- Have the CD player as a paying option for customers who specifically want one?
- Include CD players in all cars because it makes the manufacturing cost go down overall?
- Get rid of CD players altogether because everyone now uses file sharing?
A key finding of cognitive psychology is that our minds run on two systems, one fast, one slow:
- System 1: The fast response from our habitual and emotional brain equipment – it doesn’t think, it reacts. We experience these ideas as intuitions and they feel overwhelmingly correct, which is a side-effect of immediacy. Like breathing.
- System 2: Slow, rational responses from our neocortex. It requires deliberate effort to think things through, which means manipulating mental objects until the situation is clear and new insights appear.
System 1 is transactional by nature. It’s all about what we want and need and can trade. You want this? Fine, give me that. The mind reacts automatically to a request by finding the obvious thing it needs to respond without thinking. It’s a reaction of memory: what you know and how you feel about it.
System 2 is adaptive. It seeks the best response to a complex, ambiguous situation. It actually enjoys cracking the problem in a smart, new way. But it needs to be deliberately triggered because it’s cognitively costly and requires effort.
Obviously, the general level of skills matter as does the understanding of the situation. An expert engineer who knows her product inside out and has been working in that market for a long time is likely to have smart system 1 reactions – her habitual, intuitive reactions are likely to be valid … unless something changes. In which case, the very same confidence will work against her, which is what happens to experts: they’re right about tomorrow and can completely miss the obvious for next year.
When you look at an engineer, imagine you see into their mind. Imagine you can see which system is activated. Activate system 1, and they’ll act impulsively and habitually. They’ll follow their first impression and be very emotional and defensive about their intuitions. That doesn’t make them wrong, but they can make spectacular, avoidable mistakes without ever realizing – or admitting it. And be very persuasive about it.
If you activate system 2, however, they’ll think more carefully about the situation and try to figure it out. They’ll be slower, more tentative, prone to check things and recalculate. They’ll also be less confident about their opinions and less likely to express them loudly. They’ll probably sound rambling or diffident. They are thinking.
As you can imagine, in engineering, this can lead to very different kind of solutions.
Sleeping Robot
I remember a value engineering project where engineers were looking at the cost of high-volume assembly in a high-cost country. Guess what? They justified on paper the investment for a robot to assemble the part.
As we returned time and time again to that gemba, it seemed to me the robot was always stopped – wouldn’t get up in the morning. Of course, no one tracked it very carefully and explained it was absolutely the right decision. More low path.
Finally, one day, the area manager did track the OEE of the robots and it was indeed dismally low. When he looked into it, he found that the robot could only assemble the parts if they were exactly to spec. In the same cost reduction drive, purchasing had relocated the parts to a Chinese supplier (a fashionable move at the time), with quite a bit of variation on the components. Consequently, the robot did not know how to assemble these parts and … stopped.
The punch line is that the design of the final product tolerated loose tolerance on these parts – they didn’t need to be that precise, functionally. Sourcing in China was the right value engineering decision, the robot was the wrong one. But neither decision had been made like this, people had just followed the “obvious” way to deal with the problem: system 1. And of course, system 1 being tightly linked to affect, you can imagine the tone of the ensuing discussions.
The deeper problem here is how to trigger system 2 in the minds of engineers when discussing value engineering possibilities.
The high path of system 2 is triggered by focusing attention on the wider outcomes, not just the immediate transaction. We need to get engineers away from: “How do I get the consultants off my back? What do I need to give to keep them happy? How can I do so with minimal effort? How can I close this as fast as possible?,” to: “What’s the right thing to do? What would customers really enjoy? What would they think about this change? How do we make a change that enriches the product, not leaves it poorer?”
Which is where the lean tradition comes in handy. We actually know how to do this.
First, take the engineers to customers’ gembas. Rather than focus on the existing list of features and ask them to find ways to reduce costs, organize go-and-see sessions to see firsthand how customers:
- Use the product or service in real life – to do what in what circumstances?
- Think about it when they use it – just ask them to think aloud.
- Feel about it – how attached they are to using this particular product or service and why, what do they find emotionally compelling about it – what emotions does the product or service evoke.
Second, don’t disconnect value engineering from value analysis, which is solving engineering problems in products already in production. Go to the customer service department, review customer complaints, and look into which complaints we are currently solving, why, and how.
Third, set up an obeya where technologies are displayed and how they come together to create functions and encourage open-ended discussion on technology evolutions. Ask engineers how they would solve an existing problem with a new tech rather than try to find new issues that could be solved with existing technology if we optimize it. Create an environment for high-path discussions. And, oh, listen to the interns; they grew up in the future.
Start with Minds
Yes, value engineering is a lot about reducing costs. But beware. The typical value engineering questions of:
- Can we combine parts to fit one function?
- Can we find a cheaper and better material than the one we currently use?
- Is there a way to automate or outsource labor for this assembly?
- Can we standardize components to benefit from volume economies?
Are all likely to trigger the transactional low road and deliver sub-par solutions you will all regret later (and that will be very hard to argue against once they’re put on the table.)
To do this properly, start with minds: what’s in customers’ minds, what’s in engineers’ minds, what’s in suppliers’ minds, and ask about how to better mesh our technologies so that the product doesn’t generate so much waste for both customers and producers. Start by thinking about the product’s assets (what customers like about them) and how they can be enhanced, rather than by a quick shortlist of parts to “attack.” You’ll end up in a very different place.
