Oct 20 2015

Principles About Principles

Abstracting underlying principles from practices is essential when you are trying to learn from the way an organization works, for the purpose of helping other organizations, engaged in different activities in different contexts. Unless you can do it, you are reduced to just copying practices without understanding what problems they were intended to address.

Unfortunately, articulating a set of principles is hard because they must be (1) understood, (2) actionable, and (3) memorable. Here are a few meta-principles on how to achieve these goals:

  1. Banish words like “thoroughly,” “rigorous,” “towering,” “powerful”, or “fully.” If the meaning is in the eye of the beholder, it doesn’t belong in a statement of principle.
  2. Express principles as an action verb followed by a single object. “Develop,” “create,” “cancel,” or “hire” are all appropriate action verbs in a statement of principle. If you have multiple objects, you need a statement of principle for each.
  3. Keep the number of principles down to a maximum of five. Otherwise, they won’t be remembered. Most Jews can’t recite the 613 commandments in the Torah; most Christians, their 1o commandments; most Americans, their bill of rights. If you want principles to be remembered, make a shorter list.

James Morgan and Jeffrey Liker have organized their book on The Toyota Product Development System around 13 principles. While their book is otherwise valuable and seems well researched, their list of principles doesn’t cut it. So, as an exercise, I tried to improve it. First, the following table shows possible ways of making each of the 13 statements crispier:

Product development principles

NumberMorgan & Liker's The gist
1Establish customer-defined value to separate value-added from wasteDesign products customers want to buy.
2Front-load the Product Development Process to Explore Thoroughly Alternative Solutions while there is a Maximum Design SpaceStart by exploring alternatives.
3Create a Leveled Development Process Flow.Follow a product development process.
4Utlize Rigorous Standardization to Reduce Variation, and Create Flexibility and Predictable Outcomes.Standardize low-level tasks.
5Develop a Chief Engineer System to Integrate Development from Start to FinishAppoint a Chief Engineer.
6Organize to Balance Functional Expertise and Cross-Functional IntegrationMatrix the organization.
7Develop Towering Technical Competence in All EngineersLet engineers be engineers.
8Fully Integrate Suppliers into the Product Development SystemInvolve suppliers.
9Build in Learning and Continuous Improvement.Apply lessons learned.
10Build a Culture to Support Excellence and Relentless ImprovementSupport continual improvement.
11Adapt Technology to Fit Your People and Processes. Put people first, technology second.
12Align your Organization through Simple, Visual CommunicationCommunicate visually.
13Use Powerful Tools for Standardization and Organizational LearningUse tools to standardize.

Now let’s see how we could reduce their numbers without losing meaning. A list of principles is a memory jogger for employees who have been lectured on the details, and have practiced them both in classroom exercises and in actual projects. Like cooking recipes for professional chefs, the statements of principles can be concise and still evoke all the relevant details.

Principles 3, 4, and 13 all are about standardization:

  • Follow a product development process
  • Standardize low-level tasks
  • Use tools to standardize

Perhaps they can be combined into a single one as follows:

  • Use tools to standardize low-level tasks in the product development process. 

Principles 7,  9 and 10 are both about learning, skills development, and improvement:

  • Let engineers be engineers.
  • Apply lessons learned.
  • Support continual improvement.

Let’s combine these into:

  • Continually improve engineering and managerial skills 

Likewise, Principles 5 and 6 are about the organization structure of product development projects:

  • Appoint a Chief Engineer.
  • Matrix the organization.

And it boils down to:

  • Appoint a Chief Engineer to lead a matrix organization. 

With these changes, the list becomes:

  1. Design products customers want to buy.
  2. Start by exploring alternatives.
  3. Use tools to standardize low-level tasks in the product development process. 
  4. Appoint a Chief Engineer to lead a matrix organization. 
  5. Continually improve engineering and managerial skills 
  6. Involve suppliers
  7. Put people first, technology second.
  8. Communicate visually.

Eight principles is still too many for everyone involved to memorize, but it is easier than 13, and they are stated in fewer words than  Morgan & Liker’s originals. Has any information been lost in the reduction? Perhaps, but not much, and remember: each statement of principle is just an invitation to drill down into the details of its meaning, as explained in the rest of Morgan & Liker’s book. Point 4 says you need a “Chief Engineer,” but not what a Chief Engineer is. You have to dig into the details for this, and it’s normal. Morgan & Liker’s original statement didn’t explain it either.

By • Management • 3 • Tags: , ,