Process Models in Design and Development

Macro-level procedural models

A number of prescriptive models provide graphical depictions and explanations of the contextual issues that need to be addressed during design, ranging from production processes through to economic considerations. Examples include the IPD model, the total design model, the concurrent engineering wheels, (Fig. 11), and the model of engineering design set in context developed by Hales and Gooch. Models of this type are discussed further by Wynn and Clarkson.

Other models in this category prescribe DDP management structures and philosophies thought to mitigate the risk of costly loop-backs, i.e., iterations between stages of the development process. One such model commonly found in companies is the stage-gate process, which emphasises the use of formal, structured reviews to ensure a design is sufficiently mature before allowing it to proceed from one stage to the next (Fig. 12). Another is the Systems Engineering Vee model (Fig. 13) which graphically emphasises decomposition of a complex design into subsystems which are developed individually, and then integrated, verified, and validated at every level of the subsystem hierarchy. Key concerns here include ensuring the proper definition, flowdown and control of requirements and interface definitions to avoid synchronisation problems and rework. A third model that has gained attention is set-based concurrent engineering (SBCE), which advocates controlled reduction of technical uncertainties through a focus on up-front learning about whether the design is feasible. The guiding principle is that choosing the right concept means fewer surprises later, reducing rework, and allowing more standardised, more efficient work later in the design process. SBCE proposes that this should be approached by developing and maintaining several workable designs for each subsystem, and gradually eliminating alternatives that are found to be infeasible or found to generate integration difficulties as the design moves forward (Fig. 14). This may be compared against the more common practice of creating one design for each subsystem and iterating until they can all work together. Authors have also considered how Lean models developed in manufacturing, involving concepts such as JIT and takt periods, can be applied to manage routine aspects of development processes. Holistic procedural models that incorporate Lean and SBCE include descriptions of the original Toyota Product Development System; the learning first product development model of Kennedy; and the LeanPPD model of Al-Ashaab et al..

The approaches discussed above focus on avoiding rework by establishing an essentially funneled structure in which the design space is progressively narrowed; decisions thought to have greatest consequence are taken earlier in the process and efforts are made to inform them as fully as possible. This overall strategy is visualised in the textbook model of Ulrich and Eppinger. In contrast, agile models prescribe structured iterative cycles in which the design is repeatedly reintegrated as it progresses through increasing levels of definition. This and other forms of iterative incremental development (IID) have been accepted in the software development context for some time and have been proposed as possible approaches to managing product development as well. They may be especially useful in contexts where customer needs or technology evolve rapidly, in cases where requirements are difficult to specify, and where the emerging solution influences the nature of the problem. Considering similar issues, Ottosson developed Dynamic Product Development (DPD), a model targeted at projects involving substantial innovation and creativity. Ottosson argues that the traditional emphasis on controlling projects by formal documentation and review leads to delayed information and reactive management. He also highlights the difficulty of long-term planning in a project involving uncertainty. To address these issues, DPD prescribes delegation of control allowing continuous managerial involvement at all levels, which is thought to facilitate real-time dynamic guidance. Furthermore, DPD aims to minimise loop-backs by allowing the concept to be adjusted continuously throughout a project, rather than freezing it early. A key consideration regarding application of dynamic, iteration-driven approaches such as IID and DPD to large projects is ensuring sufficient discipline and control of the development process.

Practice often integrates characteristics of several models from this category without following any one exactly as prescribed. Maffin et al. argue that although such models can appear too general for easy application, they can be adapted to a particular context. They propose that a set of critical factors which define the organisation and the product are influential upon the product development process, and that classifying companies according to this framework could form the basis for guiding the selection of suitable models for a company. One overall challenge with macro-level procedural models is handling their implementation in a particular company, each of which will start from a unique set of issues and existing processes. The high level of abstraction of the models arguably does not provide much guidance towards improvements to an existing situation. Implementing a change on the level described by these models, e.g., transitioning from a stage-gate product development system to an SBCE-based system, is likely to pose many practical challenges - especially in large organisations. Such models might thus be viewed as more indicative than directive of best practice; Blessing writes that criptive procedural models (including those on the meso-level) are seldom employed to direct DDP improvement.