Dear Gemba Coach,
I’m in charge of the engineering department in our company and the CEO has asked me to start with lean. I’ve been reading the books and it seems very complicated and geared towards much bigger outfits than ours. I’m at a loss as where to start in practice – any advice?
Okay – take a deep breath and plunge in. Let’s start at the beginning: what is the problem you are trying to solve? Or more to the point, what problem does your CEO have in mind? Usually, the issue I come across is senior managers who feel they’re not getting their money’s worth out of the engineering department. These senior managers complain that projects are late, over budget, and aren’t keeping clients happy either. I’m not saying that your department is guilty of these flaws—but the fact that your CEO may feel that you are guilty matters.
Before starting any lean engineering initiative, it would be worthwhile spending some time with your CEO clarifying his or her objectives in terms of the results he or she expect from lean engineering. A great way to start is by visiting the gemba and looking at a couple of projects together. This enables you to piece together a common understanding of what’s right and what’s wrong with both the resulting product and the development process.
What are we looking for? A fundamental lean principle is that our misconceptions create unnecessary costs (waste) that can be eliminated if we can fix our wrong-headedness. Where, in engineering terms, are we creating extra costs? Firstly, there are excessive costs to customers. A product or service that does not fit the purpose the customer has in mind generates unnecessary cost of ownership for the customer. If the product breaks down, it needs to be repaired – which has a cost, both financially and in hassle terms. If the product is not easy to use, it has a cost in pain and peace of mind, and so on. The second form of excessive cost produced by our misconceptions in design and development deal with cost of the product itself: its material content, the labor hours needed to put it together, the investment in equipment and so on. The third area to monitor for excessive cost is in the engineering project itself, as unnecessary design hours will count both as man-hours costs and all the other costs associated with being late. Your fundamental challenge in applying lean to your engineering initiative is to spot what you doing wrong and then to kaizen it away.
Lean principles can help with one of the toughest challenges for people working together: recognizing one’s own misconceptions. In project work, it’s harder to distinguish between our work that delivers value to the customer from that which is waste, than it is in operations. You cannot boost engineering productivity, for example, by forcing engineers to work longer hours on more projects. Engineering productivity is linked to engineers’ capability to find the correct solution to engineering problems on their first try. It’s a completely different ball game. Adding work and pressure to engineers just makes them bog down, or go too quickly with workaround solutions that are not in fact solutions at all.
In this respect, lean practice can help in engineering, just as it does in manufacturing, by looking at your issues in a lean light:
- Are customers completely satisfied? This is always the most fundamental question to ask—yet it is never an easy one, as companies are seldom equipped to answer it. One practical way to start is invite various functions such as sales, marketing, post-sales service, and so forth, to a workshop on the performance of the new product. Solicit every point of view on how well the new release is performing, assessing it against competitor’s products, against your former products, always trying to understand it from the customer’s point of view. What benefits are they enjoying? Are there trade-offs involved?
- Is project lead-time under control? Using a simple GANTT format, plot your recent projects, tracking the start date, initially planned completion date (when engineering resources are no longer needed on the project) and actual completion date (when engineering resources are really pulled out of the project). This visual record will give an immediate feel for how well the engineering department is controlling its lead-time, as well as issues about leveling and resource planning.
- Can we reduce some project lead-times? Here a “lean” engineering project might make sense – pick one pilot project, and try to get the lead-time down by hook or by crook, starting with a value-stream map of the project and driving kaizen hard. This will not solve the engineering department’s problems, but will help you get a hands-on feel for what the problems really are. As you work at reducing reduce lead-time, all the barriers the company throws at you will be revealed as a gift, or sorts. This is like sending an advance team into an ambush to find out where the enemy positions are.
- Can we reduce cost? Reducing one project’s lead-time will surface many opportunities for cost reduction, which need to be tackled with care. The difficulty here is that for costs to be truly reduced and not pop up somewhere else (worse case, in cost of ownership at the customer’s), a real effort has to be made first to stabilize the whole engineering flow and control project lead-time.
So where to start? The temptation in engineering is to start worrying about costs before customer satisfaction. Management will push for more detailed timesheets to better understand what engineers are spending their time on and more rigorous project management with all the paraphernalia of gate reviews, steering committees, project plans and so on. Experience shows that you might succeed in the short term, but at the cost of untold damage to your engineering competence by pissing off engineers and distracting them from the fundamental issue of coming up with better products than the competition.
From the lean perspective, the place to start has to be complete customer satisfaction. Clarify who has ultimate responsibility for that. In your organizations, do the project leaders have access to customers? Do they have explicit responsibility to fulfill customer needs? Or are they expected to design to specs drawn out by marketing and signed off by management?
For lean to stick in any engineering department, everyone must accept that one physical person (the project leader) must integrate all information from customers, marketing, sales, aftermarket, etc. and come up with a technical vision of what customers really want. We’ve all been through endless horror stories where the first prototype is shown to customers and they say: “sure, all the boxes on the checklist are ticked, but that’s not what we want!” An automotive dashboard for a medium range car is not the same as for a luxury brand: it might have the same functionality, but it doesn’t feel the same.
Getting started with lean in engineering requires taking a hard look at what is expected from project leaders: do they have full responsibility for satisfying a customer or are they simply expected to design to spec? As with many lean initiatives, defining success is the starting point of deeper thinking. By “respect,” as John Shook has brilliantly pointed out in his Sloan article, we mean that every person has a right to succeed in his or her job – so success must be clearly defined.
Engineering projects are complex inasmuch as “clear” goals often hide deep trade-offs between innovation and reliable technology, between look and feel and price, between performance and customer usage, between internal competence and resources and so on. Clarifying such complex trade-offs and getting them right is almost impossible to do from the outset – this is precisely, in lean thinking, the first responsibility of the project leader.
So here’s the question to ask yourself to get started on your lean journey: are we really convinced that value is defined by the customer (as opposed to what we, internally believe)? And does the project leader has end-to-end responsibility to specify the value as defined by customers, and to deliver this value in the forms of products or services which can be build consistently at quality and cost requirements?
To discuss this and other points of views on lean, join me on The Lean Edge
