A passing inspection of several enterprise-specific PDPs suggests that they appear surprisingly similar, even across very different industries and sectors. This suggests that there is an underlying effective practice in product development. The main purpose of this section is to develop a Generic PDP, using an intentionally different representation from a traditional stage-gate graphic. We will focus on the common activities of product development, rather than on their sequence, so that the model is applicable to both stage-gated, and non-stage-gated processes.

A second purpose is to develop the reader’s skill in understanding and evaluating contemporary innovation in product development—methods such as Lean, Agile, Six Sigma, Scrum, and Voice of the Customer. Modern engineering culture is rife with methods and initiatives. Some of these methods advance propositions that can be tested for validity; others do not. Some of these methods attempt to capture intangible aspects of company culture, with varying degrees of success. Our goal is for the reader to become an educated consumer of these methods—to evaluate their utility, to understand their implications, and to apply them in the context in which they were intended, but not beyond.

From a scope perspective, many PDPs exclude the upstream process of conceiving the product (defining what is to be built). Additionally, many do not include actually operating the product but simply assume that the responsibility of the builder ends with shipment. This is true in some sectors, but often the need to consider operations and service is sufficiently great that operations through to retirement should be considered for inclusion in the PDP. In keeping with our holistic approach, we seek a PDP that is not only “birth to death” but also “lust to dust”; that is, it captures the activities from the first time a product is envisioned until the last instance is retired.

We begin with NASA (see Figure 9.1). NASA’s PDP includes some aspects of the fuzzy front end (feasibility, approval, requirements), but much of the fuzziness is hidden in the initial government furnished equipment (GFE) request. The NASA process also includes operations, because NASA is the operator of most of its products.

The upstream influences on NASA’s PDP are not captured in this PDP; where you might expect to find market analysis, NASA’s PDP notes only a feasibility question. The reality is that NASA’s market analysis combines budget decisions, public value, science goals, and industrial base questions. Notionally, NASA’s PDP proceeds linearly from feasibility to operations, [8] without iteration and without explicit reference to the technology development process.

NASA’s PDP reflects the realities of its stakeholders, and the products it builds: science ­satellites, the International Space Station, the Space Shuttle, and so on. These are predominantly low-volume, expensive space systems. They cannot be tested in situ before operations, nor can they easily be repaired. There is a high perceived cost for public failure, [9] especially for human spaceflight. Whether viewed through the lens of safety or of operations, NASA’s PDP places significant emphasis on traceability of requirements and formal review, approval and change control processes, an attribute that has been both commended (the repair process for imperfections in the Hubble Space Telescope mirror) and challenged (the Space Shuttle Columbia accident investigation board).

Helicopter Inc.’s PDP is shown in Figure 9.2, where the name of the firm has been masked. Helicopter Inc. builds helicopters for military and civilian applications. It derives a majority of revenue from government contracts, and its products compete in a highly regulated market. By comparison with NASA’s PDP, the iteration loops stand out in Figure 9.2. This is an acknowledgment that even in a NASA-like environment of aerospace development, iteration is inevitable and is not at odds with a stage-gated process. Helicopter Inc.’s process literally centers on a regulatory event, FAA certification. However, that certification is an instrument of the more important process, namely sales.

Interestingly, this diagram includes product feedback (implied from customers) but does not explicitly represent customers up front. Does Helicopter Inc. conceive products and then test them in the market, or does it gather customer needs and development grants, or a combination of both? At this level, all that can be ascertained is that input from customers and other stakeholders is implicit in the mission statement. In the Helicopter Inc. PDP, we can begin to see the four major activities that are common to nearly all complete PDPs and will form the basis of our Generic PDP: conceiving (mission statement, concept development, system-level design); designing (detailed design); implementation (fabrication, testing, and ramp-up); and operations (implicit in support and retirement, although Helicopter Inc. may not explicitly operate its products).

A third PDP, for Camera Co., is shown in Figure 9.3, where the name of the firm has been masked. Camera Co. sells camera film and cameras for amateur and professional applications. The level of competition in its markets is very different from that faced by NASA and Helicopter Inc., as is its distributed and diverse customer base. Camera Co.’s PDP explicitly shows upstream processes of strategy, voice of the customer, and R&D, all part of our generic phase of conceiving. The manufacturing development process actually precedes product development, given that Camera Co. is in a process-driven industry. This brings to the surface the idea that the implementation of products is an important driver of the overall PDP.

Although Camera Co. is often thought of as an R&D-driven company, it is interesting to note that the voice of the customer notionally precedes R&D and the technology stream. Is this an actual representation of the process, or is it an attempt to influence a company traditionally focused on technology? Manufacturing occurs in the PDP before product development. What does this suggest about the role of the architect in reducing ambiguity? Perhaps reducing ambiguity associated with manufacturing quality is a more important role than innovation in product offering, given Camera Co.’s stable, loyal customer base.

As a fourth example, the Agile PDP emphasizes iterative and incremental development. Using Agile, collaborative teams evolve requirements and solutions in a somewhat evolutionary approach. Its origins are in the rapid prototyping of software code for small and medium-sized applications. Agile emphasizes interactions among individuals who are building actual code over documentation, negotiations, and planning (Figure 9.4). Beyond software, Agile has been used as a by-word for shaking up development processes in more capital-intensive, longer-lifecycle industries. To be an educated consumer of PDPs, the reader should consider in what contexts Agile is appropriate and useful.

Based on an analysis of the four simplified product development processes, we identified many similarities and differences. Key to this discussion of PDPs is the question of whether differences are superficial or substantial: Did someone design in the differences to reflect the sectors in which the organizations operate? Similarly, we raised the question of whether the PDP represented the “actuals” of product development or a shifted image intended to motivate and transform the organization?

Here are some of the differences we observe among product development processes:

• Existence and number of phases and phase exit criteria (and degree of formality)

• Existence and number of design reviews

• Timing for committing capital

• Requirements “enforcement”

• Degree of customer input, feedback, sales, and aftermarket integration

• Degree of explicit/implicit iteration

• Amount of prototyping

• Internal testing and validation effort, importance of traceability

• Timing of supplier involvement

We would argue that several of these differences, such as the number of phases and the representation of customer input, are superficial. Which differences are important?

There are many factors that could drive differences between PDPs, such as hardware vs. software, existing product or new product, standalone vs. platform, production volume, capital intensity, and technology push vs. market pull vs. process-intensive. An informed user of PDPs judges which aspects of the process are well honed by experience, implementable, and necessary, and then applies them judiciously to the product under development.

Despite these differences among PDPs discussed above, there are enormous similarities. In fact, when engineers and architects from various backgrounds move past the superficial distinctions in their PDPs, they find a large body of common effective practice, which we codify in the Generic PDP.

Figure 9.5 provides a representation of the common activities of the Generic PDP. The emphasis is on activities of various types, and Figure 9.5 should not be read as a stage-gate approach. Studies have shown that the linear representations of the design process are deeply flawed. [10] They fail to represent iterations and feedback, presume a linear flow of time and effort across stages, and can mask a design’s immaturity when gate criteria are compromised.

The Generic PDP of Figure 9.5 is intended to be a checklist of the activities that appear in complete PDPs, loosely bundled into four groups: conceiving (determining what will be built, based primarily on market needs and technology availability); designing (rendering the information object that defines what is to be implemented); implementing (converting the design into reality); and operating (the operation of the real system to deliver value). The word “implementing” is deliberately chosen to include the coding of software, the manufacturing of hard goods, and the integration into systems. “Operations” has a sense of both supporting existing instances of the product and releasing future products. Operations ends in retirement.

Figure 9.5 also represents the architect’s system boundary. The architect often engages with a project after a small number of upstream activities, such as functional strategy decisions. If they are to be successful, the architect must be fully involved in the activities labeled “the primary domain of the architect.”

One of the roles of the architect is moving relevant downstream information into the architecting phase. This is illustrated as a reverse flow in Figure 9.5. Experience would suggest that it is easy to move constraints upstream. For example, we could argue that repairability is an important attribute of the product, therefore all parts that wear should be colored differently, quickly accessible, and easily diagnosed. Information to move upstream is plentiful, but knowing which information will meaningfully differentiate between architectures is more difficult. This is a theme that we will revisit formally in Part 4.

In order to further support comparison among product development processes, we will move outside this more traditional representation, and construct a second PDP called the Global PDP. Our intent is to construct an extended baseline against which different PDPs can be analyzed, in the interest of identifying influences upstream and downstream of the architecture.

To begin our Global PDP, we develop three nested views of architecture influences. The first level, shown in Figure 9.6, centers on the architecture of the product, which we have represented by its seven product/system attributes. Function and form are discussed extensively in Part 2. The choice of the architecture of the system is a reflection of product goals, which are in turn set to respond to market and stakeholder needs. Beyond the architecture, we have captured downstream operations from the perspective of the product operator, including operations and cost, both of which are shaped by the architectural choices made and represent a source of downstream ambiguity for the architect.

Although it runs from left to right, this generic representation represents activities, not a stage-gated process. The double-headed arrows showing the principal dependencies imply the possibility of iteration.

At this level of magnification, the architect is trying to answer the canonical W Questions also shown in Figure 9.6: why, what, how, where, when, who, and how much. Note that in this representation, form answers where, since form exists and therefore has location. One of the authors’ ­students once opined that he did not attend MIT to be brought back to the fourth grade. As with many fundamental truths, this list is sure to reappear in the search for holism in system development.

The W Questions share a common linguistic ancestor: quo from Indo-European. Many Indo-European languages use a common sound as the basis for these words. French uses “qu,” as in qui, quoi, quand, combien, ou, comment, and pourquoi. Hindi uses “k,” as in kab, kya, kyon, kitne, kisne, and kahan. The ancient Greek rhetorician Hermagoras defined seven circumstances at the heart of all issues: quis, quid, quando, ubi, cur, quem ad modum, and quibus adminiculis. The implication is that the architect who wants to have a holistic view of the product development processes must understand these attributes well.

Moving up a layer in our Global PDP (Figure 9.7), we include the activities of the design process and the implementation process, noting that each has its own instantiation of the canonical W Questions. The design process is likely to have its own set of form, notably design tools, which will shape and constrain the available system form (a draftsperson equipped with a straightedge will produce different renderings than one equipped with a French curve).

As an example of design costs influencing architecture, many automakers have a non-­recurring engineering (NRE) design cost policy for platform vehicles, whereby any vehicles occurring in the same year and produced at the same volume have to split NRE design costs evenly. This policy is not explicitly part of the technical evaluation of a concept, nor would it have been present in a stage-gate review, but it is clearly part of our Generic PDP because it will have a significant impact on the ability of a variant to deliver value.

Likewise, the implementation process will have capabilities and limitations. To the architect, this representation implies that the existing processes in implementation must be factored into the architecture of the product.

Any PDP or new design method can be critically evaluated by comparing it with the 21 questions implicit in Figure 9.7. Few methods will answer all 21 questions, so the purpose is to understand which areas a framework is strongest in. For example, the Lean movement began with studies of the Toyota Production System and evolved into principles, methods, and tools for improving manufacturing cost and quality. [11] Lean later moved upstream, asking how design decisions could enable leaner manufacturing. [12] However, Lean has also been applied directly to the design process [13], an application now far removed from the original intent.

The third nested view of our Global PDP (Figure 9.8) places the firm’s PDP in the context of its overall activities. Several firm functions are shown inside the enterprise boundary. For example, R&D and corporate functions are primarily upstream. Public relations, sales, and distribution are downstream. Human skills, information systems, and engineering tools permeate the diagram. Some of these functions are well represented as upstream or as downstream, whereas others (such as corporate strategy) may play a role in several places.

External to the firm, the diagram illustrates an incomplete list of actors and attributes that affect the enterprise. These range from the availability of capital in the market to the competition and the social impact. The corporate functions near the external interactions are meant to facilitate the interactions.

The purpose of this broadest view of the PDP is to remind the architect that understanding the contents of the PDP is not necessarily sufficient. The architect must be aware of other issues that influence the firm and context, as shown in Box 9.3 Principle of the Stress of Modern Practice.