# 14 - Improving New Product Development Process by Leveraging Lean Principles

Summary 

The classic approach to product development (Specify-Design-Build-Test-Fix paradigm) follows a linear process. Unfortunately, such a linear process flow can cause project overruns and unpredictable schedules because test feedback is delayed, teams cling to bad idea longer than they should, and problems aren’t unearthed until it’s expensive to solve them(4). 

This article proposes a knowledge-based (lean) product development as an approach to limit cost and schedule risks for new product development (also known as green field systems). 

 

Background 

The main root cause of program failure in a complex new product development context is tied to gaps in knowledge. In this context, knowledge is assimilated to the critical knowledge a company must gain to successfully develop a new product.  

Complex products/systems are characterized by emergent behavior. As the entities of a system are brought together, their interaction will cause function, behavior, performance and other intrinsic properties to emerge. Attempting to predict all anticipated and unanticipated emergent properties of a new system under development is a daring task. 

Typical linear process, i.e., “design then validate” process, promote point-based solutions. In point-based development a specific solution is selected that is deemed most feasible, then development teams validate the solution through testing in late stages. If problems are found with the design, then the development team loops back to redesign the product and fix problem they may uncover. Under a linear, point-based scenario, there is actually no way of knowing if all requirements can be achieved by the design solution picked until the design is tested. Due to the organizational commitment to the design direction, these design-test-redesign loops often extend beyond just the development and test phases. 

In the contrary, lean product development is fundamentally based on learning and discovery. Product development is more dependent on what needs to be learned than on what tasks must be completed to exit a gate. 

Project problems are predominantly caused by thinking that a solution picked early in the development process is feasible, only to discover later in the process that it is not. Selecting a design quickly feels good because work begin and progress is made early. By selecting the solution, everyone can get to work, and it feels efficient – until the design rework loops begin. The need for design reworks is often attributed to shoddy engineering in earlier phases rather than recognizing that they are inherent to the process itself. 

In lean product development, we often hear that it’s okay to fail, as long as it is early in the process. So why is failure so valuable? It is valuable because product development is a process of learning, and the greater the uncertainty in the project, the greater the need for learning. 

The main take away from this is that “you cannot plan for what you don’t know”. 

 

Options Evaluated 


Basis for knowledge-based product development is the creation of reusable knowledge through set-based design. 


Key steps required to bring a new product to market remain the creation and application of knowledge, regardless of how quickly the requirements are set. 


Set based development relies on experimental learning cycles to build knowledge over time, defining what is known and what needs to be learned. 


Knowledge based product development relies on planned learning circles to narrow solution sets, so the optimal design emerges. Learning cycles are different from redesign loops. Redesign loops happen by accident, whereas learning cycles are planned, intentional cycles to create knowledge. 


Product development inherently begins with incomplete knowledge. Critical information is often not available. The learning cycle approach provide an alternative to simply guessing and committing to a point solution. 


Learning cycle development does not require first time perfection and encourage the notion that it is better to be approximately correct and try something than to be precise but wrong. Knowledge-based product development recognize the importance of learning cycles and establish a structure methodology to create reusable knowledge (than can also be shared and built upon by subsequent projects) 


Contrary to point-based development (picking a single (point) solution early in the design process), set based development explore knowledge first, followed by a design solution later. The amount of prototyping and testing on a project should be inversely proportional to the knowledge gap that needed to be closed to resolve the design problem. 

 The Wright Brothers applied incremental learning(1)




References    

1. The SAFe lean principles: https://scaledagileframework.com/safe-lean-agile-principles/ 

2. The persistence of firefighting in product development. MIT  

3. The guide to lean enablers for managing engineering programs. MIT-INCOSE-PMI 

4. Six Myths of Product Development. Harvard Business Review (May 2012) 

Quotes  

“A bad system will beat a good person every time” (https://deming.org/a-bad-system-will-beat-a-good-person-every-time/) 

"The key to discovering design problems is testing. We have great design engineers, but what looks like a good design, even what looks like a great design, is only as good as our imaginations. Testing can reveal huge holes in our thinking.” Rob Manning, Chief Engineer at NASA/JPL

Comments

Post a Comment

Popular posts from this blog

# 11 - Model-Based Systems Engineering (MBSE)

The best way to understand the MBSE approach is to begin by understanding the alternative: what modeling partitioners call the document-based approach to engineering (and what nonpractitioners call "the way we have always done things!"). With the document-based approach, engineers manually generate some subset of the following artifacts: concept of operations (ConOps) documents, requirements specifications, requirements traceability and verification matrices, interface definition documents, systems design specifications and speciality engineering analysis such as analyses of reliability, FMEA, etc. Document-based systems engineers produce these artifacts in a form of a disjoint set of text documents, spreadsheet, diagrams, presentations (and configuration-manage them in a disjoint set of repositories). The document-based approach is expensive. More precisely, it's more expensive than it needs to be; you incur a significant percentage of total life cycle cost maintaining t...
Read more

# 10 - Principles of Dynamic Work Design

Image
Consider a well-known example of work and organizational design, Toyota’s Andon cord. In the Toyota scheme, a worker noticing such an issue is supposed to pull what’s known as the Andon cord (or push a button) to stop the production line and fix the problem. While the management literature has correctly highlighted the importance of allowing employees to stop the line, what happens after the cord is pulled might be more important. When one operator on the factory floor is struggling to complete a task in the allotted time, and so hit a yellow button, causing an alarm to sound and a light to flash. Within seconds, the line’s supervisor arrived and assisted the operator in resolving the issue that was preventing him from following the prescribed process. In less than a minute, the operator, now able to hit his target, returned to his normal routine, and the supervisor went back to other activities. A visual of this process can be seen below: What, from a work design perspective, happened...
Read more

# 12 - MOEs, MOPs and TPMs

Let's start by defining these acronyms: - MOEs: Measures Of Effectiveness - MOPs: Measures Of Performance - TPMs: Technical Performance Mesures Following a recent discussion on this topic, I've come to realize that there is a lot of confusion around these concepts, so let's try to bring some clarification! MOEs, which are stated from the acquirer (customer/user) viewpoint, are the acquirer's key indicators of achiving the needs for performance, suitability and affordability across the life cycle. The MOEs are used to validate the system at each stage of the design process and provide insight into some of the more subjective qualities desired by the acquirer that are not, or can not, be captured by hard requirements. Many of the "ilities" are used in MOEs where, for example, it may be very difficult to generate a shall statement on operability, but operability nevertheless remains an important characteristic. MOPs measure attributes considered as important to e...
Read more