There are two companies, Toyota and Boeing, whose recent woes are examples of "lean gone wrong". Both companies have aggressive Time-to-Market goals within their development organizations. Toyota has been the benchmark for how quickly a new automobile model can be developed. Boeing claimed they would avoid the delays seen at Airbus for their super-jumbo airliner. Their hedge on that bet was heavy use of Lean. Cycle time, flow and efficiency at the pull of the customer were broad, high-level themes. Looking deeper into the development process, however, we believe there is much value in balancing Lean with identifying and managing the rate of learning during development!

Don't Let Lean Rush Past Learning About NUDs

The development of knowledge in R&D primarily focuses on requirements and parameters that are NEW, UNIQUE and/or DIFFICULT (NUDs). Requirements and their fulfilling parameters that are not NUD's are called EASY, COMMON and OLD (ECOs). How fast a development team learns about the NUDs is where they get the most value on designing task cycle-time allocation. ECOs must be done well but we have very high % Knowledge-in-Hand for them - so they are low risk tasks. NUDs require careful, methodical development under the rigor of Critical/Key Parameter Development steps. "Leaning out" a project schedule to by-pass learning cycles on NUD parametric relationships without the discipline of Systems Engineering is a major contributor to increased recall rates. The correlation we are talking about here in Lean terms is: Low Critical/Key Parameter Learning Rates result in High Recall Rates and/or Longer Time-To-Market.

System Thinking vs. Lean Thinking

A good way to identify value in a development project is to think about your outcome as an integrated system. Outcomes such as cycle-time, functional performance and cost include how well we understand the project as a system of integrated development tasks. Things in development are often complex; they have hierarchical layers of designs that possess significant interactivity between many parameters, which in turn control the performance of the integrated system. What we are after is learning that culminates in documented knowledge about ECO and NUD parametric relationships. If true knowledge about the functions and enabling part and material characteristics is not developed - we may have a foreboding sense of what is lacking as we are pressed to get the project done. I believe that our two example companies did not develop and document the leading indicators of learning rates and resulting knowledge necessary to prevent the problems associated with the lagging indicators of product recalls and failure to meet major milestones. I suspect they did not take the time to develop integrated system knowledge and document it in a Critical/Key Parameter Data base. It is also likely they did not develop a Design Guide to illustrate how to design and build their products so that they have a high probability of being right the first time.

Decide in Advance to Use an Iterative Development Project Schedule

So is it better to design a project work flow whose goal is getting things right the second or third time? I'm not trying to be facetious, it just might be true! In that case, design a project schedule that reflects iterative development. This would be layers of Contingent Actions linked to a system of Leading Indicators that are measures of learning rates and % Knowledge-in-Hand associated with a Critical/Key Parameter database and evolving Design Guide! The Project Manager should have a short list of Preventive Actions that were absolutely essential to staying on-time, and a longer list of Contingent Actions to be triggered when a Leading Indicator warned that specific development tasks are beginning to fail to produce learning at the right rate to meet pre-determined levels of Knowledge-In-Hand at any given point in the development process.

The Bottom Line on What to Learn and How Fast to Learn It