Information Flow Through Stages of Complex Engineering Design Projects: A Dynamic Network Analysis Approach
IEEE transactions on engineering management
The pattern of information flow through the network of interdependent design activities is thought to be an important determinant of engineering design process results. A previously unexplored aspect of such patterns relates to the temporal dynamics of information transfer between activities as those activities are implemented through the network of people executing the project. To address this gap, we develop a dynamic modelling method that integrates both the network of people and the network
... ple and the network of activities in the project. We then employ a large dataset collected from an industrial setting, consisting of project-related e-mails and activity records from the design and development of a renewable energy plant over the course of more than three years. Using network metrics for centrality and clustering, we make three important contributions: 1. We demonstrate a novel method for analysing information flows between activities in complex engineering design projects. 2. We show how the network of information flows in a large-scale engineering project evolved over time and how network analysis yields several managerial insights. 3. We provide a useful new representation of the engineering design process and thus support theory-building towards the evolution of information flows through systems engineering stages. Implications include guidance on how to analyse and predict information flows as well as better planning of information flows in engineering design projects according to their individual stage and activity characteristics. This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.5 engineering projects is incomplete, as it does not explicitly integrate activities and project progress. B) Process-driven perspectives on information flow in engineering design: In the process domain we find engineering design activities connected by their information dependencies and/or administrative controls. Following Sim & Duffy's ontology of generic design activities , we use the term activity to refer to the actual realisation of a particular design task. Activities then involve actions executed by a person or group to transform a set of information inputs into a set of information outputs. In the context of a design activity, information has the purpose of defining the design object, evaluating design options, and/or coordinating the design process  . Models describing the architecture of the process domain that have been used to study issues related to information flows between activities include, to name a few, the process-type Design Structure Matrix (DSM), workflow diagrams, IDEF, CPM/PERT and Petri nets (for a review of activity network-based process models see  ). All these models consider a network of activities frequently connected by information-based relationships between them. Even though process models are often used to describe and analyse actual information flows between activities, the relationship they use to connect activities is not an actual information flow. Instead, the relationship between activities tends to fall into two types. One, relationships based on known technical and managerial needs that are used to define a dependency. And two, relationships based on planned information flows, typically in the form of top-down plans or perceptions acquired from a few company experts. These two types of relationships restrict the kind of questions that can be posed to elicit the process architecture to questions such as: "What is the information dependency (if any) between activities A and B?" and "What is expected/should be the information flow between activities A and B?". However, what is really required to model actual information flows between This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.6 activities is to complement plans and known technical dependencies with the architecture of the multiple information exchanges between project participants in the context of the activities in which they participate. This distinction between a process model that is built upon planned or expected information flows, in contrast to a model of actual information flows, is important when interpreting empirical results. For example, the stated aim of Collins et al.  and Braha & Bar-Yam  is to describe and analyse the dynamics of information flows between activities; nevertheless, the information they acquire and model only describes an evolving network of information dependencies. As a consequence, their results describe planned or expected information flows, not actual information flows. Activity categories: In terms of the functions that activities perform, and building on the approach by Sosa et al.  to identify and name modular and integrative subsystems, we can identify two broad activity categories: The first category includes activities related to the engineering design of specific components, modules, or subsystems under development; these we call modular subsystem activities. The second category corresponds to activities with the objective of integrating two or more components, modules, or subsystems; these we call integrative subsystem activities. A third category, not included in the original work of Sosa  but considered important by Sim & Duffy , corresponds to activities that support, manage, and coordinate design work; for consistency we call these integrative work activities. These three categories allow classifying activities based on their overall function and with this the means for aggregated analysis of information flows of each design stage. Design process stages: Staged-based models of the design process reflect the transformation over time of a set of requirements into a detailed set of instructions to implement the design object ,  . As the design process unfolds throughout its stages, information flows between activities also evolve. This evolution through different stages can be traced to This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.