BUS606: Operations and Supply Chain Management

In the introduction to this article, a number of important characteristics of the design and development process were mentioned, in particular its iteration, novelty, and complexity. These are now revisited to consider how the models treat them and to identify implications for further research.

Iteration

The iterative nature of design and development features prominently in almost all the models reviewed. Wynn and Eckert argue that there are many perspectives on iteration and find that most approaches only emphasise a few "stereotypes". The significance for the present article is that DDP models tend to idealise complex iterative situations in a way that focuses attention on a few selected issues. For example, the spiral model developed by Evans implies that iteration helps to converge on a design, and may be desirable, while the Q-GERT model of Taylor and Moore indicates that iteration is mainly caused when tasks reveal problems, and thus is undesirable. Because each stereotype suggests a quite different perspective on the causes, effects, and behaviours of iteration, it is important to understand the iterative characteristics of a real-world situation and select a model that focuses on the appropriate stereotype(s). A model that is poorly matched to the iterative situation may not yield much insight and may draw the focus of attention away from pertinent issues. Selecting an appropriate model may be difficult if the modeller is not aware of the range of approaches that are available; the present article may be informative in this regard. Opportunities for further work on this topic include developing methods to assess the iterative characteristics of real-world situations to match them to appropriate models, and developing hybrid models that blend or nest the stereotypes.

Considering analytical and MS/OR approaches in particular, we believe that some quite common assumptions regarding iteration deserve further attention. First, many methods require a modeller to specify activities, decision points, or dependencies that can cause iteration to be triggered. The choice of which triggers to include in a model will be influenced by the practicalities of modelling, and iteration may often appear in other places, or may appear to be outside the level of detail of the model. One area for further work is to develop methods to assess how iteration is triggered and which triggers are important to incorporate in a process model. As well as indicating where iteration may occur, many approaches incorporate a mathematical model of when it is triggered. This is most commonly stochastic, but the constant and independent probabilities often used may not be a good model of how iteration occurs in practice. One contributing factor is that choices are available regarding how to manage iterations. For example, companies may accept some problems so they can release a design on time, with the intention to work out those issues during production or after the design is in service. Exploring the most effective ways to model iteration initiation is, therefore, another area for further work. Finally, as noted earlier, some simulation schemes can suffer from logical issues related to iteration, such as deadlock, if a model is not carefully formulated. For all these reasons, it remains difficult to adequately represent iterations in practice especially in unstructured or nonroutine processes. We suggest that there are opportunities for further work on how DDP models can be used to support practice despite their limited fidelity, for instance, using them in ways that recognise their limitations.

Novelty

Another challenge faced when developing models of the DDP is that every project and design situation is in some respect unique, or at least unique to its participants. Different models deal with this challenge in different ways. Abstract, procedural, and MS/OR models describe the DDP in a generic way expected to be valid in many different contexts. However, as noted earlier, this may present difficulties for practical application. Many analytical models are based on the principle that although each DDP is different, there is an underlying process architecture within each company that remains essentially constant from one product to the next, and that may be modelled. Thus, a process model based on past experience may help to derive insights for future DDPs in similar contexts. However, it seems not entirely clear how process similarity should be understood or assessed, nor what its implications for modelling and analysis might be. In practice, processes change over time, for instance as new technologies become available and become integrated into the designs and as new software tools are rolled out. In the development of complex products such as aircraft, this change can occur on a timescale that is significant relative to the project timescale. Because of this, further research to explore how models can be most effective taking into account an evolving process might prove to be useful. One possibility is to map DDP models or model fragments to characteristics of the situations in which they are valid, such that a process can be progressively instantiated as design decisions are made and/or can be adapted to a particular context.

Complexity

We have already discussed insights into DDP complexity revealed through several models. These include insights on the interrelationships between the design process, the properties of the emerging design, and the context into which that design will be delivered; insights on the information flows that emerge between participants as they coordinate their response to inevitable unplanned events; insights on the impact of structural complexity in task networks on design iteration and convergence; and insights on the dynamic complexity caused by multiple intertwined influence loops as participants guide a project towards desirable outcomes. As well as generating insights, models can help to manage DDP complexity by presenting selected issues in a simplified way. At the same time, when working with a model, attention is focused on the issues that are emphasised. Knowledge of the full range of models available is important not only to select an appropriate approach for a given situation as suggested in Sect. 6.3.1, but also to ensure awareness of how different models might influence perceptions of the process.

Another issue relating to model complexity is that a modeller must choose the scope and granularity of their representation. This inevitably involves simplifications, and the consequences may be especially important to consider when seeking insights from mathematical or computational models. For example, Kerley et al. argue that a DDP simulation model should not be viewed as an attempt to create a "perfect simulacrum", but as a tool for "providing enough information to the stakeholders to facilitate debate and support them in making evidence-based judgements about the feasibility and consequences of implementing the suggested changes". A related consideration is whether results and insights from numerical analysis can be expected to converge as the level of detail in the model is increased, or as the severity of simplifying assumptions is reduced. For example, would a Task DSM clustering algorithm yield the same insights if the same process were modelled at different levels of abstraction, or by different people? Future work to develop more systematic guidelines to make appropriate choices while modelling might prove useful to practitioners.

A third set of issues relating to complexity in the context of analytical approaches concerns the practical constraints on constructing large models. Some authors have proposed that these problems of scale can be addressed by developing process libraries from which case-specific models can be more quickly assembled. This appears to be a promising approach for situations which can be decomposed hierarchically and in which the subprocess contents are relatively routine. For example, the process library in the ADePT method was found to account for more than 90% of the activities required in application case studies. It should be noted that this work focused on the construction sector, not engineering design. Appropriate software support might also help to manage large and complex models, for instance by generating filtered views customised to the needs of each user. However, these specialised tools are often not available in practice.