Effective Product Development

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 fu...

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...

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...

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...

I'd like to discuss a little bit why we use methods and models. Throughout the lifecycle, methods and models are used for multiple purposes. Some of the types of decisions that we might make are defining the problem or opportunity space, deciding on concept architectures, and making trade off decisions. So what is trade off analysis? Well, it's a decision making activity, and it's for the purpose of selecting from alternative solutions on the basis of the benefit to the overall system and its stakeholders. So examples of the types of methods are decision matrix methods that let you compare alternatives in a fairly simple way, trade study method, which adds a bit more formality to this, and then trade space exploration methods, which allows you to explore the whole solution space. Trade studies for us is looking at how we can balance cost, performance, schedule, and even risk. It's gathering all that information and looking at those alternatives, and then coming up with ...