How important is it to consider differences in roles between our current project manager and a chief engineer?

Dear Gemba Coach,

Management wants us to start lean in product development, but refuses to consider the difference in roles between our current project manager and a chief engineer – how important is that?

Ahem. This like saying “we really like this wheel concept but can’t we do without the axles?” Within Toyota’s lean world, the whole Toyota Product Development approach is what chief engineers do – it can’t be understood without the chief engineer. So I’m not sure what value applying lean tools to your development activities will have without getting to grips with that fundamental problem.

Bear with me as I try to explain the issue:

1. A successful product is the result of engineering choices. A product evolves in the three dimensional space of (i) performance – the functionalities promised to the customers, (ii) quality – our ability to hold these promises and deliver these functionalities over time and (iii) the total cost of use of the product to the customer, including acquisition price, maintenance cost, disposal cost, general hassle, and so on.
2. Good project management is the result of decision making. At each milestone of the project, a number of decisions must be made on the “blocking” items to get the project move from one milestone to the next in time, within budget and … hopefully with a good product at the end.

One might think that choices and decisions are the same thing, but they aren’t. Decisions are the specific points at which choices are implemented. For instance I might choose to stop eating meat and become a vegetarian, a lifestyle choice, but then I will have to make endless decisions to support that choice, in restaurants, socially when invited by friends, or when I feel really tired and what would perk me up is a good, juicy steak (come on, just one?).

Decisions must be made precisely when choices are hard to keep up.

For any product or service, several key choices must be made, such as:

• Which customers the product or service must convince?
• Which competing product should we convince these customers to switch from?
• Which performances really matter to these customers? What objectives?
• Which technologies will deliver these performances?
• Which features will remain the same as with the existing product, and which features will change?
• Which product architecture to deliver these features?
• Which specific features require more value invested in?
• Which specific features need value engineering to achieve target cost safely?
• What target cost?
• What rough milestones for the project
• How many prototypes are we considering?
• At which level of volume do we pay back development cost?
• What is the target distribution system? What marketing positioning?

And so on. The hard truth remain that only 30% to 50% of new product introductions are considered successes after the fact so that the good sense of these choices and the quality of execution are the only two factors that even the odds.

Only one physical person can make such choices with any kind of consistency and judgment. Any committee or management team will end up with compromises and a bland product. The Chief Engineer is there to fight for his or her targeted customers and the best product the company can come up with.

And these choices will be resisted by the entire enterprise – decisions will be asked by the functional department heads to water down the vision, to make it easier (or safer) to design, to produce, to source. This tension is absolutely legitimate and key to succeeding at quality of execution and, in the end, coming up with a product that delivers, maybe not all what the Chief Engineer had dreamed, but still better than competing products or alternative technologies.

The point I’m trying to make is that decisions come after deep choices have been made. Executive decisions are about the “how?”, or the “what?”, but rarely the why?

I vividly remember one new product project led by a perfect project manager (who also wore very sharp suits). The project was on time and on budget, phase gates were passed with nary an issue and… the product was a disaster on the market that crippled the company until a new, meatier, more valuable version was designed by an engineer all levels of management disliked for his abrasiveness, long-windedness, and general disregard of other’s opinions. Still, he saved the product.

Project managers are there to babysit a project: they don’t have a major stake in the product, they’re caretakers of the process.

With a project manager system, choices are being made across various departments, such as marketing coming up with target market and product specifications, finance with cost targets, senior management with design opinions and so on. These choices are rarely stated explicitly, they appear throughout the project as “decisions.”

When the project manager gets stuck (mostly when the “gate” approaches), the project manager goes to senior leaders, who’re never short of an opinion on… everything? As Google’s former CEO has described it, the HIPPO (Highest Paid Person’s Opinion) is about the worse way to make a product decision.

In one other new product disaster I can think of, the CEO came back from a trade show having the decided the leading product of the brand had to be relooked. Decision. Then the project team was set up, the project manager selected a design agency and the agency came up with various designs requiring a shift of cladding from metal to plastic (huh?). This major change passed the design gate because the CEO really liked the new look. Then it reached the next gate where manufacturing engineering stated it simply couldn’t be done without much, much more engineering work. This went back and forth, with many decisions taken until, at some point the Marketing manager chipped in with: “but where is the cost down?” Customers, he said, only want one thing: better prices. After all the work, effort and so many decisions, this simple statement killed the project.

At the LPPDE conference in Reading, Takao Sakai made a remarkable (and rare) presentation about inside knowledge of Toyota’s product development system:

He quotes Eiji Toyoda: “Shusa [Chief Engineer] is product president and company’s president’s role is to help Shusa.”

Powerful concept. All the various tools of lean product and process development are essentially learning activities to make this vision happen by creating spaces for the Chief Engineer to interact with the department heads and the design teams in order to learn to make her product vision a reality without taking risks with quality. Mostly these tools are about understanding two key engineering issues:

1. Where to keep the standard, replicate the knowledge and find the way to apply it in the specific situation (no simple task in many practical cases)
2. When to break the standard and create the set of options that will be explored concurrently across all functions, product design, process design, manufacturing, supply chain, etc. in order to come up with something new that works.

Let’s face it, taking on the tools of LPPD without starting with the Chief Engineer function simply doesn’t make much sense – ritual observation of activities are not very likely to result in better products that win over customers. Which doesn’t stop many companies doing exactly that, of course.