Thinking for a Change

Last month, I’ve been mostly reading Thinking Beyond Lean by Michael Cusumano and Kentaro Nobeoka.

The book describes the move from single- to multi-project product development at the major automakers and the different strategies they use.

Typically, Toyota was the first company to move in this direction. At a time when other car makers were starting to adopt Toyota’s “Lean” product development model, Toyota started to think that their product development model should be improved.

Lean product development

What are some of the characteristics of “Lean” product development?

• Development is led by a “heavyweight project manager”, someone with a lot of authority, well-respected because of his technical experience and who has a clear vision of the product to built.
• Development teams are cross-functional and co-located: designers, engineers, production engineers all work together from the start and work is integrated frequently. At the end of the development process, the product is well-integrated and ready to be produced efficiently.
• People stay on a team beyond a single project, to preserve the implicit knowledge, processes and working habits.

Agilists will recognize many traits of this model. The “heavyweight” project manager is odd: imagine someone who’s the onsite customer, the coach, the manager and the technical lead all rolled into one. It’s astonishing that Toyota is able to grow such supermen.

But, Toyota started to see some drawbacks…

• because the teams wanted to make ‘their’ car the best they could possibly build, lower-end models started to get high-end features. This not only made the cars more expensive, but the distinction between models started to blur. Some of the models became competitors and “cannibalized” each other’s market.
• to reduce costs, car makers increasingly (re)use common parts. The major shift is towards common “platforms”, the base of the car. However, it was hard to coordinate the different independent projects to reuse parts and to transfer knowledge from one project to another.
• team members became more generalists, less specialists. This is great for working as a team, but there were fears that the engineers would lose their technical “edge” and would no longer be innovative.

These drawbacks are not unique to car makers. Similar problems are encountered by teams working “vertically”: each team builds one application from start to finish. The resulting systems are “silos”, completely independent applications with nothing in common.

What to do then? Move back to a “horizontal” organization where people are organized by what they do, not what they work on? Create a design group, a chassis group, an engine group…? That’s great for innovation in each area and reuse. But it’s hellishly hard to coordinate all those departments to build something that has conceptual integrity. There’s a real danger that each department will optimize their own work, at the expense of the overall result.

I’ve seen many organizations flip-flop between the two models, never satisfied with the results.

Beyond Lean

Toyota didn’t go back to the old model. They went the “Development Center” way:

• There are 4 development centers
  • 3 development centers each develop several models. The different models in a development center typically share a small number of platforms.
  • the fourth development center is responsible for research and parts that are common to all models
• Each development center is run by an experienced ex-heavyweight project manager, whose job is to coordinate the effort of the product project managers in the centre. There’s now a hierarchy of ‘chief engineers’, so that each of them only has to coordinate with a limited number of other chief engineers.
• Each development center has a simplified matrix structure:
  • there a small number of functional groups (e.g. chassis engineering, power-train engineering…)
  • product development is still done by heavyweight project managers, using a team composed of people from the different functional groups.
• For each component in a car, the appropriate level of reuse is determined:
  • Is this something that is unique to one model, something that distinguishes this model from the others? Give the model’s project manager authority.
  • Is this something that is common to the models in the development center, like the shared “platform”? Give the the development center’s manager authority.
  • Is this something that is common to everything that Toyota makes? Is this something that requires a large R&D effort (like developing a hybrid engine)? Give the authority to “Development center 4”.
• For common parts, there is a limited choice (maybe 3-5 options), from which each team can freely choose. A new option is only added if it’s clearly superior to existing options; one of the existing options is dropped, to keep the number of choices down.

This system reduces complexity while promoting reuse within an appropriate scope. They’re still able to develop products quickly but also to reduce costs by reuse. And as Toyota grows, this structure keeps the number of communication lines and people to manage within manageable bounds.

What about agile software development?

That’s great for cars, what can we learn from this? Already, some people in the agile world are looking beyond single projects, because the same advantages and disadvantages as in Lean Product development are starting to appear. What can we reuse?

• Group several small agile teams in one unit, managed by an experienced agile team leader, who can coordinate the teams and see opportunities for cooperation.
• Reuse at the right level. Take into consideration the cost of reuse; the wider the scope of reuse, the larger the cost.
• If you use standard components, provide a small list of options. Too many choices means you won’t benefit from reuse; too few choices and chances are that none is a good fit to the problem.

Oh, and if you need to plan and coordinate multiple projects and their dependencies, look up “Critical Chain“.