BUS606: Operations and Supply Chain Management

Abstract models of the DDP on the macro-level focus on clarifying its overall form and how design processes interact with their context. To recap, abstract models neither prescribe best practices as procedural models do nor provide concrete approaches for modelling a specific situation, as analytical models do.

One example of a model in this category is the capability maturity model for development or CMMI-DEV, which among other elements describes the system of process areas that exist in a generic development project or program (Table 2). Large organisations and their development projects may involve all these process areas, while smaller companies and projects may deal with many process areas in an ad-hoc way or not at all. The process areas can be categorised into core processes that directly create value, support processes, and management/control processes. Engineering design is mainly represented within 1 of the 22 process areas, although as a core value-adding process, it interacts strongly with the rest of the system. For instance, change in customer requirements influences the technical solution process, which in turn creates work for configuration management processes. This descriptive model, as summarised in Table 2, is helpful in the context of this article to indicate the relationship between the design process and the rest of a development project.

CMMI-DEV process area	Purpose of processes in the area (summarised)
Causal analysis and resolution	Identify causes of selected outcomes and act to improve process performance
Configuration management	Establish/maintain configuration integrity of work products
Decision analysis and resolution	Analyse identified alternatives against established criteria to make decisions
Integrated project mgmt.	Define/execute integrated project processes tailored from standard processes
Measurement and analysis	Develop/sustain measurement capability for management information needs
Organisational process defn.	Establish/maintain process assets, and rules and guidelines for teams
Organisational process focus	Plan/implement/deploy process improvements considering current needs.
Org. performance mgmt.	Manage organisation performance proactively to meet business objectives
Org. process performance	Establish/maintain a quantitative approach to process performance.
Organisational training	Develop people, so they can perform their roles effectively and efficiently
Product integration	Ensure that the product is assembled from its components and behaves properly
Project monitoring and control	Understand project progress, so corrective actions can be taken when needed
Project planning	Establish and maintain plans that define project activities
Process and product quality	Objectively manage process and product compliance to standard
Quantitative project mgmt.	Achieve established quality and process performance objectives
Requirements development	Elicit, analyse and establish customer, product and component requirements
Requirements management	Manage requirements and ensure alignment with plans and work products
Risk management	Identify potential problems before they occur and mitigate adverse impacts
Supplier agreement mgmt.	Manage the acquisition of products and services from suppliers
Technical solution	Select, design, and implement solutions to requirements
Validation	Demonstrate that product's intended use is fulfilled in intended environment
Verification	Ensure that selected work products meet their specified requirements

The diversity of models discussed thus far in the article makes it clear that many perspectives on the processes (and related systems) in an organisation are possible. The Zachman Framework was one of the first models to provide a comprehensive picture of the possible perspectives. This kind of model is now known as an architecture framework. The Zachman Framework classifies perspectives on a two-dimensional grid. The first dimension indicates the question being asked by a model's users: What? How? Where? Who? When? and Why? The second dimension indicates the stakeholder asking the question: Planner, Owner, Designer, Builder, and Subcontractor. Zachman proposes that every modelling approach may be categorised as a combination of one question and one stakeholder, and that the alternative perspectives are "additive and complementary". A more recent architecture framework is the US Department of Defense Architecture Framework (DoDAF). Architecture frameworks consider that different modelling approaches allow different views of a DDP system to be created. The different views must be integrated in the minds of their users. Browning argues for a centralised comprehensive DDP model from which customised views may be extracted according to each user's needs, recognising the practical difficulties of implementing such a system and keeping the information synchronised and up-to-date.

Other authors present more conceptual models. For example, the Integrated Product Engineering Model (iPeM) discussed by Albers and Braun combines a problem-solving cycle with a stage-based view of product development. This is framed as the so-called operation system which transforms systems of objectives and requirements into systems of objects. The model is said to contain "the relevant elements to derive situation-specific PDP models" while "taking into account the dynamism and the uniqueness of product development processes". Another example in this category is the Autogenetic Design Theory (ADT) of Vajna et al., which views design and development as a trial-and-error procedure guided by feedback due to situated selection pressures. This is said to occur at every level of product development. Vajna et al. present this as an evolutionary process, in particular as a cycle of mutation to generate alternatives, evaluation of alternatives, and selection according to situated pressures, followed by replication and recombination of successful candidates. They write that levels of complexity in the design increase as the evolutionary process proceeds, drawing an analogy to the outcomes of evolution by natural selection. Wynn et al. and Maier et al. develop a cybernetic model of the DDP, arguing that the process participants interact through consideration of an ecosystem of models, including representations of the emerging design as well as DDP models. The models are said to mediate dynamic interactions among individual process participants and their design contexts. This perspective is used to identify eight factors that influence the effectiveness of models and modelling in guiding a DDP towards desired outcomes in the presence of uncertainty, disturbance, and situated decisions. Siyam et al. present a Value Cycle Model which presents complex product development as a network of roles related to the process of defining, creating, and delivering value with respect to stakeholders involved in product development. This model is used to position tools and approaches that may be used to improve the DDP from a value perspective. Pich et al. present a formal conceptual model that characterises projects according to information adequacy with a view to choosing an appropriate management strategy. They consider three such strategies, which correspond to models discussed earlier in this article. First, instructionism involves programming activities and perhaps contingency plans in detail, as per PERT/GERT and similar approaches. Pich et al. argue that this is suitable only if information about the situation and about the effect of actions is deemed adequate. In situations with many unknown unknowns, a strategy involving learning (i.e., deliberately iterative, experimental approaches such as DPD, Agile, and IID) and/or selectionism (i.e., pursuing multiple alternatives in parallel until there is enough information to choose between them, as per SBCE) may be more effective.

In summary, abstract models like these can be useful to frame analyses of the DDP on the macro-level. However, they are rather conceptual in nature and may require significant insight and interpretation to apply.