Design Management - Process and Information Issues

WDK Publications
WDKl
WDK 2a WDK 2b WDK 3 WDK 4a

Principles of Engineering Design Bibliography of Design Science Bibliography of Design Science (continued) Terminology of the Science of Design Engineering in Six languages Case Examples (1-3) Case Examples (4-6) Case Examples (7-9) Design Methodology: Proceedings ICED 81, Rome Teaching Engineering: Proceedings ICED 81, Rome Conference Results - ICED 81, Rome J Dietrych about Engineering Design Tactics in Engineering Design (Readings) Proceedings ICED 83, Copenhagen Management of Engineering Design (Readings) Proceedings ICED 85, Hamburg Proceedings ICED 87, Boston Methodical Design of Machine Elements (Readings) Reliability of Technical Systems Proceedings ICED 88, Budapest EVAD - Evaluation and Decision in Design (Readings) Proceedings ICED 89, Harrogate Proceedings ICED 90, Dubrovnik Proceedings ICED 91, Zurich Engineering Design Education (Readings) Proceedings ICED 93, The Hague Proceedings ICED 95, Prague EDC - Engineering Design and Creativity, Workshop Proceedings Proceedings ICED 97, Tampere Proceedings ICED 99, Munich Manual for Design Engineering (Selected preprint) Proceedings ICED 01, Glasgow

WDK4b
WDK 4c WDK 5 WDK 6 WDK 7 WDK 8 WDK 9 WDK 10 WDK 11 WDK 12 WDK 13 WDK 14 WDK 15 WDK 16 WDK 17 WDK 18 WDK 19 WDK 20 WDK 21 WDK 22 WDK 23 WDK 24 WDK 25 WDK 26 WDK 27 WDK 28

13th International Conference on Engineering Design - ICED 01

Design Management - Process and Information Issues

21-23 August 2001 Scottish Exhibition and Conference Centre, Glasgow, UK

Organized by The Institution of Mechanical Engineers (IMechE) Sponsored by BAE SYSTEMS Co-sponsored by The Institute of Engineering Designers The American Society of Mechanical Engineering (ASME)

Published by Professional Engineering Publishing Limited for The Institution of Mechanical Engineers, Bury St Edmunds and London, UK.

First Published 2001 This publication is copyright under the Berne Convention and the International Copyright Convention. AH rights reserved. Apart from any fair dealing for the purpose of private study, research, criticism or review, as permitted under the Copyright, Designs and Patents Act, 1988, no part may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, electrical, chemical, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners. Unlicensed multiple copying of the contents of this publication is illegal. Inquiries should be addressed to: The Publishing Editor, Professional Engineering Publishing Limited, Northgate Avenue, Bury St Edmunds, Suffolk, IP32 6BW, UK. Fax: +44 (0) 1284 705271.

2001 The Institution of Mechanical Engineers, unless otherwise stated.

ISBN 1 86058 355 5

A CIP catalogue record for this book is available from the British Library. Printed by The Cromwell Press, Trowbridge, Wiltshire, UK

The Publishers are not responsible for any statement made in this publication. Data, discussion, and conclusions developed by authors are for information only and are not intended for use without independent substantiating investigation on the part of potential users. Opinions expressed are those of the Author and are not necessarily those of the Institution of Mechanical Engineers or its Publishers.

Conference Organizing Team

Steve Culley, Bath University, UK Alex Duffy, Strathclyde University, UK Chris McMahon, Bristol University, UK Ken Wallace, Cambridge University, UK

Scientific Advisory Board

A Chakrabarti, University of Cambridge, UK R Anderl, Technische Universitat Darmstadt, Germany R Andrade, Universidade Federal do Rio de Janiero, Brasil M M Andreasen, Technical University of Denmark, Denmark E K Antonsson, Caltech, USA P Badke-Schaub, Universitat Bamberg, Germany A H Basson, University of Stellenbosch, South Africa H Birkhofer, Technische Universitat Darmstadt, Germany L T M Blessing, University of Cambridge, UK G Blount, Coventry University, UK A Breiing, Swiss Federal Institute of Technology, Switzerland S Burgess, University of Bristol, UK J Busby, Cranfield University, UK M Cantamessa, Politecnico di Torino, Italy H H C M Christiaans, Delft University of Technology, The Netherlands P J Clarkson, University of Cambridge, UK J Deans, University of Auckland, New Zealand P Deasley, Cranfield University, UK W E Eder, Royal Military College of Canada, Canada K Ehrlenspiel, Technische Universitat Munchen, German) S D Eppinger, Massachusetts Institute of Technology, USA D G Feldmann, Technische Universitat HamburgHarburg, Germany S Finger, Carnegie Mellon University, USA P Frise, University of Windsor, Canada I Gibson, National University of Ireland, Ireland H Grabowski, Universitat Karlsruhe, Germany G Green, University of Galsgow, UK K-H Grote, Otto-von-Guericke-Universitat Magdeburg, Germany P H K Hansen, Aalborg University, Denmark I Horvath, Delft University of Technology, The Netherlands St Hosnedl, University of West Bohemia in Pilsen, Czech Republic V Hubka, Heurista, Switzerland B Ion, University of Strathclyde, UK D Jiati, 720 Lab, Bejing University of Aeronautics and Astronautics, Peoples' Republic of China N Juster, University of Strathclyde, B Katalinic, TU Vienna, Austria T Kiriyama, Stanford University, USA S S Kok, Nanyang Technological University, Singapore L Leifer, Stanford Centre for Design Research, USA B Lewis, University of Melbourne, Australia Yn Li, Sichuan University, Peoples' of Republic China Uo Lindemann, Technische Universitat Munchen, Germany M L Maher, University of Sydney, Australia M Mantyla, Helsinki University of Technology, Finland D Marjanovic, University of Zagreb, Croatia H Meerkamm, Universitat Erlangen-Nurnberg, Germany M Meier, ETH-Zurich, Switzerland F Mistree, Georgia Institute of Technology, USA M Norell, Royal Institute of Technology, Sweden M Ognjanovic, University of Belgrade, Yugoslavia K Otto, Massachusetts Institute of Technology, USA U Pighini, University of Rome 'La Sapienza', Italy D F Radcliffe, The University of Queensland, Australia Y Reich, Tel Aviv University, Israel A Riitahuhta, Tampere University of Technology, Finland R Rohatynski, Technical University of Zielona Gora, Poland N Roozenburg, Delft University of Technology, The Netherlands E Rovida, Politecnico di Milano, Italy A Samuel, University of Melbourne, Australia J W Schregenberger, ETH Honggerberg, Switzerland P Sen, University of Newcastle, UK M Simon, Sheffield Hallam University, UK J Simmons, Heriot-Watt University, UK L Stauffer, University of Idaho, USA K G Swift, University of Hull, UK O Tegel, TU Berlin, Germany G Thompson, UMIST, UK D L Thurston, University of Illinois at UrbanaChampaign, USA M Tollenaere, ENS Genie Industriel, France T Tomiyama, The University of Tokyo, Japan D G Ullman, Oregon State University, USA S Vajna, Otto-von-Guericke-Universitat Magdeburg, Germany C Weber, Universitat des Saarlandes, Germany M P Weiss, TECHN1ON, Israel P M Wognum, University of Twente, The Netherlands K Wood, The University of Texas, USA M M F Yuen, Hong Kong University of Science and Technology, Peoples' Republic of China

Industrial Advisory Board

R Bodington, BAE Systems Advanced Technology Centre, UK N Brenchley, Forward Industries, UK M Brown, BAE Systems Research Centre, UK P Burnell, EPSRC, UK I Chatting, GKN Westland Aerospace, UK A Court, Portacel, UK P Fearis, The Generics Group Limited, UK P Ferreirinha, MIRAKON, Switzerland D Foxley, Royal Academy of Engineering, UK E Frankenberger, Heidelberger Druckmaschinen AG, Germany N Grant, BAE Systems Operations, UK J Gunther, Hilti AG, Liechtenstein C Hales, Triodyne Inc., USA L Hein, Technical University of Denmark, Denmark N Kohlhase, LEWA Herbert Ott GmbH + Co., Germany D Knott, Rolls-Royce plc, UK I Liddell, Buro Happold, UK P W Liddell, Lockheed/BAe, USA K Mashford, Interfacing Limited, UK I Milbum, Nissan European Technology Centre Limited, UK J Mudway, TRW ASG Lucas Aerospace, UK Y Neuvo, Nokia Group, Finland F O'Donnell, Scottish Enterprise Lanarkshire, UK C Pearce, INBIS Group plc, UK B Prasad, CERA Institute, USA D Rimmer, Pilkington Optronics Limited, Denbighshire, UK D Robson, Scottish Enterprise, UK M Shears, Ove Arup Partnership, UK L Styger, STYLES RPD, UK I Yates, UK

Contents
Preface

xii

Knowledge and Information Management Information Management

Improving access to design solution spaces using visualization and data reduction techniques P M Langdon and A Chakrabarti Supporting non-structured graphical information in integrated design team E Blanco and M Gardoni Automatic composition of XML documents to express design information needs A Dong, S Song, J-L Wu, and A M Agogino Design communication using a variation of the design structure matrix J C Lockledge and F A Salustri Multi - a tool and a method to support collaborative functional design S Menand and M Tollenaere Information flow in engineering companies - problems and their causes C M Eckert, P J Clarkson, and M K Stacey Design case relevance in quantity dimension space for case-based design aid T Murakami, J Shimamura, and N Nakajima A web-based information tool for application engineering J Schmidt and D G Feldmann

3
3

11

19

27

35

43

51

59 67
67

Knowledge Representation and Management

An agent environment to support co-ordination between design actors P Girard and C Merlo Developing a support system for novice designers in industry S Ahmed and K M Wallace Using domain knowledge to support design requirements elicitation M J Darlington, S J Culley, and S Potter Towards pragmatic approaches for knowledge management in engineering theory and industrial applications K-D Thoben, F Weber, and M Wunram Effective abstraction of engineering knowledge for KBE implementation P Bermell-Garcia, I-S Fan, G Li, R Porter, and D Butter

75

83

91

99

New techniques for design knowledge exploration - a comparison of three data grouping approaches P C Matthews, P M Langdon, and K M Wallace Computer-supported systematic design and knowledge in the early design phase E Frankenberger DEKAS - an evolutionary case-based reasoning system to protection scheme design G West, S Strachan, J McDonald, A H B Duffy, J Farrell, and B Gwyn Knowledge for product configuration K Hadj Hamou, E Caillaud, J Lamothe, and M Aldanondo An operational model for design processes M Y Ivashkov and C W A M van Overveld

107

115

123

131

139 147
147

Classifications and Taxonomies

A common language for engineering design practice and research A Samuel, J Weir, and W Lewis Using situation theory to model information flow in design Z Wu and A H B Duffy Shape matching and clustering S Lim, A H B Duffy, and B S Lee The product develoment process ontology creating a learning research community P K Hansen, A Mabogunje, O Eris, and L Leifer The application of an automatic document classification system to aid the organizers of ICED 2001 A Lowe, C A McMahon, T Shah, and S J Culley Analysis and classification methodology for objectifications in collective design processes A Verbeck and K Lauche

155

163

171

179

187

Design Reuse
Modularity in support of design for re-use J S Smith and A H B Duffy Capturing and classifying information in undergraduate design team projects P A Rodgers Incorporating incentives into design documentation tools T Lloyd and L Leifer

195
195

203

211

Scaling-up domain knowledge representation in the development of knowledge intensive CAD for proactive design for manufacture X-T Yan, J Borg, and F Rehman Re-using knowledge - why, what, and where J S Smith and A H B Duffy Documentation and evaluation in early stages of the product development process L Schwankl Mapping experience - learning from experience of peers through sociotechnical interactions T Liang, D G Bell, and L J Leifer Transfer of experience in critical design situations P Badke-Schaub, J Stempfle, and S Wallmeier

219

227

235

243

251

Organization and Management of Design Project Management

Product development models for shorter lead times and more rational processes - its effects on the work situation for project managers and project group A Zika-Viktorsson and J Pilemalm A multi-project management approach for increased planning process F Marie and J-C Bocquet Applying conceptual design methods to engineering management P Hughes, C Burvill, and R Hughes Finding and implementing best practices for design research activities M Gardoni and C Frank

261

261

269

277

285

Project Strategy and Management

Late point differentiation analysis for configurable products T A Lehtonen, A O Riitahuhta, and J M Malvisalo On the design of services R Andrade Functional products create new demands on product development organizations O Brannstrom, B-O Elstrom, and G Thompson How missions determine the characteristics of product development methodologies B Bender, B Bender, and L T M Blessing

293
293

299

305

313

Planning and Workflow Management

Visualization techniques to assist design process planning P J Clarkson, A F Melo, and C M Eckert A product and process model supporting main and sub-supplier collaboration B Fagerstrom and H Johannesson Identifying and analysing changes in a dynamic company S Suistoranta Design process planning using a state-action model A F Melo and P J Clarkson

321
321

329

337

345 353
353

Concurrent Engineering and Integrated Product Development

Integrated new product development - a case-based approach R Valkenburg and J Buijs Material instrumentation for inter-trade co-operation - a source of innovation: application in the domain of painting and varnish finishes N Stoeltzlen, D Millet, and A Aoussat Geometry users from a process perspective F Fuxin Concurrent design of product and package- extending the concept of IPD C Bramklev, R Bjarnemo, and G Jonson

361

369

377 385
385

Distributed Design/Supply Chain Integration

A framework for distributed conceptual design A Schueller and A H Basson A system for co-ordinating concurrent engineering R I Whitfield, G Coates, A H B Duffy, and W Hills Distributed product development - a case study in inter-organizational SME business networks J Pilemalm, S Gullander, P Norling, and A Ohrvall-Ronnback Organizational design - a tool for evaluating alternative extended enterprise structures A McKay and A de Pennington

393

401

409 417
417

Design Teams
Cultural issues in aerospace engineering design teams K H Payne and P J Deasley Supporting the teamwork by new means of the information technology A M Kunz, S Muller, T Kennel, K Lauche, and K Mbiti The importance of informal networks to effective design management N J Brookes, P Smart, and F Lettice

425

433

Managing uncertainty in design communication M K Stacey and C M Eckert Managing the integration between design, research, and production in the automobile industry H V de Medina and R M Naveiro Researching the thinking process in design teams - an analysis of team communciation J Stempfle and P Badke-Schaub Towards a science of engineering design teams A Mabogunje, K Carrizosa, S Sheppard, and L Leifer Dimensions of communication in design C M Eckert and M K Stacey A statistical study of how differing levels of diversity affect the performance of design teams A G Carrillo

441

449

457

465

473

481

Management of the Clarification Phase

Requirements engineering - laying the foundations for successful design G A Thomson The organization and management of engineering tenders G Barr, J H Sims Williams, S C Burgess, and P J Clarkson Modification of a methodological design tool for the developing country scenario - a case study in product definition K M Donaldson and S D Sheppard An approach for structuring design specifications for complex systems by optimization C Grante, M Williander, P Krus, and J-O Palmberg An engineering approach for matching technology to product applications J B Larsen, S P Magleby, and L L Howell
489

497

505

513

521

Performance Evaluation
Financing innovation in co-operation projects P Link and S Spiroudis Performance management at design activity level F J O'Donnell and A H B Duffy A metrics methodology developed in co-operation with industry M W Lindley, M Muranami, and D G Ullman Improvement of engineering processes S Vajna, D Freisleben, and M Schabacker

529
529

537

545

553

Process performance measurement support - a critical analysis M K D Haffey and A H B Duffy

561

Risk and Uncertainty Management

The methodology for system integrity in design J K Raine, D Pons, and K Whybrew Change prediction for product redesign P J Clarkson, C Simons, and C M Eckert Survey of current UK practice in managing technical design risk R Crossland, C A McMahon, and J H Sims Williams Development of an 'IDEA' for safety D Vassalos, I Oestvik, and D Konovessis How mutual misconceptions between designers and operators cause accidents in hazardous installations J S Busby, R E Hibberd, P W H Chung, B P Das, and E J Hughes A project view of the handling of uncertainties in complex product development organizations R Olsson Decision-making - how to avoid dysfunctions? How to analyse dysfunctions? How to improve an organization by its dysfunctions? J Stal-le Cardinal, M Mekhilef, and J-C Bocquet Preliminary design of a risk management decision tool J M Feland

569
569 577 585 593

601

609

617 625

Authors' Index

633

Preface
This is one of four books resulting from the contributions to the 13th International Conference on Engineering Design (ICED 01). The conference was held in August 2001 in the Scottish Exhibition and Conference Centre located on the River Clyde in Glasgow - the ideal place to hold the first ICED of the now millennium. The ICED conference series was initiated by Workshop Dcsign-Konstruktion (WDK) in 1981 with the first conference in Rome. From the very beginning, the aim of ICED was to offer a platform for the discussion of new trends, developments, and research findings in the areas of new product development, design support techniques, design processes, design science, and design education. The conferences have been held in eleven different countries and have become one of the most pre-eminent conferences in the field of Engineering Design, with the last two conferences being held in Tampere, Finland, in 1997 and in Munich, Germany, in 1999. Both these conferences attracted well over 500 delegates from both academic institutions and industrial organizations. Nearly all the leading authorities in the field of Engineering Design attend to report their latest findings and exchange current ideas with colleagues. All conferences have focussed on the process of planning, developing and designing technical systems and products. ICED covers all aspects and disciplines of engineering design, from general product development and innovation to feature-based geometric reasoning and design for later life-phases. As engineering design is a process to which many disciplines are contributing, an additional emphasis has been placed on design management, organization, teams, and individuals. Over the years ICED conferences have become the forum for establishing, maintaining, and improving contacts and co-operation between researchers and engineers from countries all over the world. It is self evident that the engineering design process has changed to meet the challenges of globalization, increasing international competition, and the need for sustainable development. Equally the performance and quality of engineering products have improved in many aspects, time to market, performance, reliability, reduced environmental impact, etc. If the improvements are to be maintained, the elements that contribute to the product development process must continue to be studied and enhanced. Improvements in the engineering design and its process have been supported by theories and methods developed by research groups around the world. The research is beginning to mature into an overall and consistent understanding of engineering design as will be seen in the pages of the four books. However the results are still fragmented and there is a need to unify the findings, and to ensure that these findings are transferred into industry. The theme chosen for ICED 01 was Unifying Engineering Design - Building a Partnership between Research and Industry. The organizing team received 664 Abstracts and this resulted in some 325 full papers. All papers are eight pages in length and went through a double blind review of the abstracts and a double review of the full papers. The books consist of contribution papers from some 35 countries.

xiii

DESIGN MANAGEMENT This book consists of some 13 topics and really has an overarching theme of the management of the process and the information that supports the process. It covers knowledge and information management at all levels and the organization and management issues associated with the design activity itself. Books in the series Book 1 Design Book 2 Design Book 3 Design Book 4 Design

Research Management Methods Applications

A large number of people and organizations have helped with the conference. The organizing team would like to express their thanks to all who have contributed to the content and execution of ICED01 in whatever way.

Steve Culley

Alex Duffy

Chris McMahon

Ken Wallace

Knowledge and Information Management

Including sub-sections:
Information Management Knowledge Representation and Management Classifications and Taxonomies Design Reuse

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW. AUGUST 21-23, 2001

IMPROVING ACCESS TO DESIGN SOLUTION SPACES USING VISUALIZATION AND DATA REDUCTION TECHNIQUES
P M Langdon and A Chakrabarti

Keywords: Visualisation, clustering, synthesis, design information management, information analysis, classification and retrieval

Introduction

Designers only explore a few solutions in depth at the conceptual stage [1]. Despite this, evidence suggests that a thorough exploration of a solution space is more likely to lead to designs of higher quality [2]. FuncSION [3] is a computational tool that synthesises a wide range of solutions to a class of mechanical design problems involving transmission and transformation of mechanical forces and motions that are specified as inputs and outputs. It uses a set of primary functional elements along with combination rules to create an exhaustive set of solutions in terms of their topological and spatial configurations. Previous research has demonstrated FuncSION's potential for generating novel solution ideas that designers had not thought of. However, it was found that the large number of ideas generated could not be meaningfully explored, while their representation proved too abstract to visualise. Effective support for conceptual design should help designers obtain a thorough overview of the solution space, as well as a detailed understanding of its individual solutions. However, the greater the variety and number of solutions to be explored, the less likely it is that a detailed understanding of the potential of all individual solutions will be achieved. The DESYN software described in this paper encapsulates FuncSION with a Graphic User Interfacce (GUI) [4]. The overall aim of this work is to test the extent to which DESYN is capable of assisting designers in their exploration of large solution spaces such that an overview of the entire space is obtained while at the same time facilitating understanding of the individual solutions contained in it.

Background

A paper presented at ICED99 [4] described a scheme adopted in order to solve the above problems. The problem of exploring large combinatorial spaces is an unresolved issue in computer aided synthesis research, which is further complicated by the difficulty in displaying large volume of information [5]. The approach adopted was a novel method of clustering the solution configurations to reduce the space of solutions that the designer needs to consider in order to get an overview of the entire space of solutions [6]. This was done by presenting the designers with representative solutions that were by-products of the clustering process. In this way, large numbers of solutions can be summarised by a small number of cluster exemplars of prototypes.

ICED 01 - C586/223

A number of previous approaches have adopted rule-based heuristics for the generation of solution compositions in an unconstrained space (See, for example, Campbell et al, 1999)[7] [8][9]. However, the approach adopted here assumes exhaustive generation of solutions in a partially constrained space with the use of clustering as a data reduction and representation. Because of this, all solutions are, in principle, available to the designer through interaction with the systems GUI. In the authors' earlier paper, some initial validation of the cluster algorithm was reported focussing on whether the system's clusterings of solutions were intuitive and whether the clusterings suggested by the system correspond to designers' own partition of the solution space. Initial experiments examined a number of DESYN clusterings of two sets of 20 solutions resulting from a synthis using 0-5 elements per solution from a choice of < 4 elements. Figure 1 is an example diagram of the outputs of the same clustering algorithm for a smaller 6 solution set synthesised using the elements wedge, cam and lever mechanisms. Clustering was based on a Euclidian distance metric operating on a count of features in each solution from a feature set of all possible feature pairs.

Figure 1. Cluster table for 2 to 5 clusterings of a 6 solutions for a problem using Wedge, Cam and Lever elements.

The arrows indicate the solutions that leave the 3 cluster solution to form new clusters. On the left of the diagram the six possible solutions output by the synthesiser are enumerated. The vertical columns show increasing number of clusters in the solution set. The cells show the cluster membership for each solution. Each cluster has a representative solution that is denoted by circling. Finally, the box in the corner of cells shows the average distance of the representative to all the other members of the cluster. The right hand diagram shows a Venn type representation of the 3,4 and 5 cluster solutions. Solution sets for the larger 5 element problems were presented to 5 subjects as printed words with illustrative diagrams. Subjects were required to form groupings of the 20 solutions that corresponded to their judgements of those that seemed to them to be similar on the basis of their engineering experience. The subject's groupings were scored for the percentage similarity of groupings with the DESYN clusterings of the same set. This was to test whether designers found the system's clustering of solutions intuitive, and whether the clustering suggested by the designers correspond to their own partition of the solution space. This clustering was based on an element-pair feature count (focusing on the type of interfaces possible as design elements in combination), and provided an average commonality, between designer's clustering and the

ICED 01 - C586/223

method's, of 74% in contrast to 55% commonality yielded by comparison with a random clustering. However, this evaluation was carried out using only the topology, rather than the 3-D configurations of the solutions. Evaluation of the approach is further extended in this paper (see section 3.2) using: (1) 3-D configurations displayed by the system as displays of force and motion solution chains; (2) Graphic representations of the clustered solution space. The goal of this evaluation is to find whether or not this clustering-based technique improves a designer's overview of the entire solution space, and whether the software facilities assist their understanding of the solution space.

Current Developments

Current developments include further development of the GUI and visualisation support, and further evaluation of DESYN, which are described below.

3.1 User interface development

The visualisation utilises a 2D 'star' representation of clusters (Figure 2), and a pseudo-3D display of a component chain schematic (Figure 3) that we have developed to improve access to the functional synthesis software. The former is used to aid visualisation of the spatial relationships between the component interfaces, while the latter is intended to aid the understanding of the grouping of functional solutions by similarity [10, 11].

Figure 2. The DESYN Graphic User Interface Clustering Tool

In conjunction with this, a 3D visualisation for displaying an overview of the solution space and the spatial layouts of selected solutions resulting from the synthesis is under development.

ICED 01 - C586/223

When implemented, this will display a 3D schematic representation of individual solution chains with a symbolic convention used to indicate locations and directions of force and rotation. Elements will represented by shaded cylinders and interfaces between elements are represented by spheres.

Figure 3. The Pseudo 3D visualisation interface

The orientation, direction, and sense of forces will be represented by arrow triplets. The Nominal direction of rotation or force was represented by 2D sprites. Elements will be fitted into the mechanism boundaries by an algorithm that distributes the element lengths evenly into the available space. Figure 3 represents a schematic of a concept that has four elements, nominally oriented as shown by the arrows, such that an input rotation is taken by the first (shaft-like) element, and passed on to the second (crank-like) element, which passes the resulting translation via two tie rod-like elements to the output point. The 3D representation and facilities for manipulation of individual solutions are intended to provide designers a more detailed understanding of the individual solutions than that provided by the more abstract text-based representation.

3.2 Evaluation
Each of two groups of designers (Gl and G2) were asked to individually inspect the solutions set generated by FuncSION in two conditions by using the softwares Graphic User Interface. The unstructured group were presented with a list representation of the solution set and the structured group received the representation in the form of 2D "sun-and-planet" graphic representing clusters calculated by the algorithm, the representative central member and the average distance of cluster members from that medoid (Figure 2). The task required the designers to select, using the representation available to them, a set of solutions to the specified problem that were both different from each other and formed a set completely representative of all solutions. In the unstructured condition the designers were given a text field on the interface into which they could fetch groups of solution on demand. This was managed by the use of a button that simply obtained five solutions from the total set and placed them at the bottom of the list on

1CED 01 - C586/223

the screen. No indication of the total number of solutions was given and the solutions were not presented in any ordering linked to their functional structure. Hence, the designers were allowed to select as few or as many solutions as they liked. The task further required that the designers selected individual solutions form the list (left, Figure 4) that they felt met the criteria. This was made on a point-and-click basis and the resulting set stored in a further text field (right, Figure 4).

Figure 4. The list representation experimental group interface.

In the structured condition the designers performed the same task but interacted with a 2D cluster representation of the solutions set. Dwelling the cursor on a central representative "sun" member of a cluster lead to a list of the cluster solution members appearing in the upper right text field. Dwelling on the numbered "planet" members highlighted the location of the solution in the list.

Figure 5. The list representation experimental group interface.

Again, the task further required that the designers select individual solutions form the list (top right, Figure 5) that they felt met the criteria. This was made on a point-and-click basis by clicking on the member "planets" and the resulting set stored in a further text field (bottom right, Figure 5). In both conditions the designers were able to delete members of their selected set at will.

3.3 Data analysis technique

Results in our previous study [4] suggested that the clustering solution for small problems had some psychological validity as a grouping of the solution space correlated highly with designers groupings. Therefore, in the present case, if a solution chosen by a designer belonged to a cluster generated by the computer, then it was assumed that the designer had an overview of at least that cluster. If there was a better match between the computed clusters

ICED 01 - C586/223

and solutions listed by the designers in the list condition (Gl) rather than with those listed by the designers in the clustered condition (G2), then it could be concluded that designers had a better overview of the solution space using clustering than without. This would indicate that a designer could miss innovative solutions when they did not use the data reduction technique. For the list of concepts written by each designer, solution clusters were generated using the clustering algorithm, taking the size of the list as the number of clusters. A comparison was then made between the list of concepts of the designer with the solution clusters generated by the algorithm to find how many solutions from the designer's list belong to distinct computed clusters. The proportion of the solution space covered by the designer, taken as a measure of the overview obtained by him, was then calculated as the ratio of the number of clusters 'covered' by the designer to the total number of clusters. An average proportion of solution space covered by designers in each group was then calculated by dividing the total of the ratios (for all the designers in the group) by the number of designers.

Results

List Condition (G1) Subject

Clustered Condition (G2) Ratio Subject

No.
3 3 7
13

Matched

No.
3 3 7
11

Matched

Ratio

S1 S2 S3
Total Average

1 1 6 8

1/3 1/3 6/7

21/32

S4 S5 S6
Total Average

1 1 5 9

1/3 1/3 5/7

21/29

4.3

2.7

0.51

3.7

3.0

0.46

Table 1. Cluster commonality data for the list condition and clustered conditions

The results obtained are tabulated in Table 1. Very little difference was obtained between the numbers of clusters sampled by the designers in each experimental group and this was reflected by the ratios of computed and designer sampled clusters (Table 1.). Although no inferential statistics were calculated due to the small size of the sample (n = 3 in each group) it is evident from the table that many of the designers in both groups chose a small set of three solutions that sampled only one cluster of the computed solutions.

Discussion

There was no evidence that the designers sampled the solution space more effectively using the 2D cluster visualisation GUI when measured in terms of the similarity between the clusters they sampled and the complete optimal clusterings that had been previously found to correspond to designers' intuitive groupings. The principal result suggests that the use of an assistive aid combining data reduction technique with graphic visualisation did not lead to a more complete sampling of the solution space for the highly constrained synthesis problems

ICED 01 - C586/223

tested in these experiments. However, it was observed that the time to complete the task was significantly shorter (about 50%) in the clustered condition. Although this was not measured accurately, it may suggest that the list condition designers required more time to gain an overview of the space than the designers for whom the solution space was spatially laid out. The overwhelmingly popular solution represented three sub-mechanisms that give key two element combinations that re-occur. These included mechanisms that allowed orthogonal changes in force direction, such as lever to lever; lever to cam; or lever to screw links. The reports collected from these designers suggested that the criteria applied was simplicity of solutions, ignoring repetitions of sub-mechanisms and spatially translating force to force elements such as tie-rods. The effect of prompting the designers for more solutions in these cases led to the choice of variants on these mechanisms with tie-rods added to circumvent possible spatial constraints. The limitations of the evaluation lie in the small number of designers sampled and the use of a single problem. In addition the previous evaluation [2] had established a commonality of 75% between the software-clustered groups and the designers intuitions as indicated by a paperbased solution-sorting task. In addition, the clustering method was based on a feature based on a count of pairs of solution elements. Other features of the solution chain could be used for clustering to further test the effectiveness of the clustering approach. It was also clear from the designers performance that a more realistic task would involve a realistic design task carried out over a longer period. In addition to this, the pseudo 3D visualisation software was not integrated into the DESYN interface such that visualisation of individual solution chains was possible during the trial. It was evident that such a visualisation tool would have assisted the designers understanding of the individual solutions. Work is currently underway with a larger group of designers, sampling a wider range of problems over a range of sizes of mechanisms and difficulties of task.

Conclusions and further work

A software system for assisting the visualisation of alternative solutions to mechanical design problems involving transmission and transformation of mechanical forces and motions was successfully implemented. This utilised a clustering algorithm for the purpose of data reduction and visualisation of a large solution space. An empirical evaluation of this system examined whether the designers' sampling of the known solution space was effectively assisted by an element-pair clustering represented in a 2D display of clusters, in conjunction with a pseudo-3D visualisation technique. There was no evidence for any improvement in the number of clusters sampled when the interface provided a list of solutions as opposed to a 2D cluster membership diagram, though a substantial improvement in time to complete the task was noted. Two strategies were observed in the designers tested. The predominant strategy involved listing 'elemental' submechanisms that were capable of orthogonal changes in force direction. These designers ignored repetitions of sequences or complex combinations as well as elements providing linear or parallel force transformations. These second strategy group appeared to list solution sets that were clearly distinctive sequences, because of simplicity or unique element combinations. The small number of designers sampled does not enable generalisation to designers at large as the results may reflect individual strategies. It is also possible that designers' choices were

ICED 01 - C586/223

affected by the lack of a genuine engineering task in the short trials. Firmer conclusions will be facilitated by the collection of further data using an enhanced assistive interface and more realistic and rigorous design tasks.

7
[1]

References
Chakrabarti, A. and Wolf, B., Reasoning with Shapes: Some Observations from a Case Study", Proc. 1995 ASME Design Engineering Technical Conferences: (9th Intl. Conf. on DTM), DE-Vol. 83, Vol.2, pp-315-322, 1995. Fricke, G., Experimental investigation of individual processes in engineering design, Research in Design Thinking, (N.Cross, K. Doorst and N. Roozenburg eds.) Delft University Press, pp 105-109, 1992. Chakrabarti A., and Bligh, T.P. "An Approach to Functional Synthesis of Design Concepts: Theory, Application, and Emerging Research Issues", AI in Engineering Design, Analysis and Manufacturing, Vol. 10, No. 4, pp-313-331, 1996. Langdon, P., and Chakrabarti A. "Browsing a large solution space in breadth and depth", A. 12th International Conference on Engineering Design (ICED 99), Munich, Germany, v3 p. 1865-1868, 1999. Johnson,B., & Shneiderman, B. "Tree-maps: A space-filling approach to the visualisation of hierarchical information structures". Proc. IEEE Visualization'91. IEEE, Piscataway, NJ, 284-291, 1991. Kaufman, L. & Rousseeuw, P.J., Finding Groups in Data. Wiley Series in Probability and Mathematical Statistics. John Wiley and Sons, Inc., 1990. Campbell, M.I. ,Cagan, J., Kotovsky, K., A-Design: An Agent-Based approach to conceptual design in a dynamic environment. Research in Engineering Design, Vol. 11, pp 172-192, 1999. Finger, S., and Rinderle. J.R., A transformational approach to mechanical design using a bond-graph grammer. In Design Theory and Methodology, DTM 89, vDE Vol. 17. pp 107-115, 1989. Bracewell, R.H., Sharpe, J.E.E. Functional descriptions used in computer support for qualitative scheme generation - Schemebuilder. AI EDAM Journal - Special Issue: Representing Functionality in Design 10(4): p. 333-346, (1996).

[2]

[3]

[4]

[5]

[6] [7]

[8]

[9]

[10] Robertson G.G., Card S.K., Mackinlay, J.D., Information visualization using 3D interactive animation. Communications of the ACM, Apr 1993, Vol.36, No.4, pp.57-71, 1993. [11] Mackinlay, J.D., Rao.R, Card, S.K., An Organic user interface for searching citation links. Human Factors in Computing Systems (CHI) Conference Proceedings, Vol.1, pp.67-73, ACM, New York, NY, USA. 1995.

Corresponding author's name: Dr. Patrick Langdon Engineering Design Centre, Cambridge University Engineering Department, Trumpington Street, Cambridge CB2 1PZ, UK, Tel: +44 1223 766961 Fax: 444 1223 332662, E-mail: pml24@eng.cam.ac.uk, URL: http://www-edc.eng.cam.ac.uk/people/pml24.html Cambridge Engineering Design Centre 2001

10

ICED 01 - C586/223

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

SUPPORTING NON-STRUCTURED GRAPHICAL INFORMATION IN INTEGRATED DESIGN TEAM

E Blanco and M Gardoni

Keywords: design information, design understanding, knowledge management

hypermedia

and

multimedia,

The aim of this paper is to focus on the use of draft and sketches in the group understanding within Integrated-Team. We suggest specifications of a communication tool that supports and structures numerical drafting and treatment for capitalisation of those drafts connected to messages.

Evolution of Engineering Information Requirements

Traditionally, engineering activities are performed in a sequential order. Over the last ten years, companies have tended to apply the Concurrent Engineering approach (CE) in order to drastically reduce the time-to-market of their products [1]. This approach is opposed to the sequential engineering approach because they have respectively two fundamental ways of working. In sequential engineering approach, the work starts at the reception of the results of the early stage when CE is based on information exchanges. Those exchanges are mainly performed verbally face-to-face or on the phone. Unfortunately, this information is therefore poorly controlled. This term "control" can be characterised in terms of four criteria [2] : Information Structuring: it relies on a formal conceptual scheme which organise information at appropriate places. The evaluation criteria are the easyness to organise information in an intuitive and logical way and to be able to manage information at separate locations. Information Sharing: ability of "pushing" information. Information Access: ability to "pull" information. Information Capitalisation: ability to store and process information for later re-use, we assume that it must comply with the cycle of 'company knowledge capitalisation', i.e. locate, memorise, use information and update information.

Taking into account these new requirements, we characterise the type of information exchanged in Integrated Team. We will focus here on information Structuration model. In order to meet the rigour needs of companies without going down on a too fine level of granularity, we choose an instructional design of the information significance. We then consider that the construction of a sentence corresponds to combine instructions formulated in term of variables, which provide a sense to the statement. Exchanged information is then an abstracted entity, a theoretical object which consists of [3]:

ICED 01 - C586/418

11

Linguistic components which build the significance of information starting from instructions. Rhetoric components which bring a sense to information by addition of contextual information.

Figure 1. Instructional design of the information significance

Thanks to this instructional design of the information significance, we characterise different types of information [2] : Structured-Information (SI), linguistic and rhetoric components of the 57 are generally imposed. Semi-Structured-Information (SSI), linguistic components of the SSI are little formalised and rhetoric components could be parsimonious. Non-Structured-Information (NSI), the NSI are very little formalised and the rhetoric components can be very light if they ensure a sufficient degree of relevance for the comprehension of information by the receiver. The MICA approach [4] (a specific interactive messaging system) has been developed and experimented in order to harness of NSI and to capitalise on relevant information exchanges. Also a Groupware tool called MICA, was created through an Intranet. It has been implemented and put into operation in an engineering team of twenty people in May 1998. Some return on experience has already shown improvement of the efficiency of the Integrated Team. Nevertheless, this kind of capitalisation from linguistic data is limited because of the graphical NSI lack. Sketching takes a large place in the group understanding of technical problems. Goel [5] also argues that freehand sketches facilitate creative and explorative work at the early stage of design, because they are ambiguous semantically and syntactically dense. Sketches could be considered as Graphical Non Structured Information (GNSI). They are at the same time models of the product and communication vectors. MICA only takes into account linguistic data but does not take care of GNSI management. This is today one of the actual limit of the MICA approach and more generally of Knowledge Management systems [6]. Generally Groupware solutions for interactive sketching have to be improved.

GNSI in collaborative design

In order to analyse the role of GNSI in collaborative design we have carried out a design experiment [7]. This experiment was based upon the distributed design model [8]. Three roles

12

ICED 01 - C586/418

were represented, the functional, structural and machining roles. A camera has recorded the whole progress of the design. The work began with the requirement list supplied by the client a few days before the experiment. It took six hours to implement the detailed drafts of each part of the product in order to manufacture it.

2.1 Sketches as Intermediary Objects of the design process

In order to observe and analyse the design processes, we suggest to start with the Intermediary Objects (IO) which, circulating at any given moment between the actors of the process, can be seen as resulting from their design work but also as supporting and highlighting it [9], [10]. In modelling the future product they also act as communication vectors between the product designers. These two aspects are so indissociable in the reality of the process that we cannot isolate one from the other without deforming their nature. Because of this hybrid nature, intermediary objects are "analysers", making it possible to describe the actual design process. All along the design task, the object can not exist without the actor and the actor without the object. What we observe, see and feel in the design process, are objects being constructed, talked about, manipulated, interpreted, transformed, etc. Considered separately, the objects and actors are merely capacities for action. They are inert, static, mere?? "possibilities". It is the action, or rather the inter-action in which they are engaged that endows them with force, meaning and effective reality. The intermediary objects are also mediating objects: first of all, because of the mode of representation they use. This leads to a particular way of objectivising the idea or the intention by inscribing it in a specific organised matter. Thus, for example, a drawing is not simply a faithful representation of the mental idea or specifications : it is a translation, i.e. a realisation and a transformation which has been carried out according to its specific constraints (including those of the material used, which may vary depending on whether it is on paper or on screen) and its own rules and conventions. Lastly, the way in which the Intermediary Objects play the role of mediators in the design process is a result of their being representations. IO contents are mainly of cognitive nature : it results from the use of acquired knowledge by the actors in their various fields. They also signal the gradual production of new knowledge about the product as it is being designed. However, these contents are only of a cognitive nature in a situation of action, oriented by a given project and made up by the choices of the actors, the multiple negotiations that they are involved in, and the compromises and decisions that result from these. Therefore the cognitive contents cannot be isolated from the context of action

2.2 Classification of sketches in the collaborative process

The role of the objects like sketches in collaborative design process are quite complex. Ferguson [11] identifies three kinds of sketches : thinking, talking, prescriptive. The situation of the experiment that we have carried out emphases on the second category of sketches. The collaborative activity involved many talking sketches. On the contrary, studies based on single designer activity mainly point out the thinking role of sketches [12]. In the experiment, we had characterised sketches [6] through an axis from open object that are able to support negotiation, to closed objects that mainly support prescriptions. We observed

ICED 01 - C586/418

13

that the same object can support different status even if some objects get materials and cognitive characteristics that enhance opened or closed use. The situation of action as well as the material and cognitive properties of the IO influence the status. In the protocol, for example, we observed that the same sketch can be realised by an actor for his own use and after a few minutes be proposed to the others for evaluation. It moves from a private status (it is a thinking sketch), to a public one in the centre of the table. The existence of the private area is very important for the designer. This area is the thinking area that allows to explore ideas without judgement from the other. In a second step, the actor presents the meaning of his sketch and the other actors can assess the solution in their own point of view. This object then acts as a conjecture of solution. We can say that it is an externalisation of the designer's solution mental image. But this talking phase is also a thinking phase for the group that can make the sketch evolve. Every sketches are not built in a private area. Some are drawn directly in the public area of the table. A Sketch can also move from a talking to a prescriptive status. A sketch which has been the instrument of solution negotiation and elaboration, can get a prescriptive status after the group has built an agreement over it. For example, the sketch figure 2 got this prescriptive status by the group agreement. This decision is confirmed by a mark on the object: One of the actor underlined the word piston. This mark (detail Al) acts as the validation of the agreement. The definition and the negotiation of this part is then closed. Goel [5] suggests another way to characterise the evolution of sketches in he design process: the transformations typology. He identifies two types of operations occurring between successive sketches in the early stages of design: lateral and vertical transformations. A lateral transformation movement goes from one idea to a slightly different idea. Vertical express a movement from one idea to a detail or an extract of it. Then we can say that the role of the sketches depends on their status and the evolution between to successive sketches. The next table sum up the different categories of sketches we have identified.

Lateral transformation Vertical transformation Thinking Talking / open Private new conjecture Public new conjecture Private in depth conjecture Public in depth conjecture In depth prescription
Private area Public area

Prescription / closed New prescription

Table 1. Typology of sketches

The status of the sketch is important in the sense that they partially characterise the situation of action where the actors are involved. Referring to the model presented figure 1, we can notice that the perception of the situation allows the receiver to build the sense of the information within the situation S. It act as a part of rhetoric components.

14

ICED 01 - C586/418

2.3 Sketches as a process of building conventional support

For the explanation of this point, we must focus on the building process of those objects. The Object presented in figure 3 is in fact an addition of different sketch steps. The building of this sketch represents 20 minutes of group interaction during the design process. We consider that it is in this object that emerges the solution principle developed during the next phases of the experiment[7]. The first sketch (detail A) was drawn to put a end to a misunderstanding between two actors. They did not have the same interpretation of the requirements. The three sketches (A, B, C) allowed them to build a shared understanding of the problem. Then, from this representation a third actor had doubt about the connection between the device and its environment. This actor assessed the rubber tubing connection (detail D) as a non reliable solution for this system. From this negative evaluation of the solution elements represented on this sketch emerged a few minutes later a rigid and quick connection solution that is represented (detail E) on the sketch. This move is a lateral transformation that highlight the emergence process. Then this solution offered new opportunities for the inter-connections system of blocks. Finally a general overview of the system was drawn to visualise the ability of blocks interconnection (detail F). This last view is a vertical transformation showing the same solution from another point of view.

Figure 2. Status of object moves during the process.

Figure 3. Different level of sketches in the same draft...

This sketch shows that the knowledge of construction process is necessary to be able to understand the sketch. In this sketch, aborted solutions and the solution chosen are represented on the same level. Nothing but the knowing of the process allowed the actors to differentiate the good from the aborted solution. This point allows us to point out that this type of GNSI is not able to support a prescription task. It failed as a memory of the process, In our protocol, we highlight that the actors themselves had difficulties to re-use their own sketches out of the action process itself. [7] The actors created, during the process, some symbolic devices which were connected to semantic in a local convention. This allowed them to let some part of the device in a low definition level: fuzzy and partial. The objects were used as "cognitive artefacts". The participants did not describe precisely what they were talking about, they showed the different elements they wanted to highlight with a finger or a pen and they used diectic words to point them. For example, an actor said: "that will be difficult to manufacture" (showing the elements concerned with his pen)

ICED 01 - C586/418

15

We want to highlight the fact that the sketches act as pragmatic conventional supports [13]. Those conventional supports are negotiated in the interactions between actors, even if they can also use a higher level of convention as cultural ones, shared by the actors (the rules of industrial drawing in our case). The sense of the sketch is built in the action process and the conventions which allow this interpretation are quite local. Rhetoric components of sketches are specific and part of the linguistic components are built within the action itself. This characteristic of GNSI is important in order to imagine design tool able to support GNSI in an asynchronous communication process; furthermore, in order to involve sketches in a knowledge capitalisation process as MICA does for textual NSI. Indeed local conventions which allow interpretations are built in the interaction process. They won't be available to actors that were not involved in the process itself.

Towards a communication tool MICA GRAPH

The first quality of a sketching device for designer seems to allow fast freehand sketch. Previous studies have highlighted that the cognitive tasks of manipulating the sketching tool have to be minimised [14]. Even if we can expect that the actors will learn the tool. That is why the tool is based on a simple blackboard technic and uses a digital table with an electronic pen. Indeed, when the designer needs formal drawing he will mainly use CAD or Structured information tools. Sketches are just GNSI and support fuzzy and partial definitions of elements. The functions that we offer are not supposed to help the drawing process but to partially structure GNSI in order to capitalise and treat them in the knowledge process. We are at the moment unable to manage a knowledge treatment directly on sketches. The principle we develop here is to characterise GNSI, track the steps of the building process and to associate textual and symbolic information that the data-mining techniques used by MICA are able to treat. At the moment, a designer creates a new sketch, he creates a properties file containing the legend of the file, type of the GNSI created and all the textual annotations contained. All this textual information is able to be treated by the MICA data-mining process [4].

3.1 Tracking the different steps of the object

We have highlighted the difficulty to track the different steps of a sketch out of the drawing process. It is also impossible to identify in a sketch the valid elements from the aborted solutions. It is important to follow the sketches modifications and to track the different sketch levels and steps present in the same final draft. We also want to know who had drawn on it. We propose to develop a structure of layers in order track the process. Each actor who wants to draw on an existing draft has to open a new layer. He can chose two options: "transparency" that allows him to sketch on the previous element or "blank" that opens a new layer disconnected from the previous sketch. In order to track information about the sketch contents and intentions, we characterise the type of opened layers. Six types of layers are available corresponding to the typology proposed in table 1. Public layers and private layers have different properties. When an actor wants to send a sketch, the public layers are automatically sent. Private layers sending is optional. If the actor accepts to send them the category changes moving from private to the public area.

16

ICED01-C586/418

In order to highlight decisions concerning a specific area of a sketch, actors can modify the colour of this area. By drawing a boundary line around this area, they notify that it is fixed. This materialises the compromise within the object.

3.2 The necessity to associate annotations on GNSI

In order to allow the actors to interpret the sketches in an asynchronous communication mode, and to capitalise textual information about the content of the sketch, we propose different devices to the users. Firstly an actor as to define a title to the sketch using few keywords. We notice here that some contextual components (product, process, state, part etc. ) are already identified in the MICA form. [2] [4] It is important to give the actors the ability to express comments in the sketch itself. In a synchronous interaction around sketches actors explain some elements of the solution they focus on. Drawing is generally accompanied by a speech concerning the sketch. In an asynchronous process, the speech does not exist. It is supported by writing in the message or by a local annotation on the sketch. In the same way, actors need to be able to focus the attention of the receiver on a specific area and to associate elements that allow the receiver to interpret the sketch in the right way. They have sometimes to explain some symbolic elements they have used to fuzzy represent an element. Annotations can allow them to do it. The annotations are textual information that are connected to the graphic properties. A further step is to allow an actor to define different types of annotations using colour and type of markers. Each time he defines a new type, he has to explain the legend of this symbolic feature. Laureillard had pointed out the importance of what he called co-operative feature in the co-operation between specialists [15][16]. Those symbols are local conventional supports which refer to shared knowledge between the different actors. We don't have deeply investigated the different types of annotation. Our proposition is to offer a toolbox to the actors. They have to define themselves the relevant type co-operation feature.

Conclusions

The concepts developed in the MICA-GRAPH tool have to be improved in design practices. The aim is not to suppress synchronous interactions but to complete the offer of asynchronous communications tools for design activities. Engineering design needs visual representations: structured (like CAD models) and non structured (like sketches). GNSI allows to manage quick conjecture-evaluation process. We notice that the move from direct interaction to textual explanation implies the risk of the deterioration of the contents. But the advantages of textual information related to GNSI are their ability to be treated in a knowledge process. References [1] [2] B. Prasad, Concurrent Engineering Fundamentals - Integrated product and process organisation, Vol. 1, Prentice Hall, Englewood Cliffs, NJ, 1996 M. Gardoni, M. Spadoni, F. Vernadat, "Information and Knowledge Support in Concurrent Engineering Environments", 3rd International Conference on Engineering Design and Automation, EDA'99, Vancouver, B.C., Canada, August 1-4, 1999

ICED 01 - C586/418

17

[3] [4]

Moeschler, J. Modelisation du dialogue (representation de 1'inference argumentative), Editions Hermes, Paris, 1989 M. Gardoni, Maitrise de 1'information non structuree et capitalisation du savoir et du savoir-faire en Ingenierie Integree - Cas d'etude Aerospatiale Matra, PhD thesis of Metz University 1999 Goel V, Sketches of thought MIT press Cambridge, MA 1995 Gardoni M., Blanco E Taxonomy of information and capitalisation in a Concurrent Engineering context 7th ispe international conference on concurrent engineering (CE'2000), Lyon, France, July 2000 Blanco E., 1'emergence du produit dans la conception distribute PHD thesis INP Grenoble 1998 Garro O., Salau I., Martin P., Distributed design theory and methodology, Concurrent engineering: research and applications, vol 3/1/1995. Vinck D., Jeantet A., 1995 Mediating and commissioning objects in the sociotechnical process of product design: a conceptual approach, pp111-129 in D. Mac Lean, P. Saviotti, D. Vinck (eds), Management and new technology : Design, Networks and Strategy. COST Social science serie. Bruxelles. Commission of european

[5] [6]

[7] [8] [9]

[10] Blanco E., Garro O., Brissaud D., Jeantet A., Intermediary object in the context of distributed design CESA Computational Engineering in systems applications, IEEESMC, Lille, July 96 [11] Fergusson E,S, Engineering and the Mind's Eye MIT press Cambridge, MA 1992 [12] Rodgers PA, Green G., McGownA. Using concept sketches to track design progress in Design studies 21 N5 pp 465-481 sept 2000 [13] N. Dodier, les appuis conventionnels de I'action elements de pragmatique sociologique Reseaux n62 edition CNET, 1993 [14] Aytes G., Comparing Drawing Tools and Whiteboards: An Analysis of the Group Process in CSCW 4: 51-71, 1996 [15] Laureillard P., conception integree dans I 'usage, PHD thesis INP Grenoble 1999 [16] Boujut, Blanco The role of objects in design co-operation: communication throught virtual or physical objects. In COOP 2000 conferences Workshop Sophia Antipolis May 2000 Dr Blanco Eric Soils Solids Structures laboratory, Domaine Universitaire, BP 53, 38041 GRENOBLE Cedex 9, France, Tel: (33)-4-76-82-70-11, Fax (33)-4-76-82-70-43, mail - eric.blanco@hmg.inpg.fr Dr Gardoni Mickael GILCO laboratory, ENSGI, 46 avenue Felix Viallet, 38031 Grenoble Cedexl, France, Tel (33) (0)4 76 57 43 33, Fax (33) (0)4 76 57 46 95, mail: gardoni@gilco.inpg.fr (c)IMechE2001

18

ICED 01 - C586/418

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

AUTOMATIC COMPOSITION OF XML DOCUMENTS TO EXPRESS DESIGN INFORMATION NEEDS

A Dong, S Song, J-L Wu, and A M Agogino Keywords: Information analysis, classification and retrieval; information representation; design information management

Introduction

Engineering design is an information intensive activity. It is reported that designers spend in excess of 50% of their time in handling information [7]. Thus, the efficiency and the quality of the design process depend considerably on how well designers are able to handle large amounts of information. One study [8] of the information required by design engineers to complete their jobs indicated that less than 50% of that information was actually available and only 20% could be provided by the existing specialized applications. Directing the right information to the right person at the right time is a complicated but crucial task. Design information management has received increasing attention in recent years as a result of these findings and the recognition that lacking sufficient or missing key design information may lead to sub-optimal decision-making and design [2,4]. Much of the existing research has focused on the capture, storage, indexing and presentation of design information including informal information [3,9]. Less work has been done on information retrieval based on an understanding of individual designers, their experience, their skills and the ways in which they use information in the context of their design task [1]. One key step in finding the right information is expressing information needs in context. This paper presents a methodology to generate an XML (extensible Markup Language) document that expresses the information needs of a design engineer. XML documents and their underlying Document Type Definition (DTD) offer an efficient structure for the organization of design information [5] and representation of information needs. Through declarations of XML entities and the inherent structural hierarchy of XML documents, XML documents can express the designer's information needs while framing the design's structural hierarchies. For example, an element in the DTD may permit the design engineer to express a preference for formal company documents of past designs (e.g., technical memos) rather than informal design notes. The data in the XML document may be drawn from a repository of semi-structured or unstructured text documents that the design engineer has retrieved and placed into a personal information store by using an information retrieval system. Our methodology draws from the computational linguistics techniques of natural language processing and latent semantic analysis (LSA). We assume there exists some underlying information needs that are expressed by the type of information the engineering designer wishes to view and download into a personal information store. The "type of information" will be distinguished primarily by subject but may include other identifiers such as the format of the information and the intended audience. By applying these linguistic techniques, we can

ICED 01 - C586/422

19

construct an XML document that is descriptive of this underlying need and contains information directly from the documents that is consistent with the major patterns of information preferences of the designer.

Methodology

2.1 Technical Approach

The methodology for automated composition of the XML documents proceeds along two axes: 1) explicitly solicit information needs from the designer through standard information retrieval means; 2) implicitly monitor the information retrieval behaviour of the designer to information sources including the type, quality and information contained in the documents the designer chose to retrieve. We test this methodology on access to unstructured engineering data, such as full-text, because unstructured, textual documents are the principal mode of communication by engineers. Before proceeding to a detailed discussion of our methodology, we discuss two core technologies to the methodology: mining of transaction logs to learn information needs implicitly and computational linguistics.

2.2 Learning Information Needs Implicitly

Many difficulties exist in determining what information a person wants to see as well as modelling user information needs. Most information retrieval systems require that people express information needs through a set of keywords or key phrases. However, ascertaining information needs simply by a word or two is inadequate and subject to loss of contextual information. For engineering design, studies have shown varying information needs of designers depending on level of expertise and stage of the design [1,6]. Our approach in modelling user information needs is based on a human-centred computing. Our methodology examines the user's document access patterns, that is, the user's personal information store and transaction history in an information retrieval system, for patterns of information preference. The basic approach is to examine the user's session information over all sessions while using the information management system. In learning information needs implicitly, we are primarily interested in discovering the similarity between documents that the user has downloaded into a personal information store. The assumption is that the user's particular choices of documents to store locally are indicative of information needs. Thus, instead of requiring the designer to a priori categorize the information, the system attempts to learn a similarity mapping using contextual clues such as project name, engineering discipline, and document format. Similar categorisation strategies have also been found in the classification of supplier information practised in industry [12]. To ascertain relevance, the system records each document downloaded into the user's personal information store. This is an accurate indicator of relevance because, in our system, before the user may download the document, the user has already read a brief description of the content of the document containing meta-information such as abstract, author, document type, and subject. The assumption is that during any single session utilizing the information retrieval system, the user has a dominant goal (information need) in mind that is expressed by the type(s) of documents the user decides to download. Similar assumptions exist in other studies [13] of information retrieval systems. We use the vector space approach [14] for document and query representation. We analytically modelled information needs as a linear combination of the vectors representing

20

ICED 01 - C586/422

the query and the relevant document. The weighted vector average (arithmetic mean) of all combined vectors consisting of the query and relevant documents is called the "centroid" of the user's intended information needs. The centroid is then used as a representation of the dominant information need of the user. The maximum angle between the document vectors or query string vector and the centroid is used as an indication of the variation in the user's information needs.

2.3 Computational Linguistic Approaches

Our methodology employs two computational linguistics techniques, natural language processing and latent semantic analysis, to extract and summarize the primary topic of a set of similar documents. Natural Language Processing While we use the designer's past transactions as an indication of information need, the structured information contained in the documents that are referenced in the transactions needs to be discovered and refined before it can be utilised effectively. The key phrase retrieval process helps in crosschecking the indexed subjects and compacting the size of the aggregated XML document by representing paragraphs of text with just a few representative noun phrases. As the designer adds documents to a personal information store, we do not need to concatenate all the textual information about the document to the XML document, just the extracted noun phrases that are not already in there and plug them under the appropriate tags. By identifying the noun phrases in the document, we are able to find the corresponding contents for each XML tag in the text. Additional rules and procedures are needed other than standard noun phrase retrieval process to perform this task for all tags. This latter component forms a part of future research. Extracting from the full-text content-bearing noun phrases documents that can be used in profiling and indexing involves 3 steps: tokenization, part-of-speech (POS) tagging and nounphrase identification. Tokenization is a procedure that identifies sentence boundaries and removes extraneous punctuations. POS taggers then take the processed corpus and tag each word with their POS information. Taggers that operate following semantic rules or just statistical information were developed. After the text corpus has been tagged with POS information, we could use the contextual information to identify noun phrases. The extracted noun phrases are then attached to the corresponding DTD elements of the document. Latent Semantic Analysis Latent Semantic Analysis (LSA) [9] is a statistical model of word usage that permits comparisons of semantic similarity between pieces of textual information. The idea is that the totality of information about all the word contexts in which a word does and does not appear provides a set of mutual constraints that largely determines the similarity of meaning of words and sets of words to each other. The primary assumption of LSA is that there exists an underlying or "latent" structure in the pattern of word usage across documents. LSA uses the matrix technique of singular value decomposition (SVD) to reflect the major associative patterns of words in the document and to ignore the smaller influences. The ability for LSA to remove the obscuring "noise" makes LSA useful as an analytical tool for discovering the primary conceptual content of documents. We use LSA to help us to categorize and group the documents by topic material that the user has downloaded and revealed as relevant and useful. Once these principal groupings are identified, we can then apply the rest of our methodology

ICED 01 - C586/422

21

to express information needs for each "centroid" of documents within a semantic locality through a single XML document.

2.4 Composing XML Documents

The system initiates by asking the user to specify an XML DTD containing metadata elements (XML entities) that express information needs. For this study, we asked that users express their information needs using a well-known metadata set, the IEEE Learning Object Metadata (LOM) [10], and in particular the core 20 elements. The LOM defines the information required to manage, locate and evaluate learning resources. Having a standards-based XML DTD allows us to assess our methodology's completeness and efficacy and for comparison against other systems. Because of the analogous human cognitive processes of information processing and learning [11], the LOM serves as a reasonable model for describing information needs. Once the user has specified an XML DTD, the user must now utilise the information management system, retrieving and downloading design documents. The system implicitly monitors the information retrieval transactions of the user, eventually formulating a seed an XML document containing information from the user's session. Typically, the XML document is seeded with the initial query the user posed to the system. The implicit stage contains two phases. In phase one, the system applies latent semantic analysis to characterize the knowledge conveyed by the all documents the person chose to view. To perform this phase, we analysed the transaction logs containing the transactions of both the current user and all other users of the system. The user's query and document(s) downloaded are recorded for each visit. The latter information identifies the relevant documents necessary for phase two. Using a similarity measurement, the system identifies topics represented by the documents the user viewed. By doing this step, the system ascertains the topic locality of the various documents the person viewed. This is a critical step because the user may have multiple and widely varying information needs. Then, for each topic locality, the system augments the XML document expressing the user's information needs with the metadata elements from each relevant document. In practice, the information management system will contain most of the information required to complete the tagging such as Author, Title, Date, and Format. Subject and Description information are generated automatically from the second phase. This matching can be done by exact one-to-one correlation, i.e., both the tag and attribute match, or via a crosswalk between the information about the document contained in the information management system and the XML DTD. Both of these techniques will have required some prior means of tagging the documents in the information management system. In the second phase, we apply natural language processing techniques to ascertain the principal subject of the documents within each topic as discussed in Section 2.3. The process repeats until all possible elements in the user's original XML DTD are filled, resulting in a fully marked up XML document. The completed DTD is now an expression of the information needs of the designer, based upon the available information stores and the pattern of information retrieval undertaken. In summary, a designer's information needs can be found implicitly by looking at the set of documents the designer has deemed relevant and useful and stored in a personal information store. We use LSA to find signatures of similarity in this set of documentation. Once we find the signatures, we look at what the original information needs were to find the centroid of the

22

ICED01 - C586/422

similarity. Finally, we construct a compound XML document that essentially reconstructs the full LSA space by combining information from all the similar documents, with some of the information filtered through NLP techniques to reduce the size of the document. Other information about the document indexed in the document database, such as document type, is added to the corresponding XML tag. This final XML document is then an expression of the designer's information needs.

Experimentation and Results

3.1 Test Case

The experiment and prototype evaluation was conducted on a digital library project for science, math, engineering and technology education. Students and educators use the digital library to download courseware into their personal information stores. The documents used in the study discuss the design of engineering devices and related scientific theories. The users of the system typically search for material on engineering education. This is their primary information need.

3.2 Results
First, we validated the ability of our methodology to discover information needs. We conducted this study by analysing for the known information needs of all users of the digital library. Based on the fairly homogeneous content of the digital library (courseware on engineering design) and the known profile of the audience of the digital library, we expected that our methodology would reveal one dominant information need, namely courseware related to engineering education. We would not expect for the system to reveal numerous distinct clusters of information needs. We ran the latent semantic analysis over the entire usage database. Figure 1 illustrates the distribution of all users' information needs over multiple sessions.

Figure 1. Information Needs Represented in LSA Space

ICED 01 - C586/422

23

Each dot represents in LSA space the combined vector of the user's query and a downloaded document for one session. By visual inspection, one can note one dominant information need. Specifically, the most commonly downloaded documents by all users of the system were case studies and courseware on the design of disk drives, a specific subset of engineering education. This result corroborates the known information needs of users of the database. Second, we analysed for the information needs of individual users. Figure 2 illustrates the information needs of one sample user, specifically information on "control systems". The circle represents, in LSA space, the initial query to the information retrieval system whereas the boxed numbers indicate the documents downloaded by the user. One can then apply latent semantic analysis to ascertain the similarity between downloaded documents, the original query, and the documents themselves. Users may have multiple information needs despite using the same keyword to query the information retrieval system. In the example shown, document 165 is relevant to the user's query but not similar to the other documents, therefore potentially indicating different information needs. For this document set, we found that an angle of 71o between documents provided an adequate measurement of similarity. Based on the set of similar documents, we computed the centroid.

Figure 2. One User's Information Needs

Finally, we generated the XML documents to express the information needs. Portions of an XML document are illustrated in Figure 3.
<!-- The Core IMS Learning Object Metadata in XML, a subset of the IEEE LOM V3.5. --> <metametadata> <metadatascheme>IEEELOM:1.0</metadatascheme> <language>en-US</language> </metametadata> <general> <title> <langstring> educational software engineering graphics tutorials engineering visual encyclopedia

24

ICED 01 - C586/422

mechanics virtual disk drive design studio </langstring> </title> <language>en-US</language> <description> <langstring> acme disk drive company <lifecycle> <contribute> <role> <langstring lang="en">Author</langstring> </role> <centity> BEGIN:vCard <?xml>

Figure 3. Sample XML Document

The XML document expresses out in human-readable format a summary of the user's information needs as an aggregation of the documents that the user found relevant and useful and that were related to each other.

Conclusions

This research has established a basic framework for identifying and modelling engineers' information needs using XML documents. We performed latent semantic analysis over a collection of engineering resources to construct information needs as vectors in LSA space based on usage analysis. We visualized different information needs in multi-dimensional space. Based on a cluster of similar documents representing an information need, we generated an XML document using natural language processing techniques to express the information need. These results are encouraging. They show that latent semantic analysis can be applied to the task of ascertaining information needs by monitoring the information retrieval habits of a user. In order to assess the actual "truth" of the XML document in representing the user's information needs, we would need to have the user respond positively or negatively to suggested relevant information provided autonomously by the information retrieval system. We have projects in progress to incorporate this feedback. In addition, we are working on methods to incorporate reading time into the model of information needs and to predict the expected reading time of a document based on prior reading time. We expect this methodology to impact the use of information in design in several ways. First, the XML documents can be used as information filters to direct critical pieces of information to the designer as others generate them. In addition, intelligent software agents might use the XML document as a guide to search document repositories for new, useful information. The methodology may provide insight into the cognitive states of the designer over various stages of design, offering a tool to study how changes in information needs relate to the designer's understanding of the design problem. We are currently analysing the effect of time on information needs, particularly the rate of change of information needs. In addition, we are investigating learning the information needs of design teams by analysing team communication. Our methodology presents a new means for learning information needs through a combination of LSA, natural language processing and a human-centred approach which places emphasis on understanding what it is that the user is doing.

ICED 01 - C586/422

25

5
[1]

References
Lowe, Alistair, McMahon, Chris, and Shah, Tulan, Culley, S., "A Method for The Study of Information Use Profiles for Design Engineers," Proceedings of the 1999 ASME Design Engineering Technical Conferences. September 12-15, 1999, Las Vegas, Nevada. Court, A.W., Culley, S.J., and McMahon, C. A., "The Influence of IT in New Product Development: Observations of an Empirical Study of the Access of Engineering Design Information, International Journal of Information Management, 17(5), 1997, p359-375. Dong, Andy and Agogino, Alice M., "Text analysis for constructing design representations." Artificial Intelligence in Engineering. 11, 1997, p65-75. Rangan, R.M., and Fulton, R.E., "A data management strategy to control design and manufacturing information." Journal of Engineering with Computers. 7, 1991, p63-78. Rezayat, M., "Knowledge-based product development using XML and KCs," Computer-Aided Design. 32, 2000, 299-309. Ullman, David G., Dietterich, Thomas G., and Stauffer, Larry A., "A Model of the Mechanical Design Process Based on Empirical Data", Artificial Intelligence in Engineering Design and Manufacturing. 2(1), 1988, p33-52. Williams, Ruth L., and Cothrel, Joseph, "Four smart ways to run online communities," Sloan Management Review. 41(4), Summer 2000, p81-91. Wood, William H., Yang, Maria, et al., "Design information retrieval: improving access to the informal side of design," Proceedings of the ASME Design Engineering Technical Conferences. 1998. Deerwester, Scott, Dumais, Susan T., Furnas, George W., Landauer, Thomas K., and Harshman, Richard, "Indexing by Latent Semantic Analysis," Journal Of The American Society For Information Science. September 1990, 41(6), p391-407.

[2]

[3] [4] [5] [6]

[7] [8]

[9]

[10] Learning Object Metadata, http://ltsc.ieee.org/doc/wgl2/LOMdoc2_4.doc. [11] In Klahr, David and Kotovsky, Kenneth, (Eds.), Complex Information Processing: The Impact of Herbert A. Simon, Lawrence Erlbaum Associates, Hillsdale, New Jersey, 1989. [12] Culley, Stephen J., Boston, Oliver P., and McMahon, Christopher A., "Suppliers in New Product Development: Their Information and Integration," Journal of Engineering Design, 10(1), 1999, 59-75. [13] Cooper, William S., 1976, "The Paradoxical Role of Unexamined Documents in the Evaluation of Retrieval Effectiveness," Information Processing and Management, 12, 367-375. [14] Salton, Gerald and McGill, Michael J., 1983, Introduction to Modem Retrieval, New York: McGraw-Hill Book Company. Information

Dr. Andy Dong, Lecturer University of California, Berkeley, Department of Mechanical Engineering, 5138 Etcheverry Hall, Berkeley, CA 94720-1740 USA, Tel: +1 510 643 1819, Fax: +1 510 643 1822, E-mail: adong@me.berkeley.edu IMechE 2001

26

ICED 01 - C586/422

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DESIGN COMMUNICATION USING A VARIATION OF THE DESIGN STRUCTURE MATRIX

J C Lockledge and F A Salustri Keywords: concurrent engineering, automotive engineering, design information management, workflow management.

Introduction

As reported in earlier work[1], the authors have constructed a mechanism for structuring design communications at a leading American automobile maker using a variation of the Design Structure Matrix (DSM). This paper provides a formal process to create similar matrices and outlines a mechanism for keeping participants updated on the design status. The original work was carried out in collaboration with, and implemented at, a major American automobile manufacturer. The new work reported herein is a prototype which has as yet to be implemented in an industrial setting. Many major industries base their design organizations on teams of design engineers (DEs). The use of team-based engineering practices can substantially improve the effectiveness of design processes, but they also introduce new complexities in terms of communications between team members and management of tasks carried out by the teams. This is particularly true in major industries, like the automotive industry. Thus, while modern design practices have improved the nature of the products being developed, they have also increased the administrative and management burden arising from increased complexity; what is gained in one respect can be easily lost in the other. Because these complexities are not product complexities but, rather, complexities of design and designing, they were not immediately recognized as important performance issues. Recently, however, more and more interest has been shown in North America to seek a deeper understanding of the complexities of modem design as they arise largely from these issues of communications and task management. The authors are developing a means of managing the design process to ensure appropriate communication between design team members is facilitated, that task management is streamlined, and that all this can be done without placing further burdens on the designers. Different enterprises choose different strategies to achieve these goals. One leading automobile manufacturer chose the strategy of re-defining its design process. While the car manufacturer currently designs world class engines, they felt a need to reduce their time to market. As part of this overall effort, they identified their engine design process as one for examination and improvement. The authors undertook to assist the company by developing a tool to help the company's design engineers manage engine design information more efficiently and reduce the initial design time. We focused on the following stages of the process: the initial steps in identifying

1CED 01 - C586/584

27

a desired engine to be designed (needs analysis), coordinating the initial design (conceptual design), and the day-to-day design process (design information flow). In particular, the authors noted that information regarding design changes was propagated wholesale to all DEs. This forced DEs to spend valuable time deciding if a particular design change affected the components or systems for which they were responsible. The authors conducted interviews with many DEs involved in engine design at the auto maker. Based on analysis of these interviews and background research into the company's practices, the authors concluded that a successful tool would have to be extremely flexible to respond to mid-program changes in design priorities and objectives. The tool also had to be very simple to use so as not to burden the DEs further with extra work. Our solution was a variation of Steward's Design Structure Matrix (DSM)[2]. The DSM was chosen for of its simplicity of presentation and of construction. It essentially allows designers to capture the relationships between structural elements, systems, subsystems, etc. of a product in an easily understood matrix form. Once in this form, various manipulations can be performed on the matrix to discover features of the design, such a clusters of very high interaction between product components. The analogy between simple matrix operations, which all engineers understand, and design information management make the DSM quite a useful tool. The authors modified the DSM in two ways. First, we distinguished between the physical components of an automobile engine (listing them on one axis) from the functional systems and subsystems of the engine (listing them on the other axis). Identifying interactions in the modified matrix now results in identifying the functional dependencies of the structural components. By linking structure and function in this way, the matrix was used to identify the stakeholders that needed to be notified of design changes or decisions. Put another way, DEs whose tasks or designs are not affected by a design change will not be informed of the change. This means that change information is more efficiently managed.

Table 1: Example Design Process Matrix (DPM) Manufacturing

Process

c
0 CO

8
CD

TD

1 ca CO I > X X X X X X X X

Lubrication Delivery Return Combustion Intake Exhaust Fuel Delivery Chamber Cooling Power Conversion
X X X

X X X X

X X X

Crankshaft

c 'a H

CD

Connecting Rod

28

ICED 01 - C586/584

The second modification was to build a secondary matrix above the first one to cover interactions between components and manufacturing processes. In this way, interactions between components and the systems needed to manufacture them can be made explicit. This extends the chain of interactions all the way from the functional systems, through physical components, to fabrication. Any change to one can be propagated to only those stakeholders in related aspects who need to know about the change. The authors refer to the resulting matrix structure, as shown in Table 1: Example Design Process Matrix (DPM), as the Design Process Matrix (DPM). With these changes in place, the modified DSM now represented a tool to help manage the design process: the interactions shown by the DPM are indicative of causal relations between systems, components, and manufacturing. For each of these, stakeholders can be identified. Therefore, the DPM is a model of the interrelationships between tasks as well as a model of the required interactions between stakeholders needed to carry out the design tasks. The researched sketched above was received by the automaker and integrated into their overall technical process. However, it was empirical and derived largely from the particular characteristics of the automaker's enterprise and corporate structure. The authors believe that a generalization of the DPM to a broader category of design enterprise could be very beneficial. In order to perform this generalization, a deeper understanding of the process of DPM construction is needed. This paper lays the foundations for such a generalization.

Approach to Constructing the Matrix

The purpose of this process is to create a Design Structure Matrix analogue that can be used for automating communication in a complex design environment. This environment owes its existence to the design of a product (or group of products) that will be produced by the organization. To warrant using this process, the product is expected to be complex enough to have multiple functions and several components that must be manufactured. As pointed out by Hubka and Eder3, the design intent (which are goals within specific constraints) is met by a series of functional systems. Each system exists by being embodied in one or more components (or more precisely organs). These components interact with each other, producing the desired effects through their functional systems. Within an organization individuals or teams (although typically a single individual) are assigned responsibility for releasing a component for production. As originally pointed out by Steward4, the underlying component interaction can therefore be used to model the required interaction of those responsible for designing them. This process allows an Engineering Manager to create a mechanism that takes advantage of these underlying principles to route messages to the proper individuals in a design enterprise. The process is broken into 5 steps: Constructing a Hierarchical, Component Based DSM Constructing a Hierarchical, System Based DSM Constructing a Human Role to Component Mapping Adding Process Based Communication Constructing the Communication Matrix These steps will be defined in detail in the following sections.

1CED 01 - C586/584

29

2.1 Constructing a Hierarchical, Component Based DSM

The construction of a Component DSM (CDSM) has been discussed in detail by Eppinger[5]. In general, the first task is collecting the relevant component names and determining which components define others. Rules for the construction of hierarchical, component DSMs has been delineated by Sabbaghian[6] in his work with Boeing. He points out that in constructing a DSM that has components and sub-components, any interaction between sub-components from different components implies an interaction between the components they belong to. This is illustrated in Table 2 by the interaction between the Connecting Rod and the Piston that causes the interaction with the Piston Assembly. Interactions between sub-components both belonging to a single component do not affect the relationship of the component. This can be seen in the interaction between the Rocker Arm and the Intake and Exhaust Valves. These sub-components are all part of the valve train and therefore these relations do not influence other components. A hierarchical DSM permits a larger number of components to be addressed without overwhelming those who are indicating the relationships. A hierarchical DSM is necessary because the larger number of components (and sub-components) allows finer granularity of the relationships, and the granularity of the dependencies affects how specific the messages to users can be. It also affects the number of messages a user is likely to receive, since courser granularity implies that all of the people involved in a component will receive information on changes to any related component.
Table 2: Hierarchical Component DSM Valve Train Components Connecting Rod Piston Assembly
1> flj
>

Components
-C X

II
<U
O

J*

!<
X

<5 C -

E
X

1 g> E" 2

Connecting Rod Valve Train Components Exhaust Valve Intake Valve Rocker Arm Piston Assembly Piston Piston Ring

30

ICED 01 - C586/584

2.2 Constructing a System Based DSM

Constructing a System based DSM (SDSM) relies on first identifying the functional systems in the object being designed. The functional systems may also be modelled as being hierarchical in nature, for the same reasons given in the previous section. Table 3 shows some sample functional systems in relationship to each other. In this case, the Cooling system is shown as functionally related to both the Lubrication Delivery (in the case of an engine with an oil cooler) and Combustion Chamber systems.
Table 3: Hierarchical System DSM

5
~Q

Air Intake

t > 1

E 2

(2
X

Jr w

Lubrication Delivery Return Cooling Combustion Air Intake Exhaust Chamber

2.3 Constructing a Human Role to Component/System Mapping

In most design organizations, individuals are given final authority for releasing a component's design. Since they are the only actors in the system that can affect the design, the system must interact with them, making them recipients of messages concerning design changes. For the system to do this, these roles must be identified and specified in the Role/Component Mapping (RCM) and the Role/System Mapping (RSM). Identifying these roles (and/or the individuals responsible for them) should be straight forward, as each of the sub-components must have an individual responsible for releasing it. Assigning an individual to an entire component implies that they are the responsible party for all of the sub-components. The individual assigned responsibility will then receive and need to respond to all of the messages concerning their sub-components. Individuals may also be assigned to the systems. These functional systems are not usually viewed as "released parts" so that this position takes on a monitoring role. The person assigned this role would be responsible for keeping individual DE aware of the implications to those systems of any design decisions.

2.4 Constructing the Communication Matrix.

The third matrix, as illustrated in Table 1, is the DPM. This matrix ties together the functional systems and the components. It is constructed by assigning sub-components to functional systems. An assignment results from the system being embodied in the component and thus both defining it and being defined by it.

ICED 01 - C586/584

Chamber

Systems

Combustion

Lubrication

31

2.5 Adding Process Based Communication

Not all of the individuals who are responsible for a product have design release responsibility. Some are involved in the later stages of manufacturing, distribution, marketing, and customer service. Concurrent engineering [7] discusses the need for these parties to be involved in the design process. During this step, individuals who should be aware of design changes, but who may not be central to the process, are added to the matrix. Additional roles are added to the matrix above the components, indicating their interest in those specific components. Messages will be routed to these parties as if they had release responsibility, but they are not required to respond to the changes unless they see an opportunity or problem.

Assisting Communication

These three matrices and two mappings are the starting point for the communication routing system. When a DE makes a change in their (sub-)component (which we'll call M) the system will react by establishing the following sets: SM The systems of which M is part (from the DPM), CM The components that M affects (from the CDSM), Sc The systems shared by M and components of C, and Ssc The systems that interact with systems in SC (from the SDSM). Using the RCM messages can be routed to the individuals responsible for components in CM who will need to be aware of this change. The change can also be routed through the RSM to the monitors of the system in SM. The messages to DEs would contain a statement that M was changing and which systems (Sc) would likely be affected both directly and indirectly (from Ssc). An example makes this somewhat complex process clearer. Suppose we had the CDSM, SDSM, and DPM shown in Table 4, Table 5, and Table 1. In this case, the components are not given hierarchically to conserve space. If a DE made a change in the Crankshaft, we would know from Table 1 that the Lubrication Delivery System and Power Conversion systems would be affected and that Manufacturing would like to be kept aware of any changes.
Table 4: Example Component DSM (CDSM) Connecting Rod

Valve Cover

Valve Train

Component

c o "

.*:

ra 8 03 m T
X X

T3

Piston Block X Head X Valve Train Valve Cover Connecting Rod X Crankshaft

X X X X X X X X

X X

Crankshaft
X

32

ICED 01 -C586/584

Turning our attention to Table 4 we can determine that the Crankshaft directly affects the Block and Connecting Rods. By going back to Table 1 we see that these components share the Lubrication Delivery System and Power Conversion systems. Further, by going to the SDSM (Table 5) we can find that the Lubrication Delivery system also interacts with the Lubrication Return system and that Power Conversion interacts with the Combustion Chamber.
Table 5: Example System DSM (SDSM) Combustion Power Conversion
X

Lubrication

D> _C

"5 o o

System

0)

Exhaust

> 3 "o> "CD Q rr

CD ^ a C

0> Q

'ffl 13 LJ.

Lubrication Delivery Return Combustion Intake Exhaust Fuel Delivery Chamber Cooling Power Conversion
X X X X X X X X

X
X X

Chamber
X X

>

We can now frame messages to the individuals in charge of the Block and the Connecting Rod that would read: A change was recently made in the Crankshaft: <Text generated by the DE who was changing the Crankshaft would appear here> This may impact Lubrication Delivery and Power Conversion. If so, these could cause also impact the Lubrication Return and/or the Combustion Chamber. Please verify the impact of this change on your component. Similar messages could be generated and sent to the individuals monitoring the systems. These messages are not intended to be diagnostic, rather they are to alert the DE that the design has changed and their attention may be required. Work is underway to construct a Web based tool to coordinate the communication between DE. This tool will permit users to either log into a server to be made aware of the current status of the design, or be sent daily emails that summarize the changes.

1CED 01- C586/584

33

Conclusion

This paper is a formalisation of a system to route messages between members of a design team based on a hybrid of the DSM. The routing is accomplished by examining the underlying physical and functional requirements of the product and the interconnections between them. This routing restricts updates to interested parties to avoid overloading the participating engineers with data concerning every change being made in the program. The system does this while following the same minimalist philosophy of the DSM and thus does not require extensive data gathering or modelling. A less formally developed precursor to this system was integrated into the design approach of a major automotive manufacturer and the authors believe this formalisation allows this work to be replicated in other areas. References
[1]

[2]

[3]

[4]

[6]

[7]

Lockledge, J.C. and Salustri, F.A., "Defining the engine design process", Journal of Engineering Design, 10, 1999, pp. 109-124. Steward, D. (1981) System Analysis and Management: Structure, strategy and Design, 3, (New York, Perocelli). Hubka, V and Eder, E., "Engineering Design: General Procedural Model of Engineering Design", Heurista, Zurich, Switzerland, 1992. Steward, Donald V., "The Design Structure System: A Method for Managing the Design of Complex Systems" IEEE Transactions on Engineering Management, vol. 28, pp. 71-74, 1981a. Pimmler, Thomas U. and Eppinger, Steven D., "Integration Analysis of Product Decompositions", Proceedings of the ASME Sixth International Conference on Design Theory and Methodology, Minneapolis, MN, Sept., 1994. Also, M.I.T. Sloan School of Management, Cambridge, MA, Working Paper no. 3690-94-MS, May 1994. Sabbaghian, N, Eppinger, S. and Murman, E, "Product Development Process Capture and Display Using Web-Based Technologies", Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, Par 3 (of 5), pp. 2664-2669, Oct 11-14, 1998. Kusiak, Andrew, Engineering Design: Products, Processes, and Systems, Academic Pr, 1999.

Corresponding Author: Institution: Department: Address:

Phone: Email:

Jeffrey C. Lockledge Wayne State University Department of Industrial and Manufacturing Engineering Manufacturing Engineering Building, 4815 Fourth St., Detroit, MI 48202 313 577 3507 j_lockledge@wayne.edu

IMechE 2001

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

MULTI - A TOOL AND A METHOD TO SUPPORT COLLABORATIVE FUNCTIONAL DESIGN

S Menand and M Tollenaere

Keywords : product model, design process model, functional design, knowledge management, information management, collaborative design, co-ordination, life cycle

Introduction

Concurrent engineering consists in fastening development time by executing in a parallel mode design, analysis, and industrial tasks while they were executed sequentially in traditional development methods. This results in a shortened time to market [7]. Automotive industry has applied successfully concurrent engineering to the most recent range of cars. However, concurrent engineering has not taken into account the dramatic evolution in information systems technology as the new WEB based tools allow to distribute and share technical information through all partners involved in a project [2] [7]. This will lead to new distributed organisations in design teams, to more innovative designs as design hypothesis can be more quickly tested and validated by all actors at Project Wide level. For any design problem, the best specialists from extended enterprises and partners can be appealed with full access to authorised design data with adequate viewpoint. Those new organisations, namely "shared engineering" or "collaborative engineering", will be supported by new "Product Information Systems" that directly take benefits from the information technology and the power of semantic support to information. Information technology must take into account all legacy systems to ensure of continuous data and service access to users: amongst those legacy systems, calculus worksheets, previously developed pieces of software... Further, many efforts have been provided in knowledge engineering for design activities [4] [12]. Design, like other very creative tasks, makes extensive use of many pieces of knowledge [11]. Those pieces of knowledge must be maintained, as knowledge in design is very evolutive. Knowledge is expressed either in the product model or in the tasks of engineering. This knowledge must be accessible to all actors involved in the design process, must be executable in the available design software, and must be maintained by accredited staff. This paper provides concepts for knowledge and information product sharing during the redesign. The second section describes what functional design and redesign are. The third section is dedicated to the presentation of the knowledge management approach employed in the study. The model is presented in section four. The fifth section details the web based tool that have been used to support the methodology. In section six, the application case is presented. Finally some conclusions and open issues conclude the paper.

ICED 01 - C586/021

35

Definition

2.1 Functional design

In practice, the product designer needs to know all the principle functions that the product has to accomplish. Consequently, he has to think about either the technical functions and solutions associated to its principle functions. These activities are called conceptual or functional design. They consist to design those technical solutions or to choice ones, which already exist, with the correct dimensioning. The functional design don't require any geometric or C.A.D. (Computer Assisted Design) model. It provides some crucial decisions, engages the potential life costs and product performances. As a consequence, it should be executed by the best specialists of the product life cycle inside and outside the company. The functional design is mainly based on the functional representation of the product. Linked to the fact that a function is often deployed on several parts of the product [9] which are designed by different actors, it is a co-operative activity. In fact, a function is defined by a set of parameters defined by different actors. The definition of these parameters could be conditioned by a lot of constraints, which come from other actors. These actors work on other physical parts of the product or on different product development phases (ex. manufacturing, assembly, purchasing, suppliers, ecological researchers, and fuel consumption researchers. . .). The functional design must be supported by the design process model and an explicit model of the product life cycle. The first model supports the co-ordination between actors involved in the functional design. The second model ensures that all product life cycle constraints are taken into account during the design phase. For instance, the different life cycle situations of a car may be: motorways, leaving or entering a car park, rainy, muddy and snowy roads, emergency braking, crash tests. . . Cars also have to be simulated in production environment, in maintenance situations, even in recycling phases of their life. This complex set of combined situations must be embedded in a functional model handled by different actors. This model can be developed by the different constraints, issued from different life cycle situations. Hence, the product functions are virtually simulated in all their potential life cycle situations.

2.2 The functional re-design

The functional re-design consists in the choice of the principle solutions among those that are already designed and studied. After that, the goal of the designer is to find the correct dimensioning of the product parameters allowing the product functions to be realised with the performances targets defined in the project requirements and according to the integration constraints. This "new product" also has to be integrated in its new environment taking into account the new physical and functional environment constraints. The main aim of the present study is to formalise the functional design to assist the design team in its functional redesign tasks (also called repetitive tasks). The designer need tools that assist in repetitive tasks in order to obtain time for more innovative and creative tasks.

A knowledge management approach

The knowledge management consists in managing information, data, knowledge and knowhow in order to allow its capitalisation (capture, formalisation...), its reuse (consultation,

36

ICED 01 - C586/021

exploitation. . .) and its maintenance (up-date and enrichment). The following four phases are illustrated in the figure 1 (Source: Michel Grundstein [6]).

Figure 1. The knowledge Capitalising phases [6]

From figure 1, the cycle has four main distinct phases which are respectively the knowledge identification, its capture (and the associated models), its re-use and its maintenance. It is applicable in the design phase, which requires the use of some repetitive tasks stemming from the previous design of similar product or from the same range (redesign or routine design). In this study, for each capitalising cycle phase, some concepts are proposed. These concepts are leading to a generic methodology to help the designers to manage their knowledge in their collaborative functional design. The first phase was developed in section 2.1. The following section is dedicated to the second phase. Phases three and four are presented in section 5.2.

A model to support the "volatile" concurrent engineering redesign

This section is dedicated to the presentation of a new model able to formalise respectively the shared product functions and the shared functional design process capture for the designers. The functional design process defines the product in order to ensure its good functioning according to the required objectives or performances. It must respect the integration constraints. The fact to formalise the functional design process and the product with their functions view point help the designer to design with the efficient quality and the performance at lower cost. Hence, with these models, the designer can reuse the knowledge and the information during its redesign activities.

4.1 A generic approach

Knowledge in functional design can be divided into three different levels. Each level describes both the resulting product and the co-operative design process. A generic level describes the nature of functional design. It is independent from any particular technology and routine of redesign problem. This level is embedded in a "meta model" which contains the definition of the following entities and their relationships: design parameters, features, parts, subassemblies, assemblies, lifecycle phases, functions, sub-functions, constraints between parameters, alternatives in design, actors, roles, activities, task, rules, etc.

ICED 01 - C586/021

37

In accordance with this "meta model", the user can describe in a second level the specific design "domain model" like braking system, bearing system or steering system, etc. This level contains the know-how to perform design in a specific technical domain. It help the designer to know how a function is usually materialised, which constraints must be taken into account for a specific phase of the lifecycle, etc. Presently, this piece of knowledge is often written in a handbook that can be shared on the WEB. This level must have the ability to evolve when new technologies appear. This evolution must be under the control of any responsible actor. The third level is a repository for the design problems and projects. It is called "projects repository" and contains the definition of the products that have been designed in a specific domain. This level can be supported by a specific piece of software that assists the cooperating designers. It should be in accordance with the second level and can also contain the ill-structured information (texts, CAD files, sketches. . . notes) that have not been formalised yet. The ill-structured information must be captured during the design process. Indeed, for the current project or in the future, these information can appear to be very useful for all the designers. This model and its three levels will be implemented in an information system called MULTI (see section 5). It will able to help the designers in the capture and the organisation of their specific pieces of knowledge (engineering tasks from process model, product model and associated knowledge). The model and the third level are depicted in the following section.

4.2 The model and the third level

Nowadays the product and process models (see [1 ]) don't take into account respectively the distributed nature of the product model and the co-ordination between actors. In practice, the knowledge, information and data are not structured and packaged in relation with the actors. Further more, the actual functional product description did not take into account the life situation of the product. Product design, often "volatile", must be at least supported by two related models. A product model embedding the design problem alternatives and results, and a design process model aiming at the capture of tasks, activities, roles and actors. The proposed generic methodology is supported by generic models, which are studied in this section. The generic models represent knowledge at different levels. They describe the collaborative design process, the information flow between actors (design workflow), the shared product information (functional parameters) and the other shared knowledge (feed back to design, know how description, constraints. . .). The product meta model and the third level Design solutions are represented in a classical breakdown representation with assemblies, sub-assemblies, parts, features and parameters. The parameters can be related to any level of the representation such as diameter for a bolt, the capacity for a roller bearing, etc. Each part of the product is associated to an actor, which is responsible to give the information of "its part" to others. The model of figure 2 represents the structure of the product. Functional representation is crucial to represent the design reasoning and to support knowledge. In the studied system, functions are represented in a classical breakdown representation with sub-functions. The functions must be attached to a specific life cycle of

38

ICED 01 - C586/021

the product. Hence, the different life situations of the product can be described in the model. For instance, the parts are manufactured, the assemblies are assembled, the products have to resist to the static efforts, etc. The project repository (third level) is represented by the instance's parameters. The model of figure 2 represents the functions of the product and their allocation on it.

Figure 2. The first and third level of the design product UML model

The design process meta model and the third level To realise the model of the co-operation between the actors, the MKSM activity model [5] is taken as a starting point. The design process meta model represents the roles (actors) who executes the tasks, the input data and their origins (previous tasks), the output data and their destination (following tasks), the associated knowledge (user guides execution, recipe , formulae, advice, previous experiences. . .), the associated resources (software, tools. . .), the annotations (remarks), the constraints issued from the life cycle artefact (production, assembly, etc.) and the conditions of task executions (dependent of the previous choices). The constraints are taken into account in the design process. However, the actors working on a product life cycle phase can affect its constraints on the product parameters. For example, the manufacturing actor can impose the tube section value to use the existing broach. In the future, it will represent some different product view dependent to the actors who participate to the product development to take into account as soon as possible the different constraints [8]. The project repository (third level) is represented by the instance's tasks. The model of figure 3 represents the design process meta model and the third level associated.

ICED 01 - C586/021

39

Figure 3. The UML design process meta model and project repository UML model

The links between the two models The process meta model uses and defines the product meta model parameters. There are relations between the two models. The parameter classes are a common to the two models. Second, the instance's parameters are associated to the instance's tasks like represented on the next figure.

Figure 4. The instances association

web based tool called MULTI

5.1 The concepts implemented to reuse easily the knowledge

With the web based tool, the actors (involved in the functional design) could access knowledge and data with a dedicated and context dependant viewpoint. They can access to the tasks with their related knowledge, data and also its description issued from the implemented design process model (inputs, outputs, constraints. . .). The actors can access (if they want either a functional approach or a structural approach) and edit or modify the appropriate engineering product parameters. They can know the tasks they have to make (tasks push) with their associated data and knowledge (knowledge push) in order they execute all the project tasks (edit the value of a parameter, make an operation. . .). The tasks are valid (send in the actor's agenda in order that he execute it) when all there inputs (parameters) are instantiated by the appropriate actors.

40

ICED 01 - C586/021

5.2 Some concepts to maintain easily the knowledge

The sharing out (push) model tasks and knowledge associated for execution is very interesting for the designer. With this methodology, we plan that the designer will have the right information at the right time (knowledge push) and could maintain and capitalise its knowledge as one goes along. So, the actors can edit their feedback [3] to design for a task as one goes along (post it), update the knowledge on a task, update the life cycle constraint on a task and modify the implemented product model and the design process model The "post it" are treated by the expert comities at some planned date and they discuss about the knowledge base up-date to take into account the experiences notifications.

The case study : designing assisted steering systems

To apply our methodology, to "instantiate" the models associated and to test our information system, our background is the functional design of the assisted steering column (see the Figure 4). This functional design is repetitive because for each vehicle project, the designer has to choice one technical solution among some feasible technical solutions "on shelves" and to dimension it. The goals are that the product ensure the new performance targets and can be integrated in the new physical and functional vehicle environment. This application case aim to have the experiences returned of its use from the twelve designers involved in the functional design phase.

Figure 5. Example of the assisted steering column with hydraulic pump

Conclusions and open issues

This paper has presented an approach to support knowledge management in co-operative functional design. This approach is based on the three levels of the model, each level capturing a piece of knowledge. At the higher level, the "meta-model" captures the nature of functional co-operative design, while the "domain model" embeds the know-how for a specific technical design domain. Finally, the "projects repository" stores the former and present design projects. This repository can be supported by a specific collaborative software, implementing some concepts of the domain model. An application of this approach is presently in progress for the functional design process of assisted steering columns. At this stage of our research, many issues remain opened: communication and consistency between the levels rely on a top down approach, the domain knowledge using the concepts defined in the meta-model, the projects repository storing objects in accordance with their definition in the domain model. Some mechanisms have been defined to allow evolution of the upper models, but we miss methods to maintain consistency between the models during those

ICED 01 - C586/021

41

evolutions. On the other hand, many fields of the models remains ill-structured and techniques of data mining might be useful to extract formal concepts from those large project databases. These techniques could help evolution of the models in a bottom-up approach. References [1] [2] Bernard, A., "Modele de produit et de processus", Proc. Universite d'automne PRIMECA - Nancy - oct 1999 Bonnevault, C., Couffm, F. and Faure, J.M., "Modele de processus de gestion d'informations dans un environnement multi-concepteurs base sur une methode de workflow", 3 erne congres international de genie industriel a montreal, Mai 1999 Busby, J.S., "The neglect of feedback in engineering design organisation", design Studies, Vol. 19, Nl, January 1998 Chapa Kasusky, B.C., "Outils et structures pour la cooperation formelle et informelle dans un contexte de conception holonique", Thesis report of the Institut National Polytechnique de Grenoble, October 1997 Ermine, J.L., "Les svstemes de connaissances". Paris Hermes, 1996 Grunstein M. and al. "Livre blanc", report of the III A workshop in France, 1999 Kusiak, A. and Wang, J., Concurrent Engineering : Simplification of the design process , Proc. CAPE'91 : Integration Aspects. Bordeaux, 1991, p.297-304. Nomaguchi, Y., Tomiyama, T., and Yoshioka, M. : "Document-based Design Process Knowledge Management for Knowledge Intensive Engineering," in U. Cugini and M. Wozny (eds.): Proceedings of the Fourth IF1P Working Group 5.2 Workshop on Knowledge Intensive CAD, May 22-24, 2000, Parma, Universita degli Studi di Parma, Parma, Italy, (2000), pp. 163-185. Prasad, B., "Towards a computer-supported co-operative environment for concurrent engineering", Concurrent Engineering, Volume 5, Number 3, September 1997

[3] [4]

[5] [6] [7] [8]

[9]

[10] Sivaloganathan, S. and Evbuomwan, N.F.O., " Quality Function deployment - The technique : state of the art and future directions", Concurrent Engineering. Volume 5, Number 2, June 1997 [11] Suh, N.P.,<<Applicationsof Axiomatic Design, Integration of Process Knowledge into Design Support, ISBN 0-7923-5655-1, Kluwer Academic Publishers, 1999.

S. Menand (1) (2), M. Tollenaere (2) (1) PSA Peugeot Citroen - DINQ / DSIN / SIPP / IVIC, Product and Process Information System - Knowledge Engineering, 18, rue des Fauvelles, 92250 La Garenne Colombes, FRANCE, phone: (+33)(0)156478342, fax : (+33)(0)156478300, menand@mpsa.com, http://www.psa-peugeot-citroen.com (2) G.I.L.CO. Laboratory (Industrial management, Logistic and Design), INPG (Institut National Polytechnique de Grenoble), 46 avenue Felix-Viallet 38031 Grenoble Cedex 1, FRANCE, Tel: (+33)(0)476574630, Fax: (+33)(0)476574695, E-mail: tollenaere@eilco.inpg.fr. http://qilco.inpg.fr IMechE 2001

42

ICED 01 - C586/021

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

INFORMATION FLOW IN ENGINEERING COMPANIES - PROBLEMS AND THEIR CAUSES

C M Eckert, P J Clarkson, and M K Stacey Keywords: Design teams, design information management.

Introduction

Providing everybody with the right information at the right time is one of the greatest challenges facing all organisations. This means providing relevant information and the right amount of information - not too little, but also not too much, so that the receiver does not get swamped in information, unable to tell the important from the insignificant. This paper reports on observations of how failure to achieve appropriate information flow in large-scale engineering design processes contributes to a variety of problems for designers and decisionmakers. Our observations support the conclusion that large organisations need to support both personal contact and informal channels, and thought-through mechanisms for information transmission between individuals and groups who usually have little personal contact.

Some characteristics of large-scale engineering design

Information management in large-scale engineering design is difficult and challenging for a variety of reasons. Diversity of channels. Information is exchanged among humans, between humans and computer systems and written records, and increasingly between different computer systems. CAD models and other documents often play important roles in structuring and coordinating product development activities [1]. Scale, Complex engineering products are developed over several years in teams of dozens or even hundreds of people with very different backgrounds and expertise, often working in different locations. For example the design of a passenger aircraft takes over 100,000 person-hours. Large organisations and complex teams almost inevitably have a complex managerial structure with hierarchies in each field of expertise, and specific process management in addition to the business and financial management that all large organisations have. Engineering companies are usually embedded in a supply chain, and need to manage the interaction and information exchange between collaborating companies. They must often follow procedures requested by their customers while enforcing their own procedures on their own suppliers. Variety of perspectives. Most design projects involve the collaboration of engineers from different fields, as well as scientists, mathematicians, computer programmers, product designers, CADengineers, draughtsmen, technicians and model builders. These different specialists all have their own sets of concepts for understanding the characteristics of designs, and their owns way of thinking about problems - what Bucciarelli [2] terms object worlds. They have different ways to express ideas, and different skills for creating and interpreting diagrams and other visual representations [see 1]. Communication between object worlds fails to convey the sender's entire expert understanding, but the receiver can recognise implications invisible to

ICED 01 - C586/219

43

the sender. It may also require active translation. Uncertainty. Design by its very nature is the creation of something new that has not previously existed - this involves a high degree of uncertainty. Initially many aspects of the design are unknown and others are imprecise or provisional. Often many blind avenues are pursued as the design develops. Communicating incompleteness, imprecision and provisionality is an important part of team designing [3, see 4, 5]. Tone and phrasing in conversation can convey uncertainty effectively [6], but sketches and other visual representations carry such meta-information inadequately [7, 8]. Cost-benefit mismatches in communication through documents. Computer support for information management has been the subject of intensive research and is increasingly important in industry, but so far the human computer interaction of most engineering support systems has been treated as secondary to the functionality that they can offer. So recording information beyond that absolutely necessary requires too much effort; and the person responsible for recording information is typically not the person who would benefit from the information once it is recorded. Moreover, communication through electronic and paper documents is limited by the expressive power of the available representations [cf 1, 8]. Designers are still reliant on human guides to the huge amount of information potentially relevant to each design, especially for explanations of context. For instance March [9] found in a study in Rolls Royce that designers gained 82% of their information from people they knew and 9% from people they didn't know. Only 9% of all information gathered by his subjects came from computers (3%), bookshelves (2%), filing cabinets (2%), desks (1%), or drawing vaults (1%).

Methods

The research reported in this paper draws on case studies in two large UK engineering companies. In both studies we interviewed senior engineers and engineering managers in semi-structured interviews lasting about an hour. In Spring 1999 we interviewed 23 engineers in a large aerospace company in a study focusing on the processes involved in customising a complex product [10]. In Autumn 2000 we interviewed 15 engineers in an automotive company to gain an insight into planning behaviour at different levels of the company hierarchy and the communication problems that result from it. Both studies also investigated communication and information flows, actively exploring issues raised by earlier research on design teamwork [such as 1, 3] and by the communication problems that we have observed previously in a large ethnographic study of the knitwear design process [8]. As these case studies were primarily based on interviews, the results presented in this paper are based on the participants' own analyses of the communication process. Care was taken in the interviews to establish each interviewee's background and perspective (which is inevitably biased); and assertions were cross-checked with other interviewees to establish the generality of issues, and whether the different participants had compatible views of shared problems. Some important aspects of collaborative designing, such as how the form and content of graphic representations influence communication, can only be investigated effectively in observational studies. These are planned for a later phase of this research.

Perspectives on communication

In understanding communication in large-scale design processes, we need to balance and integrate two contrasting perspectives: how individual human beings exchange information in particular interactions; and how information is handled on a larger scale by an organisation.

44

ICED 01 - C586/219

4.1

Understanding is actively constructed

A number of design researchers with a sociological perspective have drawn attention to how information is expressed and constructed from content and context [3, 2, 6, 1]. They see designs as generated in negotiation between human actors, where information is actively communicated and actively made sense of. Each individual's understanding of the design situation is dynamic and unique, and is constructed largely through interaction with other people and with all sorts of textual and graphic representations of design information. Successfully constructing an understanding of what to do in a new or changed situation, such as a modification to a design, comprises obtaining the information needed and making sense of it. Making sense of what you see or are told has three aspects (that are inseparable in practice) shown in Figure 1: interpreting this information from the form in which it is represented; integrating it into one's understanding of the situation by elaborating it and evaluating its quality with contextual knowledge; and inferring its implications for one's own tasks and responsibilities, and how to apply it. This necessarily involves learned interpretation skills, background knowledge and awareness of context, which are different for each participant. A representation of design information might be incomplete, ambiguous or inconsistent, or obscure aspects of the design. Missing information must be filled in from context, typically with conventional assumptions or default values, which might or might not be right for the problem. If the recipient realises that the information is incomplete or inadequate, he or she will try to find the missing or correct information, either by going back to the person who has provided the information or by looking for other ways to find it.

Figure 1. Recipient's Perspective on Information Transmission

4.2

Information flow

To understand design processes we need a broader perspective than cognitive or sociological insights into individual designing episodes can give us. We need to understand how many different activities fit together to create a design. Taking an information-centred perspective allows us to consider how designing activities are structured by the design itself (as well as requirements and constraints it must meet) and by the social organisation of the designers and their environment. However, information flow isn't smooth or infallible or confined to formal channels, or even deliberate communication; it is often chaotic and cannot entirely be predicted. In engineering design, a great deal of information is usually communicated through the representations in which the design is generated, such as CAD models or sketches,

1CED 01 - C586/219

45

whether they serve as focus for discussions or are generated and read at different times and places [see 1]. CAD models, drawings and formal documents are seldom produced to convey specific points. Often they carry more information than needs to be communicated at a particular time. Much information is transmitted through the customary organisational communication patterns, for example distribution lists, between people with particular organisational roles. Designers also become aware of information that they are not actively seeking through the activities of their colleagues. In taking an information flow perspective, this paper concentrates on communication between the members of a large team designing a complex product, who cannot all meet frequently or solve problems by interactive negotiation (see [11] for a discussion of different communication situations). Even when designers can meet and discuss, they may be responsible for generating and passing on information about particular aspects of the design. A lot of design research has looked at joint designing in meetings, both because it is much easier to study experimentally, and because many important decisions are made in meetings [3, 2]. Tracking information flow in detail through such interactive joint designing is both infeasible and unnecessary for guiding the management of design communication. What is needed instead is understanding what information and expertise should inform joint designing.

Manifestations of communication breakdown

The following list does not present a complete picture of possible failures of information transmission. Instead it describes manifestations of inadequate information flow that have been commented on in our interviews or observed in other studies.

5.1

Not understanding the big picture

It is extremely difficult for an individual design to fully understand a complex product or the process by which it is generated. The designers in our study had a localised knowledge of the product and the process, but had very little understanding of other aspect even on a very high level. For example the aerospace designers had only the most cursory understanding of the role avionics played in the overall craft. Of course, complex products are decomposed as far as is possible into modules with relatively simple interactions, to minimise the complexity of the design process. But lack of awareness of interactions between components of designs and between design processes results in a number of problems, when designers don't know what information they need to provide at which time; nor what information they need to request. 1. Lack of awareness of tasks that need to be done. Team members were not aware of the requirements of other designers and therefore failed to do tasks. Often they knew about big tasks, but small seemingly insignificant tasks can have a huge impact on the design process if they are not done in time, for example ordering a vital component for a prototype. 2. Lack of awareness of information history. Team members often don't know where items of information such as specifications and parameter values come from. In consequence they can't trace them back the designers who are responsible for them, and so can't question the information. If the designers need to change previous decisions such as parameter values, they don't know who has based their decisions on this value and therefore would need to change their own areas of the design. Tracking information is especially difficult across organisational barriers.

46

1CED 01 - C586/219

3. Lack of awareness of how information is applied. Team members often don't know how their contribution fits into the overall process. They don't know who depends on the information that they are creating, nor how they use the information. In consequence designers often don't provide their colleagues with all the information they need to have, especially about what decisions are provisional, or the boundaries within which parameters can be changed [see 5]. 4. Lack of awareness of changes to processes. Design processes are often changed because new requirements are added, or scheduled tasks have failed and need to be repeated or replaced with more complex procedures. News of process changes is often not passed on to members of the design team, so that they don't re-plan their own activities, or do tasks that are no longer required. 5.2 Missing information provision

Problems often arise simply because designers are not told what they need to know. 5. No feedback on information provided. Team members often don't get feedback on how their information has been used by colleagues. In consequence they can't identify failings in how well they perform their own tasks or how they communicate with their colleagues, so can't improve their performance. They may also feel under-appreciated. 6. No status information. Team members can often not make sense of the status of the information that they receive; for example if a parameter value is a final value or a simple estimate, or if an element of a sketch is an important and carefully thought-through element of the design or merely a placeholder there to make other elements of the sketch comprehensible [see 4, 7]. People therefore often assume that values are exact and put great effort into meeting a seemingly exact target. In our study of knitwear design [7,8] we found that technicians often ignored parts of garment specifications because they could not assess which aspects they should rely on. 7. Power structure excludes viewpoints. Contractors and suppliers are often excluded from decision-making processes, because they have no official standing in the company hierarchy or because the information discussed in meetings is considered confidential. Yet their tasks depend on decisions made in these meetings; moreover the success of the product might depend on the decisions made in these meetings drawing on their expertise and addressing their concerns. 8. Information is consciously withheld. Contractors or suppliers are consciously not given information that might be useful for their tasks, because it is considered confidential. Information can also be withheld when the provider of the information does not understand why the information is required or believes the recipient has no authority to know. Henderson [1, p. 65] was often not given technical information as a technical writer, because engineers and administrators could not see why she needed to know (she received much more cooperation when introduced as a sociologist). 5.3 Information distortion

In complex organisations information is often passed on via several other people before it reaches the recipient. The generator of the information may not know the ultimate recipients at all, or does not know the recipients' needs, tasks and background, so can do little to ensure accurate transmission.

1CED 01 - C586/219

47

9. Information is oversimplified. Due to the sheer volume of information concerning a particular design, complex information often needs to be simplified or abstracted to be communicated clearly. However different team members may have different criteria for what information is relevant [see 1, p. 157], so significant details and qualifications can be left out. 10. Chinese Whispers. Information that is passed on through other people is likely to be distorted. Unless everybody knows the context, the details or emphases are likely to be changed. This applies in particular to information passed on orally. 11. Hierarchical Communication Paths. In many companies, communication between experts of the same speciality in different teams is passed on along hierarchical paths. An individual engineer alerts his group leader, who passes information on to his boss outside the particular project, who in turn passes it on the team leader of another project. Information might be passed on through six or eight different people, if there is no horizontal communication between people solving similar problems. Each person selects information as it is passed on, and relatively little information reaches its final destination. 12. Expertise of Intermediary. The people who pass on information might not have the technical knowledge to understand the implications of the information, or to argue the case for a particular technical solution. An extreme example is that project presentations to the board of directors or to clients are often made by managers or finance experts with very little technical understanding.

5.4

Interpretation of representation

The representations designers use to express design ideas and other information, and the representation-understanding skills they possess, have a powerful influence on design communication [see 3, 1, 4, 7]. The following two points are taken from observational studies and have not been commented on directly by our informants in the two interview studies. 13. Interpretation of ambiguous information is based on context. Information is often presented ambiguously or can be interpreted in more then one way. (Note that any level of abstraction can be fleshed out in different ways, without having being represented ambiguously.) The recipients interpret this information based on their own experience and context, which will not be exactly the same as the originators' [8, 3; see 4, 7]. 14. Recipients are unable to extract the required information from the representation. Many kinds of information can be displayed in a variety of different ways, some more effective than others. And many representations of designs make some aspects of the design explicit and hide others. Information can be obscured by the representation, for instance when parameter values have to be inferred rather than read directly. A representation can be vague or ambiguous to someone lacking its creator's diagramunderstanding skills [1], or be incomplete when its creator thinks it is complete.

Factors contributing to communication breakdown

Communication problems are seldom monocausal. Communication breakdowns can result from a combination of several problems; so resolving one issue in isolation may be insufficient. For instance, our study of the knitwear design process found a communication bottleneck caused by technicians doing detail design interpreting incomplete and inconsistent

48

1CKD 01 - C586/219

specifications according to their own experience [8]. A variety of cognitive, social, organisational and cultural factors contribute to the problem; Eckert [8] argues that the key issues are the difficulty of creating consistent and unambiguous representations costeffectively, and failure to recognise difficulties as stemming from communication problem. Bucciarelli [2] points out that interaction and communication across different object worlds (the sets of objects, attributes and relationships that people with particular experience and expertise think with) is always potentially problematic. In our study in the aerospace industry we found that mapping problems are amplified the further the other object world was away from the designers' own experience. For example the stress engineers and mechanical engineers who work closely together could make reasonable sense of each other's assertions, while neither group had any understanding of the constraints and needs of avionics specialists, with whom they rarely interact. In our interviews designers have commented again and again on the importance of personal connections and informal communication. People who have once worked together, for example for the same past employers, talk to each other. People moving between departments often create links between those departments; for example if a load expert is moved to the stress department, he will think about the load implications of his stress analysis. Suppliers are often a conduit of information between competitor companies. Contractors move between different companies in the same industry; while they are bound by confidentiality, they transfer the approach to solving problems from one job to the next. Not surprisingly, communication works best when people can meet each other easily. Communication on the same site will always be easier than between different locations, though technology supporting remote meetings with shared workspaces is proving effective in commercial use.

Conclusions

Communication can fail at every stage shown in the figure. Many problems simply arise from information about the product and the process not arriving at the right person in the right way. In other cases designers do not have the background information to make the right inferences from the information that they are given. Our studies highlight the importance of minimising distortion, by ensuring so far as possible that information is conveyed by people who fully understand it, and that information can be traced back to its sources. They reinforce the wellrecognised finding that one key to effective knowledge management is enabling the people who have the knowledge to talk to each other. Ensuring the accurate and timely delivery of appropriate information is a less tractable problem. In complex processes information flow is always problematic and difficult to support. Only if designers know where information is coming from and where it needs to go can they communicate effectively. We are working on tools for planning and managing dynamic design processes [12] based on the parameter values exchanged between tasks, and developing visualisation techniques for design process that make these dependencies and connections salient [13]. Ackowledgements This research was funded by the EPSRC Rolling Grant to the Cambridge Engineering Design Centre. We are grateful to our informants for the time and trouble they took talking to us.

1CED 01 - C586/219

49

References [1] [2] [3] Henderson, K., "On line and on paper", The MIT Press, Cambridge, MA, 1999. Bucciarelli, L.L., "Designing Engineers", The MIT Press, Cambridge, MA, 1994. Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies oi Group Engineering Design Practice", PhD Thesis, Department of Mechanical Engineering, Stanford University, 1991. Xerox PARC report SSL-91-22. Stacey, M.K. and Eckert, C.M., "Against Ambiguity", Computer Supported Cooperative Work, in press. Stacey, M.K. and Eckert, C.M., "Managing Uncertainty in Design Communication", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001. Brereton, M.F., Cannon, D.M., Mabogunje, A. and Leifer, L.J., "Collaboration in Design Teams: Mediating Design Progress through Social Interaction" in N.G. Cross, H.H.C.M. Christiaans and K. Dorst (eds), Analysing Design Activity. John Wiley, Chichester, UK, 1996, pp. 319-341. Stacey, M.K., Eckert, C.M. and McFadzean, I, "Sketch Interpretation in Design Communication", Proceedings of ICED'99, Technical University of Munich, Munich, Germany, vol. 2, pp. 923-928, 1999. Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis and Computing Solutions", Computer Supported Cooperative Work. 2001. Marsh, J.R., "The capture and utilisation of design experience in engineering design", PhD Thesis, Department of Engineering, University of Cambridge, 1997.

[4] [5] [6]

[7]

[8] [9]

[10] Eckert, C.M., Zanker, W. and Clarkson, P.J., "Aspects of a better understanding of changes", Proceedings of ICED'0l. PEP, Glasgow, UK, 2001. [11] Eckert, C.M. and Stacey, M.K., "Dimensions of Communication in Design", Proceedings of ICED'0l. PEP, Glasgow, UK, 2001. [12] Stacey, M.K., Clarkson, P.J. and Eckert, C.M., "Signposting: an AI approach to supporting human decision making in design", Proceedings of the ASME 20th Computers and Information in Engineering Conference, University of Maryland, Baltimore, USA, 2000. [13] Clarkson, P.J., Melo, A. and Eckert, C.M., "Visualization of Routes in Design Process Planning," Proceedings of the IEEE Conference on Information Visualization. London, 2000, pp.155-154. Dr Claudia Eckert and Dr P John Clarkson Engineering Design Centre Department of Engineering University of Cambridge Trumpington Street Cambridge CB2 1PZ Phone: 0044 1223 332758 Fax: 0044 1223 332662 Email: {cme26,pjc10}@eng.cam.ac.uk IMechE 2001 Dr Martin Stacey Department of Computer and Information Sciences De Montfort University Kents Hill Milton Keynes MK7 6HP, UK Phone: +44 1908 834936 Fax: 0044 1908 834948 Email: mstacey@dmu.ac.uk

50

1CED 01 - C586/219

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DESIGN CASE RELEVANCE IN QUANTITY DIMENSION SPACE FOR CASE-BASED DESIGN AID
T Murakami, J Shimamura, and N Nakajima

Keywords: Classification and retrieval, design reuse, similarity, case-based reasoning, data mining

1 Introduction
Nowadays, designers must consider an increasing number of issues such as product liability and environmental friendliness as well as functionality and performance of artifacts. Supporting such complicated design processes by compiling design knowledge and information and making use of them is becoming more important. There are two approaches to such design aid: one is to prepare a general building block library or knowledge base for design problems (e.g., [1]), and the other is to store past designs and extract valid knowledge and information for new design problems case by case. For the latter approach, we have studied a computerized retrieval of kinematic designs to possibly achieve a required behavior using geometrical pattern matching [2]. To cover design problems more generally, however, we need a computerized retrieval method based on a wider range of physical phenomena. The aim of this study is to propose the idea of a quantity dimension space as a basis for casebased design aid. First, quantity dimension space is defined to characterize various designs and design-related terms using relevant physical quantities. Then similarity and relevance between various designs and terms is defined in the space. By applying the proposed method to examples of various designs and terms, its efficacy and feasibility is examined.

2 Characterizing design-related concepts by physical quantities

In a mechanical design process, some physical phenomena to fulfill the design requirement (typically specified as purpose and function) are selected. Then physical entities that produce the phenomena are determined. Therefore, many concepts used in design processes are relevant to (physical) quantities. When designing a hydraulic cylinder, for example, we should consider and calculate quantities such as the "force" to be generated, "pressure" of fluid and "area" of the cylinder as in Figure 1 (The design case "hydraulic cylinder" in Figure 1 is described hierarchically by containing sub design cases such as "cylinder tube inner diameter" and "cylinder tube thickness"). The design of an electric motor, on the other hand, should contain "torque", "electric current" and "voltage". When designing an artifact to "move" something, we should consider quantities such as the "mass" of the object, required "force", required or resulting "velocity" and "acceleration" as in Figure 2. To "transmit heat", on the other hand, the relevant quantities should be "temperature", "thermal conductivity" and "heat". Thus, many concepts such as design cases

ICED 01 - C586/301

51

and design-related terms (e.g., "move" and "transmit heat") in design processes can be characterized by relevant quantities.

Figure 1. Design Case Description Example

Figure 2. Term Description Examples

3 Representing design-related concepts in quantity dimension space

To formalize this concept characterization using quantities, we propose a quantity dimension space. A quantity, e.g., 9.8 m/s2, is represented by its magnitude and unit (for example, [3]). In SI units, all units are composed of the nine fundamental units "m", "kg", "s", "A", "K", "mol", "cd", "rad" and "sr". These nine units can define orthogonal axes to define a mathematical space, which we call "quantity dimension space". A unit dimension of a quantity is a nine dimensional vector in this space: [length mass time electric-current thermodynamic-temperature amouni-of-substance luminous-intensity plane-angle solidangle}. For example, a unit N for a force is (mass^l) * (length^l) / (time^2) which is (length^1) * (mass^l) * (time^-2), thus it becomes [1 1-2 0 0 0 0 0 0]. Since a design-related concept such as a design case or a term is characterized by a set of quantities as explained before, it can be represented as a cluster of vectors in the quantity dimension space. Figure 3 depicts terms "move" and "transmit (electricity)" plotted in the

52

ICED 01 - C586/301

quantity dimension space (Only three axes are depicted for comprehensiveness). In this representation, design-related concepts with similar physical quantities share some vectors and make similar and overlapping clusters, whereas concepts with different physical quantities share few vectors and make different or separate clusters. Therefore, we can mathematically define similarity between concepts by defining distance and similarity between vectors and clusters.

Figure 3. Cluster in Quantity Dimension Space

4 Defining physical quantity similarity in quantity dimension space

First, we define a "distance" between two quantities based on a vector distance in this space. We define a vector representation vi of unit dimension of physical quantity qi as follows (Subscript i is to identify multiple quantities and vectors).

Here we define a distance dq between two quantities qi and qi based on city-block distance (Figure 4).

Figure 4. Distance in Quantity Dimension Space (Depicted two dimensionally for comprehensiveness.)

ICED 01 - C586/301

53

We use a city-block distance because Euclidean distance makes the difference about multiple axes closer than the difference about a single axis (e.g., Euclidean distance between N and N/m2 is 2 and v^2 between N and kg/s), which does not seem adequate. By this definition, dq has the following properties: 0<dq, d q (q i qj)= dq(qj, qi). Similarly to vi, we introduce an appearance vector ai. If a fundamental unit appears in quantity unit definition, the element is 1 regardless if the unit is eliminated in the final form. If a fundamental unit does not appear from the beginning, the element value is 0. When the unit of qi is N/m, for example, N/m = m1*kg1*s-2*m-1=kg1*s-2 and thus vi =[0 1 - 2 0 0 0 0 0 0], in which the first element for length is 0 because length is finally eliminated. However, ai = [1 1 1 0 0 0 0 0 0] because length appears in the definition even only intermediately. Here we define a similarity sq between two quantities qt and qj using the distance dq as follows. Two equal quantities make the distance 0 and the similarity 1, and increasing distance decreases similarity to 0.

The scalar product of appearance vectors ai and aj in the right-hand of the definition has the following properties. - The value is between 0 and 1, and is higher when more units appear, even intermediately, in common in the definitions of two quantities. - When no common fundamental unit appears in the definition of two quantities, the value is 0. For example, two appearance vectors a3 and a4 of the vectors V3 (area) and V4 (time) in Figure 4 are orthogonal and thus their scalar product is 0. - However, if some common fundamental units appear in the two quantity definitions, the value is not 0 even when two vectors are right-angled. For example, vectors vi and V2 in Figure 4 are right-angled but the scalar product of their appearance vectors is not 0 because a1 and a2 share time and length. - Even when two vectors vi and vj are dimensionless, the value is higher when the original quantity definitions are more similar because appearance vectors ai and aj hold the information. By this definition, sq has the following properties: 0 < Sq< 1, sq (qi, qj)= sq (qj, q,).

5 Defining similarities of physical quantity clusters

Then we define a similarity of two clusters in the quantity dimension space. By using similarity sq between two quantities, we define similarity sc of cluster ca to cluster c/, as follows. For each quantity <?, in cluster ca , we calculate similarity between that and quantity qj in cluster cb, which is most similar to qt.

54

ICED 01 - C586/301

By this definition, sc has the following properties.

6 Implementing concept relevance calculation program

We implemented a program to load descriptions of design cases and terms, represent them as physical quantity clusters, and calculate similarities in the quantity dimension space in an object-oriented Lisp [4]. Design cases can be defined hierarchically as in Figure 1. A case can be either a detailed description containing all calculation sequence as in Figure 1 or just a collection of characteristic physical quantities obtained as a product specification information from catalogs. In our implementation, a design case is considered to have all physical quantities in its sub cases, in other words, a physical quantity cluster representing a design case contains all physical quantity clusters representing its sub design cases. Although we calculate a "similarity" of physical quantity clusters representing design cases and terms, we use the words "similarity" and "relevance" in this paper in the following sense. - "Similarity" is for the same type of concepts (For example, "similarity of two design cases", and "similarity of two terms"). - "Relevance" is for the different types of concepts (For example, "relevance between a term and a design case").

7 Examples of similarity/relevance calculations

For testing our implemented program, we define 18 design cases, which contain 24 child cases. Part of which are listed as follows. "digital Roentgen" "dyeing and finish process using super high pressure" "extruder" (d4-l) "cylinder", (d4-2) "cylinder thermoregulator", (d4-3) "hopper", (d4-4) "screw", (d4-5) "speed reducer", (d4-6) "spiral die" (d6) "hydraulic cylinder" (d6-l) "cylinder tube inner diameter", (d6-2) "cylinder tube thickness", (d6-3) "piston", (d6-4) "seal between piston and tube", (d6-5) "seal between tube and blocks" (d7) "inspection using X-ray CT" (d8) "micro actuator in blood vessel" (d8-l) "silicon tube" (d9) "micro gripper" (d9-l) "smacoil" (d10) "photofabrication of lenses utilizing surface tension of photopolymer" (d11) "precision analysis of carbon and sulfur in metal" (d13) "Rapid Prototyping system" (d13-l) "elevator", (d13-2) "laser", (d13-3) "resin" (d2) (d3) (d4)

ICED 01 - C586/301

55

(d14) "Solid Ground Curing" (d14-l) "elevator", (d14-2) "resin", (d14-3) "UV" (d17)"zetpol" Also, the following 18 terms to represent behaviors are defined: "bury", "compress", "cool", "expand", "extrude", "fill", "fix", "grip", "heat", "hold", "insulate (electricity)", "insulate (heat)", "move", "transmit (electricity)", "transmit (heat)", "transmit (light)", "turn", "vibrate". Using our program, we calculated average bi-directional similarity/relevance, in other words, for one design case or term A and every other design cases and terms X, we calculated [sc(A, X)+sc(X,A)]/2.

7.1 Similarity between design cases

Similarities between the design case "digital Roentgen" and other design cases, such as (d7) "inspection using X-ray CT" and (d6) "hydraulic cylinder", were calculated. Figure 5 shows the sorted result. Electricity-related design cases generally exhibited higher scores; these comparisons can be used to search for past design cases similar to a current design case.

Figure 5. Similarity between design case "digital Roentgen" and other design cases

Figure 6. Relevance between term "compress" and design cases

7.2 Relevance between terms and design cases

Relevance between the term "compress" and all design cases, such as (d6) "hydraulic cylinder" and (d2) "digital Roentgen", were calculated. Figure 6 shows the sorted result.

Pressure-related design cases generally exhibited higher scores; these judgments can be used for a behavior- or function-based search of design cases.

7.3 Similarity between terms

Similarity between the term "cool" and other terms, such as "heat", "transmit (heat)", "move" and "transmit (light)", were calculated. Figure 7 shows the sorted result. Heat-related terms generally exhibited higher scores; these comparisons can be used to make a dictionary of synonyms.

Figure 7. Similarity between term "cool" and other terms

8 Discussions
The method proposed in this paper itself is not a case-based design aid but should be a component technique to achieve such design aid. By extending and combining the proposed idea to conventional keyword-based searches, this approach should provide an effective method for design aid using case-based reasoning, knowledge discovery and data mining. Although not used in this paper, our descriptions of design cases and terms can contain keywords by some strings as well as physical quantities in Figures 1 and 2. Now we are working on defining similarity based on both physical quantities and keywords. We represent a design case and term as a cluster of physical quantities and no structure among quantities are not considered. In actual design cases, however, there are structures among physical quantities such as calculations (in a design of a hydraulic cylinder for example, tube thickness is calculated from pressure). By representing such structures as networks among quantities and taking them into account, we can probably define more precise and accurate similarity between design cases and terms. In some studies on case-based design aid (e.g., [5]), attribute names and their values (typically implemented as slot names and their values in an object-oriented approach) are used to

ICED 01 - C586/301

57

estimate relevance between cases. That approach should be appropriate to achieve efficient reasoning when the domain is rather fixed (for example, architectural design) and the slot names can be unambiguous enough as keys for reasoning. On the other hand, the motivation of our study is to establish a method to cover wider range of engineering design using physical phenomena. The reason we came up with the idea of quantity dimension space is that any physical quantity in the past, present and future design problems can be objectively and unambiguously compared with nine fundamental units even when the name or keywords assigned to the quantity may be subjective, ambiguous and different by persons or technical domains. Of course, a method using physical quantity alone should have problems of poor descriptive power and inefficient reasoning. To find a good combination of the idea in this paper and other available techniques should be necessary for achieving practical design aid.

9 Conclusions
In this paper, a quantity dimension space defined based on the nine fundamental SI units was proposed, and similarity between design cases and design-related terms were mathematically defined in the space. The similarity calculation results for several examples of design cases and terms show that the quantitatively calculated similarities seem making sense in general. Our next directions include verifying that our mathematically defined similarity matches designers' comprehension quantitatively and constructing a design aid technique based on the methods in this paper. This work is partly supported by "Modeling of Synthesis" project (JSPS-RFTF 9600701) in the "Science of Synthesis" research field of the Research for the Future Program, Japan Society for the Promotion of Science. References [1] Umeda, Y., Ishii, M., et al., "Supporting Conceptual Design Based on the FunctionBehavior-State Modeler", Artificial Intelligence for Engineering Design. Analysis and Manufacturing. Vol.10, No.4, 1996, pp.275-288. Murakami, T. and Nakajima, N., "Mechanism Concept Retrieval Using Configuration Space", Research in Engineering Design. Vol.9, No.2, 1997, pp.99-111. Gruber, T.R. and Olsen, G.R., "An Ontology for Engineering Mathematics", Fourth International Conference on Principles of Knowledge Representation and Reasoning. Morgan Kaufmann, 1994. Matsui, T. and Kara, I, EusLisp version 8.00 Reference Manual Featuring Multithread and XToolKit. ETL-TR-95-2, Electrotechnical Laboratory, Agency of Industrial Science and Technology, 1995. Maher, M.L. and Garza, A.G., "Developing Case-Based Reasoning for Structural Design". IEEE Expert. Vol. 11. No.3. 1996, pp.42-52.

[2] [3]

[4]

[5]

Tamotsu Murakami Department of Engineering Synthesis, The University of Tokyo, Kongo 7-3-1, Bunkyo-ku, Tokyo 113-8656, Japan, Tel: +81-3-5841-6327, Fax: +81-3-3818-0835, E-mail: murakami@design.t.u-tokyo.ac.jp, URL - http://www.design.tu-tokyo.ac.jp/ IMechE 2001

58

ICED 01 - C586/301

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A WEB-BASED INFORMATION TOOL FOR APPLICATION ENGINEERING

J Schmidt and D G Feldmann

Keywords: Fluid power, intranet, knowledge acquisition, product data management.

Introduction

Nowadays increased global competition forces companies to intensify and structure the information flow between the departments and enterprises to be successful on the market with its grown technological and economical challenges in product development. Time to market decreases; development time can be substantially shortened by introducing innovative communication and information tools, which enable the project teams to work on the basis of a common development platform. Particularly the early phases of product development offer a large potential for development time reduction and for later product quality improvement; because of missing tools for data processing this potential is not exhausted yet. The variety of possible design solutions at the early phases, coupled with an often bad information quality, i.e. incomplete and unstructured tasks, leads to delays in development and negatively affects the product quality. The Institute for Mechanical Engineering Design of the Technical University HamburgHarburg is developing a product model based tool for application engineering of hydrostatic systems, which supports the early stages of product design. To guarantee that all employees of the company have access to product data and design knowledge via Intranet the tool is WEBbased. Increased data processing support especially in the early stages of product development requires computer-supported acquisition of the task which is offered by the tool. Additionally different modules support the solution identification process by supplying design experience and giving access to realized solutions. Circuit diagram creation, selection of components, system simulation, error estimation and 3D-layout of the hydrostatic system are also supported by the tool. Central component of the engineering tool is a product model, defined especially for hydrostatic systems, in which all product specific analysis and synthesis data are stored. The design of the hydrostatic system, thus the filling of the current product model with information, takes place with help of IT-tools, which support the several stages of product design, following the "VDI guideline 2221" [1].

ICED 01 - C586/147

59

The structure of the Application Engineering Tool

The widely hardware independent client-server-architecture of the tool allows distributed project teams to develop several new products at the same time; thereby the designers always have access to a current base of product data. The design construction and experience which is structured in a central database can be used systematically to develop new products. The development stages in the conventional engineering process are supported by use of several closed and platform-dependent tools such as text processing systems, programs for spread-sheet analysis, CAD systems and simulation programs. The variety of programspecific and thus usually not compatible data formats represents a weak point; there is no central data management implemented, whereby redundancies and inconsistencies in the data pool accrue, which can lead to delays in product development and may cause quality losses. The available programs represent isolated solutions, so that a constant computer support for all planning and design phases is due to missing or only insufficiently operating interfaces not possible. Especially the missing computer supply in the early phases of product development is a considerable weak point of the conventional product development process. There are no tools available for a systematical entry and evaluation of the task, that often leads to incomplete and unstructured tasks. Considerable delays in the later stages are the result, that often causes iteration cycles, which increases time to market. With the following concept of a WEB-based application engineering tool for hydrostatic systems a constant computer support of all planning and design phases becomes possible. The engineering tool supports the systematic solution search by supplying design experience and design notes. A product model particularly defined for hydrostatic systems contains the data

Figure 1: Structure of the Application Engineering Tool

60

ICED 01 c586/147

structure and saves the product-specific information; the product-independent data are stored in a "static" area of the data base. For circuit diagram generation and simulation of the solution concepts a commercial simulation tool is connected to the IT-tool by an interface. A specific kind of value analysis tool is used to select the best concept. In figure 1 the structure of the application engineering tool is represented in principle. Four interlaced modules for information input, information storage, information extraction and visualization form together the structure of the engineering tool. With consideration of the heterogeneous information of the planning and design phases, separate IT-tools have been developed, which support data processing and storage in the respective development stage. The product model, which is specific for each product, enables the structuring and central storage of the information. The product model contains the entire information to a product. During the development process quantity and quality (accuracy and completeness) of information in the product model grow. If a project is in its final stage, i.e. an optimal solution concept has been identified, the project manager finishes the development process. Thereupon the system modifies automatically the access rights for the current product model. From this point in time the product model is fixed and represents new design experience, available for following projects and development stages. Only the project manager or one of his assigned coworkers can make subsequent modification of "fixed" product models, which may be necessary to correct faults or optimize the design as a result of application experience; in such a case they have to use the design tool. All static and not product-specific information such as rules, component libraries, experience data and also the product model are administrated in a relational data base. Access to the data base take place by means of SQL queries, which are initialized by the IT-tools. The information system represents the interface to the user. For the entire development process a uniform user interface was implemented. WEB-browser are used to visualize the ITtools, these user interfaces are available in each modern enterprise as a standard. The conceptconditioned client-server-architecture allows a distributed and parallel operating in the company-wide Intranet and guaranties, that inconsistencies and redundancies in the data base are avoided. For user acceptance data security is important. Here must be differentiated between worldwide and enterprise-spreading information exchange in the Internet and local data transfer in the Intranet of the company. The compliance of safety requirements at the enterprise-internal Intranet can be ensured by password-controlled access rights; that however presupposes that no connection to the Internet exist. If there is a demand to access over the enterprise boundaries beyond Internet, far more complex safety mechanisms are necessary. At present these usually server-lateral mechanisms offer still no total protection from abuse by unauthorized persons. That concerns in the long run the entire area of e-Business, why developers of WEB-browsers and servers do a lot to increase data security. The developed engineering tool uses the currently available safety mechanisms of browsers and servers.

The computer supported process of product development

To explain the functionality of the Application Engineering Tool in the following all planning and design phases are (exemplarily) passed. The engineering process for a hydrostatic system begins with the computer supported entry of the task followed by the solution concept

ICED 01 - C586/147

61

identification, continues with the circuit diagram creation, simulation and concept evaluation and ends with the selection of components and a first geometric layout.

3.1

Definition of the design task

The identification of a product idea is the first step in the development process, which is put down either by a customer or by a department of the company. The first requirements on the new product are typically incomplete and unstructured and they are documented in form of discussion logs, simple CAD documents or also handwritten tables, sketches and diagrams. In this early phase the computer support of the engineering tool begins; all documents are stored via digitization in a database, i.e. in a new product model. For a first structuring the collected information is divided into request classes. According to standard the classes technical requests, economic requests and organizational requests are predefined at the engineering tool. The coworkers of a project group are informed about task modifications automatically by email and they are obliged to acknowledge their notice of the modifications in the system; thereby all team members have the same knowledge status. So communication problems caused by inconsistencies of the task can be avoided at an early point in time.

3.2 The clarification of the task definition

The task definition and the clarification of it, commented in the following, are coupled. Both phases will be gone through in an iterative process until a sufficiently structured and complete task definition can be formulated; the release of the task definition is usually made intuitively by the project manager. The use of the design tool shortens this process and ensures a structured formulation of the problem, based on product functions. The representation of the technical requirements by product functions has the advantage that it does not limit the set of solutions in advance by the determination of components. The review of the task definition concerning completeness is made easier by the functional description of requirements and can be to a high extend carried out automatically by the engineering tool. The simplified presentation of the Functional Product Structure (FPS) shown in figure 2 captures the product functions necessary for the representation of the requirements. The product functions are structured by dividing them into the groups output, control, input, fluid conditions and maintenance. These groups contain in a hierarchical structure all product functions that have been defined within the frame-work of previous projects. The groups are predefined for the first deployment of the design tool and will be adapted and extended according to the needs of the company along with the number of completed projects. In order to clarify the task definition the project team assigns the requirements defined within the frame-work of the problem description to the product functions necessary for the performance. If for example a linear output is requested as a part of a new system, the project designer firstly calls up the class of output in the Functional Product Structure and limits the possible number of product functions by selecting the necessary main function, here supply translational motion. The project designer is now provided with the next range of functions in the functional hierarchy. Five steps are needed as a rule to reach the level of basic functions that make it possible to completely describe the requirements. Each function is so described by a set of clearly defined and product-independent attributes and characteristics. Should it not be possible during the task clarification to indicate specifications for all attributes provided by the system, it is an indication towards an incomplete task formulation.

62

1CED 01 - C586/147

Figure 2: Functional Product Structure (FPS)

The correspondent function is marked accordingly by the engineering tool. All not completely cleared product functions are automatically summed up in a report and can then be discussed with the customer or the concerned departments. The project task is only released by the system, when all product functions are finally cleared or the yet unknown features are marked as "to be cleared" upon authorisation of the project manager. If none of the systems existing product functions is able to describe the task, it is possible to define a new function with its characteristics and attributes. In order to ensure the consistence of the Functional Product Structure and the integrated data structure a number of further entries - omitted here - have to be made to release newly defined functions.

3.3 The systematic generation of a concept

The use of the engineering tool supports the systematic access to the experiences from previous projects. The design experience that is stored in the models of previous projects can be extracted through search patterns defined by the customer requirement specification (at this time already structured), which will identify correspondences and similarities of new product models with stored product models of previous projects. The search patterns structured accordingly to the groups of requirements do not have to be defined newly for each project. The tool provides the project designer with a standard search pattern for repeatedly developed systems that needs only to be fine tuned according to the current problem definition. As a result of the search the project designer is supplied with a catalogue of preceding projects with similar models which can be used as a basis for new concepts. The search results are ranged according to the priorities of the requirements of the task definition by weighing the search parameters in the search patterns of the different requirement groups. The suitability of preceding projects for new developments is defined by establishing a limit value of conformity. The basis for the step from concept to realization is the Function-/ Function Carrier Matrix. The matrix is product-independent and represents the connection between the Functional Product Structure and the Function-Carriers, defined as a mathematical and geometric description of real hydrostatic components. Function-Carriers can be single components such as a cylinder as well as complex components like a speed control unit. In

ICED 01 - C586/147

63

addition to this functional description they are assigned symbols for circuit diagram generation as well as the technical system data required for the optimization of control engineering. The symbols and the parameters needed for the simulation correspond to the simulating program connected with the tool. A function carrier can perform more than one function of the FPS and the other way round one and the same function can be performed by different function carriers. The Application Engineering Tool provides the project group with a requirement-specific Function-/ Function Carrier Matrix for solution finding, where every required product function is assigned to all known workable function carrier; every new project enlarges the scope of the Function-/ Function-Carrier Matrix. By choice and by combining different Function-Carriers various solutions are generated. The engineering tool must not hinder creativity by working with or offering only known solutions; the demand for a high product quality requires a constant optimization of products, therefore the project designer is enabled to develop and compare various concepts. As in common product development the creativity of the project designer is of great importance; the engineering tool encourages creativity since it offers all Function-Carriers known to the company for each required product function together with an explanation of their pros and cons. The constantly methodical approach and the subject-related access to the basis of decision-making in preceding project developments also promote the optimization of the development process.

3.4 The simulation, choice of components and evaluation

The examination of the performance of the developed concepts is carried out with an existing commercial program that is able to generate circuit diagrams as well as to simulate the static and dynamic system performance. This program is an integrated part of the engineering tool in the way that the project designer is provided with a concept-specific library of components on the user-surface of the simulating program. These libraries contain all of the FunctionCarriers respectively their hydrostatic symbols needed to describe the concept developed within the frame-work of the design; the symbols are combined in groups analogue to the Functional Product Structure, thereby a clear allocation of the symbols in the circuit diagram of the hydrostatic system becomes possible. In order to generate the circuit diagrams and for the simulation the internal functions of the simulating program are used. A detailed description of the software would go beyond the scope of this paper. A condition for an automatic choice of devices is the disposability of the technical specifications of the used hydrostatic components in a digital form; such as technical data sheets, operating instructions and geometrical descriptions in the form of 3D-CAD-models. The experiences gained from previous projects with these components are stored in the data base and can be taken into consideration. The allocations of the component data to the Function-Carrier deduced from the task definition is carried out automatically on the basis of the product-independent Function-/ Function-Carrier Matrix; apart from the local component data there is the possibility in principle to use electronic component libraries in the internet, although this would presuppose a standardized and company-independent language of description that has not yet been defined for the fluid technology. The evaluation of the system concept concerning the fulfillment of the task definition is the last step in the frame-work of design. The weighted marks according to VDI guideline 2225 [2], in a computer-supported method came into use as a method of evaluation. This method stands out due to its easy handling and clarity. As a result of the assessment a priority of possible product concepts is provided and the optimal product concept can be chosen.

64

1CED 01 - C586/147

The realization of the Application Engineering Tool

After the data structure and the flow of information had been deduced in the form of ERmodels from the concept of the engineering tool, the main emphasis of the project work was the predefinition of the actual data bank structure, i.e. the definition of the relations, their entries and keys. The used relational data base can be divided into a product-independent static part and in a product-specific dynamic part; the product model that clearly describes every product concept is member of the dynamic part of the data base. Through data bank inquiries views on the internal sections of the product model are opened that enable the project designer to be informed via internet/intranet about the state of the project or respectively to further develop the project through the input program. The interface between user and engineering tool is the web-browser installed at every working place in the company. The project designer "communicates" through the internet/ intranet with the computer system via interactive forms, i.e. http-inquiries are sent to the web-server; e.g. a http-inquiry contains a html-form from the project designer that contacts the data base in order to store the data. A commercially available interpreter (CF-server) was installed between the web-server and the data base since a common web-server is not able to interpret a html-source coding with integrated data base inquiries. The investigations for the development of an internet-based information system by Stritzke [3] confirm the advantages of such a software. The html-form, shown as an example in figure 3, is used to acquire the initial data of a new project; the illustration should give an impression of the arrangement of the user-interface of the engineering tool. Apart from forms like this, tools such as charts, graphics and trees will be used to visualize and acquire information; tools for the construction of state-diagrams or for the visualization of 3D-CAD-data have to be taken into consideration as well.

Figure 3: HTML-form to initialize a new project

ICED 01 - C586/147

65

Summary and Conclusions

As a result of the computer-supported project design with the here presented tool an optimal design of a hydrostatic system is available considering the evaluation criteria. From the hydrostatic and control engineering point of view, this design contains an optimal hydrostatic circuit with its components assigned to the parameters of available devices. All information that is handled or produced in the course of project design is stored in the product model of the system for the product development of future products. Next to the basic primary task definition of the customer and its changes, the Functional Product Structure, the concepts, the results of the simulations, the circuit diagrams and lists of parts as well as all decisions and comments of the concerned project group is documented. Since the number of available and completely filled product models increases with the run time of the IT-tool, a growing supply of experience can be used for the development of new products. Commercial programs will be tied in for the design of the circuit diagrams and the simulations. The design tool is based on a client-server-architecture that supports simultaneous engineering on one hand and allows the control of "workflow" on the other. The further development of the design tool will provide tools for the geometrical design of the hydrostatic systems specified in the product concept. The aim is to make statements about possible collisions between devices or dimensioning errors in the project design stage of the product, using a 3D-geometrical model. With the help of a so-called assembly model the project designer can arrange early remedial measures, like selecting different devices, in the case of inconsistencies on a new or modified construction. The hydrostatic devices are assigned simplified geometrical models in order to keep the amount of geometric data low for the assembly research. The assembly model of the hydrostatic system consisting of these "configuration models" of components is composed out of simple geometries like cuboids and cylinders. Only the functional surfaces and volume units important for the assembly and the dimension rating of these simple geometries are completely worked out, e.g. the position for holes, casing surfaces or the fastening threads important for assembly. References [1] [2] [3] VDI-Richtlinie 2221. "Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte", VDI-Verlag, Diisseldorf 1986 VDI-Richtlinie 2225. "Konstruktionsmethodik, Technisch-wirtschaftliche Bewertung", Blatt 3, VDI-Verlag, Dusseldorf 1990 Stritzke, H. Intemetgestiitztes Informations- und Kommunikationssystem fur verteilte Projektteams am Beispiel der Produktentstehung. Dissertation. Fortschrittsberichte VDI Reihe 10 Nr. 569. VDI-Verlag, Dusseldorf 1999.

Prof. Dr.- Ing. D. G. Feldmann, Dipl.-Ing. Jens Schmidt. Technical University Hamburg-Harburg, Institute for Mechanical Engineering Design, Denickestrasse 17, 21073 Hamburg, Germany, Tel: +49 40 42878 3231 , Fax: +49 40 42878 2296, E-mail: jens.schmidt@tu-harburg.de , URL - http://www.tu-harburg.de/ktl /deutsch /index.htm IMechE 2001

66

ICED 01 - C586/147

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

AN AGENT ENVIRONMENT TO SUPPORT CO-ORDINATION BETWEEN DESIGN ACTORS

P Girard and C Merlo Keywords: Design information management, knowledge acquisition, knowledge management, product data management, collaborative design.

Introduction

The investigated domain is the modelling of the design system. We focus on the relations between the decisional system and the technological system through the informational system, according to the methodology [1] developed by GRAI (Groupe de Recherche en Automatisation Integree). The objective is to define this informational system in order to support engineering design co-ordination [2]. In previous work, multi-agent concepts have been applied to the modelling of design knowledge, according to the design system model, as proposed in [3]. This contribution details the architecture of the multi-agent system and specifically of the product agents. We describe the objectives, the links with the environment to support design co-ordination, the mathematical definition and the architecture of product agents. Then we discuss the results of a first experiment to validate the proposed concepts.

GRAI approach in engineering design

Considering the expansion of co-operative design, involving numerous and heterogeneous teams, the GRAI approach proposes a model of the design system with the aim of improving the performance of product engineering design. The GRAI reference model describes the engineering system (figure 1) as two subsystems: the decisional system and the technological system. These two systems converse through a third one, the informational system. The decisional system co-ordinates and synchronises the technological system which transforms information flows into product knowledge.

Figure 1. The design system

The decisional system is formalised through a double decomposition: on the basis of a time

ICED 01 -C586/156

67

criteria defining strategic, tactical and operational decisions which represent three different levels of granularity, and on the basis of a functional criteria defining product or project oriented decisions. The decisional system is divided into local decision centres according to this fractal decomposition. Each of them controls a design centre in the technological system which transforms specific requirements into product and route sheet definition [4]. For example at a strategic level, a design centre can be in charge of analysing the requirements to propose a decomposition of a design project into several steps, and at an operational level a design centre will be in charge of a calculation activity or a sub-assembly detailing task. [5] have demonstrated the need of archiving design knowledge in the design centres, in order to send back information to the decisional centres and to facilitate the control and the coordination of design. The informational flows of design centres are formalised using a product model and a process model: the product model is based on a functional description, including also structural and first geometric representations, through three types of elements: functions, technological entities and boundary entities. For example in the first steps of the design of a multi-spindle machine tool the function "to bind completely" is related to two technological entities TE: "Drilling machine interface" and "Pinion". For this function the TE are specified by boundary entities: an axis and a point to define their relative position. The process model archives the activities of the design centres and at each activity is associated a state epk of the product model. The analysis of design knowledge in the design system shows the needs of communication and co-operation between the actors, the flexibility of their organisation and the needs of capitalisation. These conclusions led us to apply multi-agent concepts to the modelling of the informational system, in order to improve design co-ordination [6].

Knowledge modelling

The set of agents defined in the multi-agent system (figure 2) compose an assistance environment for the design actors, In the technological system, actors use information formalised in the product and process models. The product and process agents are in charge of storing, controlling and distributing this information in an active way, to improve the cooperation of the actors in a local design centre. The product agent uses a translation agent to display product information with a representation adapted to each design actor. A communication agent is assigned to each actor to shape, in an adapted form, the input-output information. It is an active interface between the actor and the informational system.

Figure 2. Description or the mum-agent system

Finally a set of capitalisation agents helps actors to improve the exploitation of design knowledge by extracting product, process and decisional information from current projects, or

68

ICED 01 - C586/156

by reusing archived projects. We will now focus on product agents and the links with their environment. We will show their contribution to the engineering design co-ordination.

Product agents to support design co-ordination

4.1 Product agents characteristics

Control and co-ordination of product information can be described by the following ideas: the information created by actors must respect product model rules (syntax and evolution), each information must be semantically correct according to its environment and to the actor context, non public information from an actor must be evaluated to prepare future integration with product model, public information (in work or released) must be quickly communicated to concerned actors, in order for them to take it into account.

Product agents have to respect these characteristics even if they are not in charge of all the related tasks, such as the control of the syntax of product information. But they will control the coherence of product information in relation with the actors and have a real added-value. We propose that product agents have the role of managing and controlling the product information in the area of the co-ordination of the related tasks led by the actors in the technological system. So they have to: answer to "check out" requests from an agent (an actor most of the time), using if necessary a translation agent, and respecting product model formalism, answer to "check in" requests from an agreed agent, in order to modify or to increase product knowledge by the control of the coherence of the new information.

4.2 Product agents contribution

In the technological system, product agents support design actors. First, product agents guarantee the coherence and the integrity of the product information. For this, agent tasks consist of controlling information, establishing dialogues with actors and distributing relevant information to obtain a coherent state of product information. Each agent is assigned to an actor. The actors are assigned to a design centre, so product agents are organised into equivalent groups to perform their tasks. A supervisor agent controls their activities in the area of the design centre and a global supervisor controls their activities in the area of each product. Second, product agents communicate with other agents to support design actors for the management of design knowledge. They decide to co-operate with translation agents to visualise information of the product model and with communication agents to exchange with actors. They are requested by process agents to validate a specific state epk+1 of product information and by capitalisation agents to extract information about product, In the decisional system product agents support actors making their decisions by extracting information from the product model. They are requested by capitalisation agents to access specific information from product model to reuse it to perform design activities analyses.

ICED 01 - C586/156

69

4.3 Product agents definition

We have based the description of product agents, and more generally of the multi-agent system, on the following definitions from [7]: the system contains a set of objects O; the system contains a set of agents A, which are active objects; relations R exist between objects (and consequently between agents); operations Op represent the actions from agents upon objects (and agents); operators Ok represent the effects of the operations upon the environment of the agents. These definitions led us to develop a mathematical description of the agents, we propose a graphical representation (figure 3) which is a transition between the mathematical part and the implementation. We define the product agents Ap by: their identity (nature N, function F, situation S and mechanisms M), relations Rp, operations Opp with their environment, and operators Okp upon design knowledge. We can identify the internal identity of Ap by a set of characteristics: n: type "computational agent", "name", name of the referenced actor, f: function"controlling the evolution of product information in a co-operative context", s: localisation "IP address", list of design centres to which it belongs, m: list of internal functions and algorithms, of communication protocols, . . . Then we define the integration of Ap in the environment as: 3 k agents Ahi e A, human agents authorised to access to the product model, 3 1 agents Ahj e A, human agents contacted for control, and 3 At e A, translation agent, called by the product agent, in order to adapt the visualisation to the context of the human agent Ahi, such as:

with Rp x: relations between Ap and all the Ax having access to the product model, defining their access rights. For the visualisation requests, the following two operations represent the actions that the product agent has upon its related actor, and upon a translation agent if necessary:

For the modification requests, we define the operation Op p j representing the control actions that the product agent decides to execute, and the operator Okpi happening after the positive end of this operation, and representing the update of the product knowledge:

70

ICED 01 - C586/156

with

epk-i and ep^: previous and final states of product model

Figure 3. Graphical representation of product agent

Before the implementation of an agent, several works ([8]) have demonstrated the necessity to establish a formalised architecture in order to adapt a methodology to the needs of the global system and to respect quality rules: standardised process of development, more structured process, easier maintenance, components replaceable, ... We propose that the internal architecture of product agents (figure 3) is structured into five components: the "communication model" receives or sends messages, using predefined protocols, which are parts of the mechanisms M, the "environment model" contains information to identify recipients (N, S and F from other agents, and the relations R identifying the links with them) and the mechanisms M to maintain this knowledge, the "self model" centralises the information about its own identity N, S and F. The agent can send it to be known by other agents, the "task model" defines all the basic actions of the agent, these actions are mechanisms M which are combined to obtain external actions Op and Ok, the "processing model" analyses the received information to define an appropriate strategy by combining basic tasks. This model contains the mechanisms M used for actions. This model and the task model allow the agent to act on its environment or to react.

First approach of the Product Agent implementation

We use the MAGIQUE platform [9] to experiment the implementation of a product agent. This platform is based on JAVA and proposes agent classes, communication protocols, a hierarchical organisation and the possibility to locate agents through a network. The case study is restricted to the control tasks that the product agent manages in order to guarantee product information coherence between actors. We simulate first a visualisation request and then a modification request. The developed agent analyses them and send messages to the

ICED 01 - C586/156

71

concerned actors. We have used UML formalism to analyse and to model the product agent. In a first phase, we define the context of the prototype. We focus on a design centre called BEM composed of three actors (Durand, Renard and Cunier), this centre is controlled by a decision centre called DCM. BEM actors co-operate to produce new states of product knowledge. Then we precise two situations for the tests: three valid states epo, ep1 and ep2, and two proposed states for modifications ep1m and ep2m- These states are characterised by a list of elements (functions, technological and boundary entities) that are added, modified or deleted by one actor at a time. We define three status types for each element to trace the modifications: not valid, valid (if the element depends on a valid state) or in work (proposed state). The objectives of the prototype are to test the product agent during the control phase of the modifications of product knowledge proposed by one actor from BEM. We define ApDurand = ("product agent", "Durand", "controlling the evolution of product information in a co-operative context", "173.20.20.19", "BEM", list of mechanisms). At the beginning of the simulation, Durand sends a visualisation request on the product model. Consequently ApDurand reacts and explores the product database to satisfy Durand requirements and then defines a working subset of the product model: ep1 (figure 4). ApDurand filters (task 1) the information from the database according to the organisation of design system (ApDurand uses a communication task 2 to know that), by calculating the rights (task 3) of Durand upon each element of product database. These rights depend on: the centre to which Durand belongs, the centres to which belongs the owners of each element, the rights previously associated to the element, and the rights linked to the objectives given by the decision centre DCM controlling the design centre of the actor BEM (ApDurand uses a communication task 4 to know these objectives). These rules are deduced from GRAI concepts and are based on relations such as: Rp(ApDurand , Cunier ) = { Cunier, design centre of Cunier, IP address of Apcunier }. The resulting operation is: Opp (ApDurand , Durand ) = {task 1, task 2, tasks, task 4 }.

Figure 4. Product information extracted from ep1 state

When Durand sends a new request for the update of ep1 with ep2m. ApDurand begins the control of the modifications to co-ordinate the information inside and outside the design centre. First it has to identify (task 5) all the elements added, modified or deleted since ep1, and all the elements linked with these elements according product model rules. Then for each element identified, it has to determine the actor(s) concerned by the modifications and the level of needed synchronisation (task 6): information, validation without answer or validation

72

ICED 01 -C586/156

expecting an answer. Apourand identifies Cunier and Renard as actors that need an information about the proposed modifications and it defines communication tasks 7. Relations are the same as in the previous request, and the new operations are for example: Opp (ApDurand , Renard ) = { task 5, task 6, task 7 }. Figure 5 shows the messages exchanged between ApDmand and the product agents of Cunier and Renard. After task 7, ApDurand sends a "check in" request to the product database. This task 8 defines the operator Okp (ApDurand, Durand): ep1 |-> ep2.

Figure 5. Product agent controlling product information coherence

The relations Rp i are dynamic and establish the relative situation existing between the related actor and an other actor, according to the organisation of design and decision centres. The set of tasks (task 1 to 8) is a part of the mechanisms M of the product agent. These tasks imply that the product agent will keep external information in the environment model (current organisation), or in the processing model (objectives, results of control or information messages for example). As translation agents are not implemented yet, the operations Opp t do not exist. As a conclusion, the prototype simulates the co-ordination of the evolution of product knowledge through the use of an agent for each actor from BEM, DCM and BMM. The agents can be launched on a single PC and also on different PCs over a network. Our aim is to achieve the complete description of agents using a neutral platform, and to validate the addedvalue of agents for the application of GRAI concepts in engineering design co-ordination.

Conclusion

The contribution consists on the proposal of a multi-agent system to manage the knowledge

ICED 01 -C586/156

73

evolution in design system. We focus on product agents and we define their main objectives and interests to assist actors in engineering design co-ordination. We formalise a mathematical definition and an architecture of product agent. The implementation validates part of product agent actions and needs to be improved. We must extend its abilities in order to allow the agent having a more adaptive behaviour during control actions and being less dependant from actors. We will apply this work to all agents in the informational system and define a complete environment to engineering design assistance. References [1] Doumeingts, G., Ducq, Y., "Enterprise modelling techniques to improve efficiency of enterprises", in Production Planning and Control. Taylor & Francis Publishers, Volume 12, Issue 2, 2001, pp.146-163 Duffy, A.H.B., Andreasen, M.M. and O'Donnell F.J., "Design Co-ordination", Proc. ICED '99. Munich, Germany, August 24-26, 1999 Merlo, C. and Girard, P., "Knowledge Modelling in Engineering Design Control", IDMME'2000. Montreal, Canada, May 16-19, 2000 Girard, P., Eynard, B. and Doumeingts, G. "Proposal to control the systems design process: application to manufactured products", in Integrated Design and Manufacturing in Mechanical Engineering: IDMME'98. edited by J.L.Batoz, P.Chedmail, G.Cognet and C.Fortin, Kluwer Academic Publishers, ISBN 0-7923-6024-9, 1999, pp.537-544 Eynard, B., Girard, P. and Doumeingts, G., "Control of engineering processes through integration of design activities and product knowledge", in Integration of Process Knowledge into Design Support Systems, edited by H.Kals and F.van Houten, Kluwer Academic Publishers, ISBN 0-7923-5655-1, 1999, pp.351-360 Jennings, N.R., Sycara, K. and Wooldridge, M., "A roadmap of Agent Research and Development", Autonomous Agents and Multi-Agents Systems. 1, Kluwer Academic Publishers, Boston, 1998, pp.275-306 Ferber, J., "Les svstemes multi-agents - Vers une intelligence collective". InterEditions HA, Paris (1997) Glaser, N., Haton, M.-C. and Haton, J.-P., "Models and knowledge acquisition cycles for multi-agent systems". Proceedings of 9th KAW, Banff, Canada, 1995, pp.24/0-24/20 Bensaid, N. and Mathieu, P., "A Hybrid and Hierarchical Multi-Agent Architecture Model", Proceedings of the Second International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agent Technology: PAAM'97. London, UK, The Practical Application Company Ltd, 1997, pp.145-155

[2] [3] [4]

[5]

[6]

[7] [8] [9]

Dr. Philippe GIRARD1 and Engineer / PhD student, Christophe MERLO1,2 1 Laboratoire d'Automatique et de Productique, Groupe GRAI, Universite Bordeaux 1-351 cours de la Liberation, 33405 TALENCE CEDEX, France, +33 (0)5.56.84.24.04, +33 (0)5.56.84.66.44, girard @lap.u-bordeaux.fr 2 Ecole Superieure des Technologies Industrielles Avancees, LIPSI, Technopole Izarbel, 64210 BIDART, France, +33 (0)5.59.43.84.33, +33 (0)5.59.43.84.01, c.merlo@estia.fr (c) With Authors 2001

74

ICED 01 - C586/156

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DEVELOPING A SUPPORT SYSTEM FOR NOVICE DESIGNERS IN INDUSTRY

S Ahmed and K M Wallace

Keywords: Design understanding, knowledge management, cognition and learning process, and training of designers

Introduction

Recent studies suggest that designers rely heavily on their memory and experience when tackling design tasks [1, 2, 3]. However, how they apply their experience and knowledge is not understood and further research in this area is required. In addition, the aerospace industry, along with other industries, has recognised the need to capture 'experience'. In order to capture experience, the nature and use of design experience within the aerospace industry needs to be more clearly understood. This paper describes the results of a study of novice and experienced designers undertaken in the aerospace industry; the research approach and research issues; a method of support for novices designers; the preliminary evaluation of the method; and the trial implementation of the method in the aerospace industry.

Experience: current understanding

The long-term aim of this research is to provide a method of support for novice designers. In order to understand how to provide this support, it is important to understand how novice and experienced designers design. Very little is known about this, as most studies have focused on the time spent on external activities, e.g. task clarification and generating concepts [5], rather than focusing on problem solving activities [4]. Too few studies have been carried out, and those that have been have had differing aims. Hence, the findings are difficult to relate to one another. In addition, many of these studies have focused on well-defined problem domains, e.g. chess playing, physics, etc. The relationship between well-defined problem areas and the ill-defined area of design is poorly understood, and hence the applicability of these findings to design is not fully understood [6, 7]. The main findings relevant to novice and experienced designers in design (these findings were also applicable to well-defined problem areas) can be summarised as: Novice designers were found to have a tendency to reason backwards and to use a deductive approach. Experienced designers tended to reason forwards, and, when solving more complex problems, to alternate between forward and backward reasoning. A designer's problem space is thought to increase with experience.

ICED 01 - C586/259

75

Experienced designers hold larger amounts of information in a single chunk in memory. The ability to recall increases with experience. Experienced designers were found to have better spatial memory than novices. The effect of experience on creativity is unclear and further research is required.

There are many design tools that support designers, however these tools are, on the whole, in their early stages of development. The design tools reviewed did not support designers with the provision of design strategies based upon a cognitive model. In addition, methods or tools that assist novice designers to gain experience faster were not found. The review highlighted the need for further research to understand how designers carry out design work and to identify the differences between how novice and experience designers approach design tasks. This understanding could then provide the basis of a tool or method to support designers and, in particular, to support novice designers.

Research Approach

Empirical research in the aerospace industry was carried out to understand the differences between how novice and experienced designers approach design tasks. Three different research approaches were employed: (1) observations and post-observation interviews; (2) discourse analyses; and (3) interviews. The research was data driven and the findings from each study influenced the direction of subsequent studies. All the studies were audio-recorded and no method of analysis was set up prior to the studies. The transcripts were used to create categories that summarised the designers' activities, including their thoughts and actions. The research method employed for each of the studies is described briefly below: During the observations, the designers were asked to think aloud whilst carrying out design work. The designers worked on their own task to ensure that it was of a suitable complexity for each designer's experience. The designers were observed for 90 minutes. Each observation was followed by a 30-minute post-observation interview in order to gain an understanding of the background of the designer and the task. The discourse analyses consisted of pairs of novice designers interviewing experienced designers without the presence of a researcher. The aim of the interviews was to elicit knowledge to describe a particular design process, e.g. designing a turbine blade. The interviews were semi-structured and aimed to gain an insight into the company culture.

When planning the empirical research, the following issues relating to empirical studies in industry were considered: To keep the amount of time involved for participants at a reasonable level to ensure the support and co-operation of busy designers. To respect the commercial sensitivity of the aerospace industry. The use of video recorders is forbidden, and permission needs to be sought for audio-recorders.

76

ICED 01 - C586/259

To maintain rigorously the confidentiality of the designers.

Many issues need to be considered when carrying out empirical research in industry, e.g. the work schedule of the participating designers. There were often delays in arranging observations, interviews or evaluations as a result of trying to accommodate the designers work schedule. These issues added considerably to the time involved in data collection and analysis. However, the difficulties involved in carrying out research within industry were far outweighed by the benefits. The results were more relevant to industry and more easily transferred. The total time for data collection and analysis during this research amounted to 1325 hours (or 165 days) and is broken down in Table 1. Each of the three studies contributed in their own way towards identifying differences between novice and experienced designers. The observations provided an understanding of how novice and experienced designers approached design tasks. The discourse analyses provided an opportunity to analyse the interactions of novice and experienced designers without the presence of a researcher. The discourses were used to understand the types of questions asked by novice designers and their knowledge needs. The interviews were used to triangulate the findings from the other two studies. In addition, they provided an insight into the company and a broad view of the design projects undertaken by the designers. The interviews were useful for identifying the categories of experienced designer behaviour (as identified from the observations) that the experienced designers were aware of.
Table 1. Breakdown of time spent on data collection and analysis

Study

No. of hours spent

616 374 120 215 1325

No. of days spent

77 47 15 27 165

No. of participants Novice

6 8 0 6 20

Experienced
6 8 6 6 26

Observations Discourse analyses Interviews Evaluation Total

3.1 Participants
In total, 34 engineering designers from five different teams in Rolls-Royce pic participated in the three studies (a further 12 were involved in the evaluation of the proposed method). Designers with little experience within the company were classed as novices and those with many years of experience as experienced designers. It was not assumed that an experienced designer was necessarily a good designer: no attempt was made to assess the quality of any design work. Experience is thought to contribute to being a good designer, but once a particular level of experience has been reached other factors become more important [8]. The period necessary to become experienced, defined as having attained an international level, in fields such as chess playing, arts, sports and sciences, is thought to be 10 years [9, 10, 11 in 12]. By selecting novices with less than two years experience and experienced designers with

ICED 01 - C586/259

77

over eight years experience, it was assumed that the novice designers had not reached the level of experience required to be good designers. The novice designers would still benefit from support that would help them gain experience more rapidly. The research aims to understand the differences in how novice and experienced designers approach design tasks within a particular aerospace company, and not against some predefined 'international level'. Therefore, the participants of this research were selected based upon the number of years of relevant industrial experience and were not assessed on their design skills. The experienced designers involved with the research had worked an average of 19.5 years in the aerospace industry and the novice designers an average of 1.5 years.

Findings

The findings from the three studies conducted identified differences in how novice and experienced designers approach design tasks. Differences were also found in the designers' understanding of what they needed to know in order to complete design tasks. A summary of the main findings for each of the studies is presented in the following paragraphs (a more detailed description can be found in [13]). The observations of designers found that novice designers used a particular pattern of trial and error when designing. The novice designers only evaluated decisions after they had been implemented. Experienced designers carried out a preliminary evaluation stage allowing them to evaluate decisions prior to their implementation and, hence, avoiding the use of the novice trial and error pattern. The observations identified eight strategies that experienced designers adopted that allowed them to avoid this process. Novice designers had not developed such strategies and were found to be unaware of these strategies. However, the most experienced of the novice designers were beginning to move towards experienced designer behaviour. The discourses were analysed for the type of query, the topic of the query and the response to the query by the experienced designer. Two types were identified: a question or a statement. The type of response was one of the following: an answer to the question; the provisional of additional information; the query was rephrased or declared irrelevant; a combination of these. In total 633 queries were analysed. The analysis revealed that novice designers were aware of what they needed to know in only 35% of all queries. Novice designers were found to be aware of what they needed to know in queries regarding topics such as domain knowledge, but not about design strategies employed by experienced designers, suggesting that they were unaware of them. 10% of all the queries were rephrased or stated as irrelevant by the experienced designer. 29% of all queries were statements which indicated that the novice designers were aware of the topic that they needed to know about, but they did not know how to phrase their questions. In response to 16% of all queries, the experienced designers offered additional information to that required simply to answer the queries. These findings suggest that novice designers require support in identifying what they need to know. The interviews and the post-observation interviews supported the findings from the observations and found that the experienced designers interviewed were aware of experienced designer behaviour in five out of the eight categories identified as design strategies. The experienced designers did not mention all of the categories of experienced designer behaviour that was identified from the observations. This suggests that the categories not mentioned might be described as the tacit knowledge possessed by experienced designers. Without the use of observations as a research method, these categories of experienced designer behaviour would probably not have been revealed. The interviews suggested that experienced designers

78

ICED 01 - C586/259

had many points of contact, i.e. they knew who to contact; were aware of what reports were relevant; and were aware of what questions to ask to resolve issues. The observations, discourses and interviews all indicated, not surprisingly, that experienced designers had greater knowledge of how the engine functions, that they questioned data and considered issues. The results from the discourses revealed that novice designers are often not aware of what they need to know. The findings suggest that novice designers require support to formulate design strategies and that supporting novice designers by simply supplying information is not enough, as they also need to be aware of what they need to know and how to phrase appropriate questions.

C-QuARK METHOD

A method of support named C-QuARK has been developed based upon the findings (refer to Figure 1). The method aims to prompt experienced designer behaviour by informing novice designers of what they need to know through the provision of generic questions. These questions were derived for each of the eight categories identified as design strategies employed by experienced designers during the observations. C-QuARK links these design strategies based upon how experienced designers were observed to move from one activity to another. The arrows in Figure 1 represent these links and the direction of the arrows have been determined by the observations. The basic difference between C-QuARK and an expert system is that it provides novice designers with questions rather than answers. It therefore does not rely heavily on captured knowledge. C-QuARK is intended to support novice designers in a flexible manner by: Providing them with the type of questions experienced designers ask whilst designing and, hence, support designers in making faster progress in their work and remove the likelihood of missing out important questions. Inform novice designers of what they need to know. Provide them with strategies for designing based upon experienced designer behaviour.

The method can be used to support designers in the following ways: As a method to be referred to when designing. Through training as part of an educational programme. To capture and structure information.

Rolls-Royce has initially implemented the method by providing training for graduates recently recruited to the company. The affect of the method on the graduates is being evaluated and compared to those who are unaware of the method. The initial reaction to the method was found to be positive. The novice designers using the method were observed to increase their use of design strategies, such as consider issues, in comparison to the designers that were unaware of the method [14]. C-QuARK is currently being implemented to help develop the structure of the intranet. Information is structured using the categories identified from experienced designer behaviour

ICED 01 - C586/259

79

and the additional information provided by experienced designers during the discourses. Each webpage is linked using the links identified from the observations and, hence, prompts the novice designers to move from one category to another in the same way as experienced designers. Information in the intranet is captured and structured using C-QuARK. As CQuARK is based upon how experienced designers were observed to design it should therefore be a natural way to obtain information for experienced designers. Although capturing a significant amount of information into the intranet will take time, the intranet should be of immediate benefit by simply supplying novice designers with the right questions and the availability of examples.

Evaluation of C-QuARK

A preliminary evaluation of the proposed method has been carried out, involving a further 12 designers. A novice designer was observed using C-QuARK to carry out a design task and an experienced designer acted as the knowledge source, answering any questions. The aim of the evaluation was to identify inappropriate questions or links and identify any areas the method had missed. The evaluation identified missing links between categories, but no major areas were found to be missing. The evaluation results were useful in refining the categories. The evaluation validated the method and found no inappropriate categories or links. It was also useful in refining the categories. Two additional links between activities were found that were not identified from the observations. These two links need to be investigated further to understand if C-QuARK should be modified to include them. The initial reaction of both novice and experienced designers to the method was found to be positive. The use of C-QuARK reduced the number of inappropriate questions asked by novice designers by around seven percent in comparison to those during the discourse analyses. The evaluation suggests that the novice designers found three of the categories more difficult to use than the other five. This indicates that the way these categories are explained to novice designers needs to be reviewed.

Conclusions

This research has contributed towards understanding how designers carry out design work at a problem solving level, and, more specifically, to understanding the differences between novice and experienced designers at this problem solving level. The research has been carried out within industry and differs from many previous studies in that the findings have been used to develop a method of support for designers. The research has found that novice designers were unaware of the design strategies employed by experienced designers. Novice designers therefore require support to identify what they need to know. A method to help novice designers to gain experience more rapidly has been proposed. The method can also be used for structuring information within the intranet based upon how experienced designers think. A preliminary evaluation has been carried out and further work is required for the full implementation of the method. The overall conclusions suggest moving from supplying answers to providing questions.

80

ICED 01 - C586/259

Figure 1. The C-QuARK method

ICED 01 -C586/259

81

Acknowledgements

The authors acknowledge the support for this research from the Engineering and Physical Sciences Research Council (EPRSC) and from Rolls-Royce plc. References [1] [2] [3] Court, A., "The Modeling and Classification of Information for Engineering Designers". Ph.D.. University of Bath. 1995. Marsh, J.R., "The Capture and Utilisation of Experience in Engineering Design". Ph.D., Cambridge University, 1997. Rodgers, P.A., "Capture and Retrieval of Design Information: An Investigation into the Information Needs of British Telecom Designers", Cambridge University, CUED/CEDC/TR5, 1997. Eisentraut, R., "Styles of Problem Solving and their Influence on the Design Process." Design Studies. 20, 1999, pp. 431-437. Fricke, G., (1999). "Successful Approaches in Dealing with Differently Precise Design Problems." Design Studies. 20, 417-429. Ericsson, K. A., and Charness, N., "Cognitive and Development Factors in Expert Performance." Expertise in Context, AAAI Press, California, 1997, pp. 3-41. Zeitz, C. M., "Some Concrete Advantages of Abstraction: How Experts' Representations Facilitate Reasoning." Expertise in Context. AAAI Press, California, 1997, pp. 43-65. Sonnentag, S., "Expertise in Professional Software Design: A Process Study." Journal of Applied Psychology. 83(5), 1998, pp. 702-715. Simon, H. A., and Chase, W. G., "Skill in Chess." American Scientist. 61. 1973, pp. 394-403.

[4] [5] [6] [7]

[8] [9]

[10] Hayes, J. R., "The Complete Problem Solver. Franklin Institute Press", Philadelphia, 1981. [11] Bloom, B. S., "Developing Talent in Young People", Ballantine Books, New York, 1985. [12] Ericsson, K. A., and Smith, J., "Empirical Study of Expertise: Prospects and Limits." Towards a General Theory of Expertise. Cambridge University Press, Cambridge, 1991, pp. 1-38. [13] Ahmed, S., Wallace, K. M., Blessing, L. T. M., and Moss, M., "Identifying Differences between Novice and Experienced Designers". Proc. Engineering Design Conference EDC2000. London, 2000, pp. 97-106. [14] Weinert, S., "Learning to Ask the Right Questions: Evaluation of a Program to Improve the Acquisition of Knowledge in the Design Industry," Masters thesis, Technical University of Dresden, 2001. Saeema Ahmed, EDC, Cambridge University, Trumpington Street, Cambridge, UK, Tel: 01223-332709, Fax: 01223-332662, Email: sa233@ene.cam.ac.uk. http:/Avwwedc. eng. cam. ac. uk/people/sa233. html Cambridge Engineering Design Centre 2001

82

ICED 01 - C586/259

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

USING DOMAIN KNOWLEDGE TO SUPPORT DESIGN REQUIREMENTS ELICITATION

M J Darlington, S J Culley, and S Potter Keywords: Structure of requirements, requirements elicitation, conceptual maps.

Introduction

This paper introduces a novel design requirements elicitalion method that is domainknowledge based. The method combines a simple knowledge-representation formalism and an interpretation scheme, implemented in a prototype design requirements elicitation system. Development of this approach has been carried out for three purposes. Firstly, to provide a basis for a requirements elicitation tool that might be used to capture and generate design requirements for manual or automatic configuration design. Second, to allow the idea of association - implemented in a simple 'concept-chaining' mechanism - to be explored as a means of embodying constraining domain-limited knowledge in a system. Third, to provide a vehicle to force the focus on the conceptual content of a particular area of discussion. In engineering design, the task of capturing the design requirement is an important and difficult part of the design process [1]. This importance is well illustrated in a number of cases, where incorrect, incomplete or ambiguous expression of the design requirement has been shown to occur, leading to design of artefacts that are unsafe, unsatisfactory, uneconomic or inappropriate [2,3,4]. The task of capturing and expressing the design requirement acquires an extra dimension in the development of automated systems - whether for requirement capture or design itself. Here the process of design requirement evolution must be formalized, as must the content and the representation of the requirement. A number of process approaches for developing a design requirement have been articulated, such as that of Clausing [5] on QFD and the House of Quality. Similarly, there are a growing number of commercial software tools, of which DOORS [6] is representative. These help manage the process of requirements capture, definition, maintenance and revision. However, the work reported in this paper looks principally not at the methodology of the requirements development process, nor at the structured recording and tracing of a requirement's evolution, but at the intelligent elicitation of the requirement, based on embodied domain knowledge.

Identifying the tasks for developing an elicitation scheme

Investigating the expression of the design requirement involves consideration of, amongst other topics, the following:

ICED01-C586/519

83

1. The conceptual areas that must be referred to, e.g. functionality, reliability and safety. 2. The language(s) - verbal, graphical and physical - appropriate for expressing ideas about the concepts, and the language content. 3. The nature of design requirement capture and generation episodes in the real world. This includes such things as essential elements, its evolutionary character, limitations, etc. 4. Methods of structuring the expression and elicitation process, to improve on the ad hoc communication of the design need. In addition, effective design requirement expression is dependent on overcoming the problems identified in the Authors' earlier work [7] which are a consequence of the nature and power of human communication. Problems result from such things as ambiguity, contradiction, incompleteness, assumption, redundancy, and so on.

2.1 The tasks

Two tasks are central to enabling the development of a dynamic Design Requirement elicitation scheme. First is the identification of the vocabulary for use in talking about the design need; second is a method for implementation that will allow guided elaboration of a design requirement in a controlled way, using the specified vocabulary, through interaction of the user and the computer. Thus there are two key issues, which must be dealt with, and in the following order: 1. What to represent the concepts that are needed to think and talk about the domain. the words needed to label these concepts. a method for constraining the use of the vocabulary to that which is currently appropriate. a structure to allow the words to be represented and used.

2. The means of representation

Concepts, content & associations

The above discussion identifies three key elements which are fundamental to providing a framework for design requirement elicitation support. These are discussed below.

3.1

Concepts

The term 'concept' is widely used, in a number of ways, and definitions abound. In the context of this research work on controlling the expression of requirements, concept will be used according to the following definition. A concept is a collection of ideas about a separable (abstract) component of the world designated by a label. The meaning of a concept is defined in terms of the meaning of the ideas which support it. Thus a given idea can be defined recursively as a concept that is supported by other ideas. So,

84

ICED 01 - C586/519

for example, the concept of a wheel consists of the set of ideas (packets of meaning) that make up wheel. By being a separable component of the world, the concept is demonstrating that the referent in the world to which it refers is demonstrating a perceivable regularity that makes it stand out and be recognizable from one encounter to another. Importantly, this suggests that the concept may be recognizable, and thus shareable, by others. The set of ideas that constitute the meaning of the concept will be different for each individual. Communication between individuals is possible just because common experience assigns overlapping meaning to a referent in the real world, which by agreement is given a label. The label is used as the common term for the referent, and is the means by which communication can be achieved, between individuals or between a computer and operator.

3.2 Content
In the development of this design requirement elicitation method, the investigation has been limited in the first instance to consideration of an application-neutral verbal language and to one that is appropriate to discussing the motion of a machine. Restricting the area of investigation limits the complexity of the language content, and is made on the presumption that verbal language is basic to the discussion of design need [3], and that function (purpose) is the underlying need in engineering design. It is recognized in this work that a text medium alone may be insufficient for the elicitation and expression of a complete design requirement. It is natural, and almost certainly necessary, for graphical media to be used in conventional design. It may turn out to be equally true for eliciting and presenting data for input into automated design systems. The investigation is based on the following assertions relating to function: 1. When considering some of the tasks that a 'machine' can carry out, the following basic activities can be performed: - moving an object, - acting on an object (e.g. when clamping or drilling), - acting on itself (e.g. in moving a mechanism). 2. The requirements that a mechanical system may be required to meet can be expressed in terms of the function (the purpose) of the machine and in terms of the action of the machine. 3. The actions that a machine can perform can be redescribed or 'chunked' as functions, 4. The manner of describing these actions and functions is unrestricted (given the generative nature of English). 5. The set of concepts invoked when describing the function or actions is restricted or, at least, a restricted set of concepts can be identified that can usefully describe them.

3.3 Associations
In many modes of thinking, ideas and concepts that emerge are not random, but are constrained to what is appropriate in the current context: this idea leads to that idea, and so on. Clearly, were this not so a coherent train of thought could not be developed. Concept association provides one mechanism by which this contextual constraint might be

ICED 01 - C586/519

85

accomplished. Context doesn't provide a fixed boundary, but some graduated measure of appropriateness based on meaning. For a given situation, the conceptual space is disposed in such a way as to have a focus point situated where the meanings central to the situation are clustered. For a full discussion of concepts see [8].

A mechanism for constraining dialogue

In the interaction between humans and computers, the interpretative power is very one-sided. Computers, having no intelligence, can interpret input only in a limited manner, and only where the mechanism has been pre-specified. However, if contextual constraint can be provided in humans by an implicit network of concepts, then why should it not be provided to some extent in a decision-support tool by making the network explicit, by pre-defining the concepts and their interdependent relationships? This would allow the behaviour of the system to be constrained, and fix the context for the interaction between it and the human operator. It is recognized here that some concepts are private. Thus, in making the concepts explicit it would be presupposed that only those that were readily labelled (and hence shareable) would be available and useful.

4.1 Representing the concepts as a structure

The above discussion clearly identifies for representation, shareable concepts - which will be identified by labels - and associations or relations between the concepts. The method chosen here for representing concepts and associations is a simple graph, consisting of nodes (representing the concepts/labels) and arcs representing a direct relation. The relations adopted between the concepts, principally based on meaning, are: parent, child and co-activee, elaborated as follows. Parent. Each concept, excepting the graph root concept, will have a single parent. Child. Any concept may have one or more child concepts. These may be associated by the logical relations: AND, OR and XOR. For example, AND implies that all child concepts are logically entailed if the parent concept exists. Co-activee. This is a pragmatic relation that allows logical entailment of remote concepts (those placed in different graphs). A set of labels and their relations as defined above together form a domain specification which constitutes the domain knowledge for the domain to be considered.

Developing the domain specification

The first domain to be mapped for exploratory purposes is that of machine motion. The general content was introduced in Section 3.2. Here the content for the domain is elaborated.

5.1 The lexicon of terms (concept labels)

The starting point for developing a lexicon to describe this domain was the lexicon developed in the authors' earlier work [7] relating to the automation of configuration design. From this

86

ICED 01-C586/519

have been taken those words which were appropriate for this particular purpose. Additional words have been adopted as seemed appropriate in order to increase the richness of the expression. In addition the existing general lexical ontology WordNet [9] has been used as a principal source of words and definitions for this specialist lexicon. In particular, WordNet was used as a means of eliminating synonyms. Development of the lexicon was carried out itcratively with development of the conceptual structure in the form of a set of graphs.

5.2 The graphs

To control graph complexity and facilitate administration and maintenance, the domain is described using a number of graphs, although, in principle, a single graph might be used. Each graph relates to a different descriptive dimension of the domain as a whole, viz: Function Motion Force Attribute Control

The function graph represents the entry-point conceptually for the domain, in that it is as a function that the embryonic design requirement is expressed. Requirements described in terms of function can also be described as activity. These aspects of the domain are contained (redescribed at a different level) within the motion and force conceptual structures.

Figure 1. A fragment of the motion graph, showing concept labels, AND relations (solid lines) and XOR relations (hatched lines).

A separate graph, control, contains concepts relating aspects of controlling the activity of the solution system. This might be seen as a special area of functional requirement. The attribute structure contains concepts and associations relating to physical objects and their attributes. It should be understood that although self-consistent, the chosen content and organization of the graphs is a subjective (to the originator) representation. Its usefulness lies in the extent to which it is recognizable by others, and hence might be 'shareable'. A fragment of the motion graph is illustrated as an example in Figure 1.

ICED01-C586/519

87

Implementation issues

In order for the conceptual structures discussed above to be operationalized, an algorithm has been developed to interpret the data expressed as a domain specification and implemented in a prototype computer programme. The implementation consists of: 1. A representation of the domain specification as a conceptual structure. 2. A method for assessing association-relation decision criteria. 3. A representation of the current episode knowledge as a conceptual structure. 4. A method of adding to the current episode conceptual structure as concepts are accepted. 5. A method of eliciting and accepting information from the user. In addition to containing knowledge about the domain concepts and relations, provision is implemented for numerical and text values to be associated with specific concepts. This allows the system (the designer) to prompt the user (the customer) to provide these values when appropriate, and for these values to be output together with the design requirement concept structure. Together these provide what can be thought of as a Design Requirement Record. From this record can be extracted those elements that are useful in a given context as the Design Requirement itself.

A computer-supported design requirement elicitation episode

The initialised system can be thought of as taking the part of the designer, about to embark on a information-gathering episode. At this stage the current knowledge consists of the general knowledge about the domain, but none about any specific episode. The process that ensues can be seen as one of progressively by inference and by eliciting user-input eliminating from consideration irrelevant elements of the closed domain. The episode is initiated by the system prompting the user to enter a 'key concept': the principal functional requirement that the user desires to be satisfied by the design. This corresponds to one of the concepts in the domain specification function conceptual structure. The system 'activates' this concept by placing it as the first entry in a concept-list. This represents episode-specific knowledge. The system now looks for the next most closely related concept to the one selected. This is activated and placed in the concept list. This process is repeated. At each stage the current knowledge - the domain knowledge and the growing episode-specific knowledge - is searched, which allows inferences about the next nearest concept to be considered. The chaining process continues until the choices presented to the system cannot be reconciled using the current knowledge slate (in which case it prompts the user to provide the information necessary to continue) or until all concepts that might be appropriate to the current episode have been activated (in which case the elicitation episode is at an end). During the elicitation, the system will prompt the user for numerical or text data, where the domain specification prescribes that a given concept has such an associated value. Output from the system consists of reporting the content of the episode-specific knowledge in the form of a set of concepts, ordered in a relational hierarchy. In addition, numerical or textual data, associated with particular concepts, are attached. This constitutes the full design

88

ICED01-C586/519

requirement record, which can be modified or augmented manually to form the design requirement. A fragment of a record and the resulting design requirement is shown in Fig. 2. Motion Requirements movement rotation reorientation tipping max_angle: 90 deg manner intermittent sporadic rotate_speed: variable set_speeds minspeed: 1 deg/s maxspeed: 5 deg/s

Figure 2. A Fragment of the Design Requirement Report. Concepts shown in bold outline are those that were selected by the user from choices presented by the system; others were chosen by the system. The text output forms the basis for the Design Requirement itself.

Results

The test domain specification contains 207 concepts. Taken across ten test cases, the average number of concepts chosen in an episode is 61% of the 207 concept labels in the domain specification. This is the proportion of the total domain that has been chosen as being appropriate to the episode. Of these, the average percentage of concepts chosen by the system without intervention from the user is 69%. The remaining 31% are those selected by the user from choices presented by the system. Of these an average of 27.5% are presented for selection together with one or more alternative, because the choice is dependent on user preference rather than on knowledge-based inference - the system simply cannot make a decision. The remaining 3.5% are 'blind' concepts. These are those concepts that, given the domain knowledge, might be expected to be known by the system as being appropriate for activation, but have yet to be considered and activated at the current decision point. Thus they, and alternatives, have to be presented to the user for choice. This is a function of the linear nature of the algorithm used for navigating the domain knowledge. The content of the domain specification is a representation of the way in which the originator of the specification apprehends and organizes the concepts relating to the domain. The implementation allows the content to be explored and refined by increasing the descriptive power of the domain specification. Provided that the content is a self-consistent and effective reflection of the domain, then the system will respond to that user's inputs in a coherent way. However, many questions have been raised about the best methodology for writing a domain specification that has the structure and completeness necessary for elicitation and generation of a design requirement that can be used to drive a design, either conventionally or through automation. To this extent the system has been shown to be useful.

ICED01-C586/519

89

The extent to which one user's representation of domain knowledge is shared by (and can be effectively used by) another user remains to be explored. This, however, is embraced by more fundamental questions about the extent to which internal representations of the world are shared between individuals, a subject beyond the scope of this paper. Nevertheless, the implementation presented here provides a tool by which this can be investigated.

Conclusion

The generation of a basic requirement is the starting point for all design activity. This work is concerned with supporting this generation process. Initial tests suggest that the straightforward concept association method chosen provides a principled method for constraining dialogue in a design requirement elicitation mechanism. In doing so, such things as ambiguity, contradiction, incompleteness and redundancy can begin to be controlled. In addition, the implemented mechanism provides a useful tool for exploration of a number of aspects of design requirement elicitation, including the conceptual content of a design domain. References [1] [2] [3] [4] [5] [61 [7] Wootton, A.B., Cooper, R. and Bruce, M. "Requirements Capture: where the front end begins?", Proc. ICED '97, Tampere, vol 1, 75-80. Smith, P.G and Reinertsen, D.G., "Developing Products in Half the Time", Van Nostrand Reinhold, N.Y., 1995. Ullman, D. G., "The Mechanical Design Process" (2nd ed.), Reston Publishing, Reston, VA., 1997 Hales, C., "Managing Engineering Design". Longman Scientific and Technical, Harlow, England, 1993. Clausing D., "Total Quality Development". ASME Press New York, 1994. DOORS. Quality Systems & Software, Inc; URL: http://www.qss.co.uk. Darlington, M. J. and Potter, S.E.,, "Engineering Design Requirements Formalization: the development of a constrained natural language and an elicitation scheme formalizing aspects of the design requirement". Internal Report No. 041/98, Engineering Design Centre in Fluid Power Systems, University of Bath, 1998. Sowa, J.F., "Conceptual Structures: Information processing in mind and Machine". Addison-Wesley Publishing Co., Reading, MA, 1984, Miller, G. A., Beckwith, R., Fellbaum, C., Gross, D. and Miller, K.J., "Introduction to WordNet: an on-line lexical database", International Journal of Lexicography, 3 (4), 1990, pp. 235 - 244. ftp://ftp.cogsci.princeton.edu/pub/wordnet/5papers.ps.

[8] [9]

Mr M. J. Darlington Department of Mechanical Engineering, University of Bath, Bath, BA2 7AY, United Kingdom, email: M.J.Darlington@bath.ac.uk, tel: +44 (0) 1225 826131 IMechE 2001

90

ICED 01 - C586/519

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

TOWARDS PRAGMATIC APPROACHES FOR KNOWLEDGE MANAGEMENT IN ENGINEERING - THEORY AND INDUSTRIAL APPLICATIONS
K-D Thoben, F Weber, and M Wunram Keywords: Knowledge management, KM, pragmatic, methods.

Introduction

Corporate knowledge is nowadays well accepted as a decisive asset in most European enterprises. The know-how and expertise of the work-force is an important factor for the success of companies and strongly influences the effectiveness and efficiency of the business processes and their outcome. The concept of Knowledge Management (KM) receives high strategic attention across multiple sectors. In the engineering area, KM is specifically relevant due to the knowledge intensive character of the domain. The new product development process, which is an innovative and a non-repetitive process par se, is especially interested in learning from the lessons of the past. However, today's practice in KM still lacks from significant drawbacks and the existing knowledge is captured and capitalised only to a small degree. The reasons for this are manifold, and one of the most critical factors is time. Though many employees are willing to document and utilise existing knowledge, they do not have the time to do this in the pressure of day-to-day business life. Consequently, there is a strong need for methods and tools with utmost user friendliness for rapid Knowledge Management. This paper aims to contribute to this need by discussing the relevance of pragmatic approaches for KM in engineering. Three cases will serve as an example for presenting benefits and drawbacks.

Pragmatic Solutions in KM - Motivation and Characteristics

Knowledge can be seen as the entirety of cognitions and abilities which are used by individuals to solve problems. This comprises theoretical perceptions as well as pragmatic day-to-day rules and guidelines and is an organised set of statements of facts or ideas, presenting a reasoned judgement or an experimental result [1]. KM comprises any process or practice of creating, acquiring, capturing, sharing and using this knowledge, wherever it resides, to enhance the learning and performing in organisations [2]. As the evolution of KM is driven strongly by large enterprises and consulting companies, the proposed solutions are often rather complex and dominated by information technology (IT). However, Malhotra [3] reports about different studies in which no direct correlation between IT investments and business performance or knowledge management was identified. He

ICED 01 -C586/526

91

emphasises that the organisational processes and the way the employees communicate and operate through the social processes of collaborating need more attention. Davenport and Prusak [4] report that some Japanese companies have installed so called "Talk Rooms" in which scientists come together to have a cup of tea and talk to each other for about half an hour. There is neither an agenda nor schedule and the only target is to bring these people together to evoke a discussion about their current work and to exchange ideas, thus leaving the generation of new ideas up to chance. A similar perspective is taken by the authors in [5]. Extending this statement, the authors would like to take the position in this paper that small pragmatic solutions are often as effective as high IT investments. Therefore the aim is to exploit the already existing systems as far as their functionality allows. Secondly, the complexity of problems has to be reduced. The underlying philosophy of a pragmatic approach can be characterised by following phrases which can be seen as guidelines as well: "A bird in the hand is worth two in the bush!" "To make a mistake is better than to make no experience!" "Stop talking, start doing!" Accordingly pragmatic solutions are aiming at a 80-90% solution for an identified problem instead of a 100% solution. The remaining 10%-20% are either postponed for future activities or are not solved at all, because of the undue efforts which are necessary to achieve the needed results. The main characteristics of pragmatic approaches (incl. methods and tools) are listed below: intuitively applicable by the user fast and easy to implement active participation of the users in the definition phase value added to be achieved in the short term application of a stepwise approach are self promoting due to the short term benefit and thus can pave the way for larger follow-up solutions (if felt necessary) low costs

Based on a number of projects in the field of KM in engineering design the authors are convinced that a "controlled neglect" of certain aspects of a problem is reasonable for many industrial applications. This controlled neglect is implicitly embedded in the Pareto-principle (better known as the "80/20-Principle"). This principle was recognized by the Italian economist Vilfredo Pareto at the end of the 19th century and first published in 1897 [6]. It basically says that, out of a given group of elements, already 20% of them will yield 80% of the results. A well known application of this principle is the ABC-Analysis which is often

92

1CED 01 - C586/526

used as a time/task-management tool. Examples for how the 80/20-Principle was successfully applied in others than the engineering domain are given in [7].

Cases 1 - KM within the Process Chain of Formed Sheet Metal Parts

A pragmatic approach to knowledge management was chosen at a manufacturer of formed sheet metal parts for small series. Figure 1 shows the process chain from tool design until the finishing of the sheet metal parts: based on the product specs, a tool has to be designed and manufactured in various process steps: casting, milling, finishing, etc. In the last step the tool is used to manufacture the formed sheet metal parts. As the various process steps need specialised resources the shop floor is organized according to the process chain into so-called manufacturing "cells" or "units". Knowledge about problems and related solutions identified during the process was documented in problem and solution reports according to the needs of the individual manufacturing cells. Available knowledge of the other cells as well as the needs of the other cells were not considered while documenting the knowledge of a cell. Accordingly improvements in quality, time and costs of the overall process were limited. Feedback from one process step to an earlier one was limited as well. Knowledge how to avoid problems in the manufacturing process and how to support a design for manufacturing (DfM) was available in general, but not for the designers. Forced by their customers to reduce lead-time and increase quality the company had to redesign the information management along the process chain.

Figure 1. Management of knowledge in a process chain for formed sheet metal parts

The overall approach was to form a task force including product designers, tool designers and representatives from all manufacturing cells involved in the process chain, to discuss the mutual needs, the problems, and the challenges of all steps of the chain. Based on a better understanding of each other, inputs and outputs requested from the various cells were defined and the overall process knowledge was structured. In many cases, changes were required compared to the old approach and compromises were made in order to achieve a pragmatic solution, e.g. people agreed on having a 90 % solution instead of a 100 % solution which would have required far more effort.

ICED 01 - C586/526

93

A second pragmatic element in the approach was that the solution was implemented in the short term as a paper based KM system. Following an incremental approach, the first step was to start with a so called "tool file", which was handled manually along the process chain from cell to cell. Within the tool file (which had an agreed format) problems, related solutions etc. were documented. In parallel, the development of the computerised "Knowledge Base" has started, so that in future problems, related solutions as well as other ,,experiences" gained in the various steps of the process will be documented along the whole chain from tool design until the assembly of the sheet metal parts. Even by introducing the paper based, but commonly agreed tool-file, the number of reliable feedbacks from manufacturing to design increased significantly.
Table 1. Summary of Case 1

Problem Insufficient communication and coordination along the process chain, caused by the application of the so-called "Throw it over the wall"- approach.

Pragmatic Approach Specification of rough but commonly agreed documentation forms. Incremental Approach: From an early implemented paper based solution (80-90% solution) to a database application. Forms were made accessible for all employees involved in the process chain by an Intranet application.

Case 2 - Management of Design Knowledge between Design and Assembly

Considering the time aspect of a production chain, assembly activities are "far away" from design activities. This causes various well known problems in engineering design: After the design, a feedback from the assembly is - if ever - available only several weeks or months later. As the documentation of problems is time consuming and represents an additional activity for the people in the assembly area, their motivation is limited.

However, aiming at high quality products experiences gained in the production and assembly process have to be made available for the design of new products. In parallel, the time and efforts needed for documentation have to be minimised and just-in-time documentation has to be realised. Additionally ideas about optional solutions, anticipated problems, as well as identified problems have to be described in such a way, that it is easy for the designers to understand. The approach chosen in the company was to create a close link between the design department and the assembly area by installing an Intranet application on the one hand, and by offering various digital cameras to all departments dealing with the manufacturing and assembly on the other hand. Pictures made with the digital camera are stored in a database and are being made available to the design department via the Intranet application. So far a textual description has to be typed to describe the problem documented by each specific picture. However, by applying this approach, time consuming documentation activities were avoided and the response time for feedbacks from assembly to design was minimized.

94

1CED 01 - C586/526

This case serves as a good example for distinguishing pragmatic from non-pragmatic solutions: The distribution of digital cameras including the instruction to manually typing in the problem can be regarded as pragmatic because it used a straightforward approach and mature and easy to use technology1. The introduction of technologies like e.g. speech recognition, automatic picture processing and indexing would have been beyond pragmatic approaches as these are not yet fully mature and need careful adaptation and fine tuning. Thus the proposed 80% solution was prioritised compared to the 100 % that would perfectly fulfil the needed requirements.
Table 1. Summary of Case 2

Problem Pragmatic Approach Easy to use technologies (digital cameras and Insufficient feedback of problems and experiences identified in the assembly area to Intranet) for a quick documentation of design department problems and failures.

Case 3 - Approaches to KM in a R&D Department

The following case provides a brief outline about different pragmatic approaches for KM which have been implemented successfully in a R&D department of an organisation with a staff of 150, comprising engineers of various domains, as well as technical and administrative staff. Major objective of all activities was to reduce the knowledge loss when experienced colleagues leave the organisation, to speed up the learning curve for novices, and to increase the knowledge exchange between the individual, multidisciplinary experts. The measures were addressing both knowledge about complex engineering issues e.g. methodical research/development approaches etc., as well as small day-to-day business processes as e.g. business travels or specific email problems. The following measures were implemented (among others): Personnel Coaches (Mentors): When entering the organisation, each novice, e.g. a junior engineer, is assigned to a personnel coach who is responsible for introducing the novice to the colleagues, the business processes, and the future working domain. The coach must have already stayed in the organisation for at least 2 years. Round Table: The engineers involved in the development process meet regularly (3-4 weeks) for exchanging their current design challenges and problems. The round table is accompanied by smaller means as e.g. a knowledge map of the engineers or an internal newsgroup for short term problem discussions. Common directory structure: All engineers store all their files in a common directory structure on a server. No files related to a project must be stored on the individual hard disks. The structure comprises predefined directories for e.g. projects, acquisition (bids), old projects, general department issues, or individual users. The structure is predefined up to four levels (for a detailed case description cf. [8]) which was identified as sufficient for most of the projects. A cost benefit ratio for this measure was exceptionally high, also because no IT investment for its implementation had to be made (because servers were already existing).

The authors assume here that the corresponding processes were well defined, i.e. that it was e.g. specified how the designers make use of the picture database.

ICED 01 - C586/526

95

How To's: A variety of guidelines and recommendation is made available voluntarily on the Intranet by 'knowledge owners'. These range e.g. from where to take project partners to dinner, via how to prepare project meetings, up to how to configure the email system. These recommendations are intentionally placed outside the organisations' formal Quality Management Handbook following ISO 900x. (This approach can be compared with a selforganized concept of FAQ (Frequently Asked Questions)).

All measures are successfully in operation since 2 years (except for the round table which has been implemented only 3 months ago). All measures allow small individual or case specific modifications and assure short term benefits for the users. Common to all approaches was the utilisation of the existing IT infrastructure. For some of the approaches, also larger solutions had been in discussion, but these were rejected for the benefit of a fast, flexible and simple implementation. Also, all approaches have been planned and implemented by the employees themselves.
Table 1. Summary of Case 3

Problem Flat learning curve of novices Lack of communication of non project specific information and knowledge Identification of knowledge "hidden" in other projects Time consuming no value adding tasks related with project management activities. Frequent disturbance of experts related to tips and tricks requested by colleagues

Pragmatic Approach Personnel coaches Programmers Round Table Specification of identical directory structures up to the fourth level for all types of projects. Further detailing of the structure would have generated to high efforts Documentation and provision of "How to's" on the Intranet

Conclusions and Future Activities

The authors have applied the concept of pragmatic approaches for KM considering industrial cases related to engineering design. As described, pragmatic approaches are based on a philosophy which prefers to implement 80-90% solutions in the short term instead of a 100% solution in the long term. Three exploratory cases have been presented and the achieved benefits have been discussed. These are mainly the possibility to achieve working KM solutions in the engineering design environment in a short implementation time and with reduced costs for IT investments. On the other hand, however, pragmatic approaches in general bear a strong risk. People may be tempted to implement the first solution they see without carefully reasoning about its appropriateness and usability. If KM solutions aiming to support a better cooperation between design and manufacturing fail, it is more difficult to motivate the users to participate in a second approach. Thus - in contrast to trial and error solutions - the possible error must be avoided as far as possible. Accordingly incremental approaches are far more promising than large and not controllable steps. The authors assume that a sound conviction about the

96

ICED 01 - C586/526

appropriateness of a solution is a critical success factor for the successful implementation of pragmatic approaches in engineering design. A general question arising in the context of applying pragmatic approaches, that aim at achieving a 80-90% solution instead of a 100%, is that according to the Pareto Principle the most relevant parameters/elements have to be identified. Thus a major risk when applying pragmatic approaches is the neglect of vital aspects of the problem to be solved. So far the starting points in the industrial cases described above were identified in common workshops aiming at a higher product quality and shorter throughput-times. In order to exploit pragmatic approaches with a reduced risk, future research should aim to develop methods and tools for KM which allow the identification of the most relevant aspects to be addressed by pragmatic solutions. References [1] Probst, G.; Raub, S.; Romhardt, K.: Wissen managen - Wie Unternehmen ihre wertvollste Ressource optimal nutzen; 3rd Edition; Frankfurt am Main, Wiesbaden; Gabler-Verlag p.46, 1999 Scarborough, H. Knowledge Management: A Literature Review, Institute of Personnel and Development, 1999 Malhotra, Yogesh: Knowledge Management for the New World of Business. Asian Strategy Leadership Institute Review, Vol. 6, 1998 Davenport, T., Prusak, L.: ,,Working Knowledge - How Organizations Manage what they Know", Harvard Business School Press, Boston, Massachusetts, 1998 Thoben, Klaus-Dieter; Weber, Frithjof: Supporting Decision Making and Communication in a Concurrent Engineering Environment: Information Technology and Social Aspects. In: I. Dumitrache, A.M. Stanescu, M. Pallot (Eds.): Preprints of the First International Symposium on Concurrent Enterprising, ISoCE'98, 4-6 June 1998, Sinaia, Romania, 1998, pp. 23-34 Pareto, Vilfredo: Cours d' Econonomie Politique, vol. 2, 1897, pp. 370-72. In: North, Gary; Priorities and Dominion - An economic Commentary on Matthew, WWW-site (15.01.2001) (http://www.freebooks.com/docs/html/gnma/chapter27.htmtfN 4 ) Koch, R.: The 80/20 Principle - The secret to success by achieving more with less. Currency, New York, 1998 Thoben, Klaus-Dieter; Weber, Frithjof: Designing Information and Communication Structures for Concurrent Engineering - Findings from the Application of a Formal Method. In: Lindemann, Birkhofer, Meerkamm, Vajna (Eds): ICED 99, Proceedings of the 12th International Conference on Engineering Design, Schriftenreihe WDK, Munich, Vol 2, p. 989-994

[2] [3] [4] [5]

[6]

[7] [8]

Klaus-Dieter Thoben University of Bremen and Bremen Institute of Industrial Technology and Applied Work Science (BIBA) at the University of Bremen, Hochschulring 20, D-28359 Bremen, Germany, Tel.: +49-421-218-5529, Fax: +49-421-218-5551, URL: www.biba.uni-bremen.de, tho@biba.uni-bremen.de . IMechE 2001

ICED 01 -C586/526

97

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

EFFECTIVE ABSTRACTION OF ENGINEERING KNOWLEDGE FOR KBE IMPLEMENTATION

P Bermell-Garcia, I-S Fan, G Li, R Porter, and D Butter

Keywords: Knowledge-Based Engineering, knowledge representation, knowledge abstraction, industrial case study, aerospace engineering.

Introduction

This paper suggests a set of guidelines for the effective abstraction of engineering knowledge for the application of Knowledge-Based Engineering (KBE). KBE applications have been successfully delivering benefits in reducing engineering design time and cost. However, the current generation of KBE applications is developed with the primary objective of automating design tasks. The concept of knowledge re-use can be fully supported with current KBE tools. However, they are seldom realised in practice. This paper reports on the development of a KBE application during which the guidelines and methods of abstracting engineering knowledge was developed and tested. The innovation is in the viewpoint of optimising KBE rules with the consideration of efficient abstraction and re-use of knowledge. The research was carried out during a pilot industrial project in proving the feasibility of using KBE in aerodynamics wind tunnel model. The approach follows on the concept of Reusable Knowledge Component (RKC) proposed previously in the group. KBE applications developed with the guidelines shall be easier to maintain and grow due to better knowledge sharing and reuse.

Knowledge-Based Engineering

KBE is a particular type of Knowledge-Based System (KBS) with a focus on product design [1],[2],[3],[4]. In the computing science context, the dominant KBE systems today are objectoriented programming environments tightly integrated(or interfaced) with a geometric modeller. In contrast to CAD and solid modelling design tools, the key characteristics of KBE are generative modelling and integrated modelling. Generative modelling means that the product model is generated based on a set of coded rules enabling automated generation of product data. The starting point of the design is a set of rules rather than a geometric concept. In order to achieve this, a generic model of the product needs to be created based on a detail understanding of the product, in terms of its function, geometry, configuration and all the relevant factors. From this generic model, the geometry and other product data for a range of similar products of similar functional characteristics can be generated automatically. The specialisation characteristics of these instances of the generic models can be specified by the design end users. For example, if a generic model of an aircraft wing can be defined, a variety of wings can be generated easily based on new customer requirements. Integrated modelling

ICED 01 - C586/131

99

highlights the rule-based nature of KBE design. Rules relating to the full range of product development disciplines and activities can be built into the generic model. Examples of integrated modelling are the automatic generation of finite element meshes and machining tool paths together with product part geometry.

KBE implementation issues

KBE technology has been successfully applied in many different industrial environments. Some of these case studies can be found in [1],[2]. KBE implementation should be able to support two basic objectives: Solving a particular design problem by a KBE application. Retaining domain knowledge required for solving design problems in the environment.

Methods to develop a KBE application in a systematic and structured way in order to extend and maintain it conveniently and also to effectively reuse the knowledge collected for one KBE application in the future KBE applications are challenging problems [4],[5],[7],[8]. Research on better methodologies for KBE development can be found in projects like MOKA (Methodology and Tools Oriented to Knowledge Based Engineering Applications) [5]. At the application level, example project like KOMPRESSA (Knowledge-Oriented Methodology for the Planning and Rapid Engineering of Small-Scale Applications) [6], aims at developing KBE implementation methodologies for small organisations. As it has been reported in [6], the lack of standardisation within KBE applications, platforms and systems, requires knowledge sharing and reuse strategies within organisations. A strategy is the re-structuring of KBE applications to produce smaller, generic sub-applications. These sub-applications can then be re-configured for future KBE development. These generic subcomponents are called Reusable Knowledge Components (RKC). RKC's behave as small software packages in which knowledge related to solve engineering problems is stored. A RKC accepts inputs and then generate decision outputs accessing to a knowledge base containing engineering rules using certain inference method.

Developing KBE applications

The KBE development process consists of the steps to: capture knowledge; develop the product and process models that represent and maintain the captured knowledge; and the coding of the knowledge using a KBE implementation language. Knowledge abstraction is the step in formulating the product and process models to be coded. This requires a careful analysis of the domain knowledge in which the KBE application has to work and the specific knowledge of the problem to be solved. 4.1 Knowledge view of the design problem Achieving a design solution involves the contribution of a number of knowledge sources, usually from designers. A design solution is the complete description of the artefact to be built. The designers use their domain knowledge and expertise for solving the design

100

ICED 01 - C586/131

problem, specified to them in design requirements and constraints. This design problem solving process is illustrated in Figure 1.

Figure 1. Knowledge-based design problem-solving model.

In current KBE practice, the domain knowledge and expertise of the designers is captured by knowledge engineers whose responsibility is to represent the knowledge and make it explicit for its coding. The representation is the abstraction of this knowledge in such a way that is suitable to be coded into a computer. 4.2 Codifying knowledge in KBE Current KBE software systems employ object-oriented paradigm as the coding technology. The abstraction of knowledge has to be in object form. The knowledge modelling mechanism in these systems is rule. In effect KBE technology uses the rule-based knowledge representation technique combined with object-oriented programming. Thus, knowledge abstraction in KBE can be stated as: "The process in which the engineering knowledge is analysed for being represented in terms of objects and engineering rules through a computer understandable language". Figure 2. illustrates how design knowledge is handled in KBE applications.

Figure 2. Knowledge abstraction process.

A design object is an abstract entity containing definitions that model the design problem. Each one can contain different kinds of information such as these: Geometry definitions such as revolved surfaces or lines.

ICED 01 - C586/131

101

Equations based on design parameters for performing different calculations. Design parameters related to the geometry (i.e. dimensions) or related to other attributes such as weight or density. Engineering rules defining relationships among design objects.

Engineering rules are embedded in design objects in most KBE languages. However due to their role in knowledge modelling, they could be considered as an independent entity/object. Methodologies for managing the engineering rules and the object codes independent of the KBE software platform are the subject of current research [9]. The KBE application is the combination of these objects working together in a software platform. The output of the KBE application is the complete or partial solution to the design problem. This output could be in the form of 3D models, data sets, or other kinds of description fulfilling the requirements of the design problem.

Guidelines for effective knowledge abstraction

Most KBE applications have been developed for solving large-scale design problems in the aerospace and automotive industries. The main concern is the functionality needed to automate a complex design problem, rather than the reusability of engineering knowledge. One reason is that the immediate cost for the development of a reusable KBE application is typically more than the cost to develop a bespoke KBE application. The benefits of the reusable concept are to be reaped from the elimination of redundant knowledge capture and the systematic build up of a high quality knowledge pool for long term KBE implementation. The effectiveness of the knowledge abstraction process depends largely on the optimum decomposition of the design problem to create sub-components able to be shared and reused among applications and be maintained easily. Theoretically, object-oriented technology allows the creation of a KBE application that has only one single object. This object would contain all the part definitions, calculations and engineering rules. Common sense and structured programming methodologies advise against this approach. The current state of KBE technology as reported in [4], [8] lacks the tools to support effective knowledge decomposition due to the ad-hoc character of most KBE applications. In the industrial project to develop a KBE application for aerospace wind tunnel models, the authors noticed that many engineering rules collected were generic and could be used again and again, even in the same application package. So the attention had been on how to decompose those knowledge in a fashion that could be reused effectively. This led to the guidelines and criteria that could be used by knowledge engineers and designers for more effective abstraction of design knowledge. The guidelines provided here are consolidated from the known knowledge management techniques and tested through the development of the KBE applications in the case study. The resultant knowledge abstraction process after the adoption of the guidelines is illustrated in Figure 3.

102

ICED 01 - C586/131

Figure 3. Proposed effective knowledge abstraction process.

These criteria and the guidelines arc listed as follows: REPETITIVE. Isolate objects performing tasks (geometry generation, calculations, etc.) that are often repeated in the problem. INDEPENDENT. Split large problem into independent problems. A design problem can be composed of different tasks that are almost independent. GENERIC. Define generic ways of performing tasks in the environment. A specific approach to solve a problem may not work in other similar cases. A generic way of solving a set of problem is more effective. EXTENSIBLE. Design objects definition must be done with the consideration on the use of objects in other design problems in the environment. The application of these general guidelines is illustrated in the industrial case study.

Case study

The authors have been commissioned to build a KBE system to investigate the feasibility of using KBE for aerodynamics wind tunnel model design and manufacture. Wind tunnel models are scaled down versions of aircraft components. Although computational fluid dynamics simulation is used extensively for the aerodynamic design of aircraft, the testing of design using a physical model in a wind tunnel is still an essential step to validate the design. The external shape of the wind tunnel model has to conform to the full size aircraft design. The internal structure of the model has to incorporate all the features for instrumentation and attachment requirements of the test, as well as maintaining a similar structural behaviour of the full size aircraft. Typical wind tunnel test requires the collection of pressure data from a pre-determined pattern of points on the surface of the model. The points are the location of the 'pressure tappings'. Tubes (tubings) run inside the model to connect the pressure tappings to the pressure measuring instruments. The design problem illustrated here is the automated generation of the tubing design. It consists of a set of runners on the surface of an aircraft component. This set of channels links the pressure tappings with a pocket feature. Inside the runners, tubes for measuring the pressure in the taping position will be allocated.

ICED 01 - C586/131

103

Figure 4. shows a simplified configuration of the tubing system in a nacelle component.

Figure 4. Tubing design for a nacelle component.

To simplify the illustration, the cylindrical shape of the nacelle has been flattened to a 2D plane. In Figure 5 (left), the problem can be stated as: Problem statement: Link the pressure tapping points with the pocket using a set of straight runners. Constraints: 1. The runners cannot overlap with each other. 2. The width of the runner must be sufficient for channels that contain more than one tube.

Current knowledge abstraction of the tubing design configuration is illustrated in Figure 5 (right). This design configuration is the approach currently employed by the designers to solve the design problem.

Figure 5. Pressure tapping design and the current design configuration.

After the application of the guidelines proposed in this paper, a new design configuration is developed. The new design concept is illustrated in Figure 6. The design knowledge has been abstracted into the three types of objects: primary channels, secondary channels and tertiary channels. The behaviour of the objects is controlled by a set of engineering rules. An example of engineering rules would be the one controlling the behaviour of the primary and secondary channel. Such engineering rules would decide whether the secondary and primary channel He on the right or on the left side of the pressure tapping, depending on the position of the secondary channel. As can be seen in the example, all secondary channels except the one in the very left side are located at the same side in which the tapings are arranged with respect to the pocket.

104

ICED 01 - C586/131

The application of the criteria and guidelines are explained here: Repetitive: The defined objects are heavily re-used in the design problem, especially the primary runner. Independent: Design objects are almost independent. Their dependency is based on simple relationships such as the position of other objects. For example, the position of the primary channels at the right or left side of the tapings depends on the position of the secondary channels. Generic: Objects are defined in a generic way. For example the same object "secondary runner" is used when only one tapping has to be driven to the tertiary channel as well as in the case of ten tapings. Extensible: The design objects here defined have been used in a nacelle design. They can be used in different problems in the environment such as the case of a wing model design. Before the application of the guidelines, the knowledge for laying out the runner is represented in a variety of objects based on the different locations of the pressure tappings. This results in a large number of runner designs. The guidelines help to reduce the different type of runners to three. This represents the best concept to connect different pressure tapping patterns on different models.

Figure 6. Proposed solution for the design problem.

Conclusions

This paper illustrates just a small and simplified part of the work developed in the research/industry partnership. In its current status, the KBE application has transformed a design activity that can last more than a week into a two hours process. The knowledge abstraction approach proposed here has demonstrated its feasibility in the KBE implementation for this industrial problem. The application of the guidelines proposed here have been useful to prepare the business case for introducing KBE technology to the industrial collaborator. It is expected that future extension of KBE application to the different members of the product families will be less expensive by the sharing and reuse of existent

ICED 01 - C586/131

105

codes. Further extension of knowledge representation in this industrial project will be the extension of KBE implementation from design to downstream activities such as manufacturing and/or assembly procedures. Current KBE systems do not provide clear separation of design object and engineering rules. A framework that enables this separation and provides the ability to manage both elements would allow better adoptions of the RKC approach. This framework could be supported by the emerging technology of "software reuse" [10] to increase the quality and productivity of the coding processes. References [1] Cooper, S., Fan, I. & Li, G. "A Best Practice Guide - Achieving Competitive Advantage through Knowledge Based Engineering", Department of Trade and Industry (DTI), UK. June 1999. Li, G., Cooper, S. & Fan, I. "KBE application and research in UK". Proc. International Conference on Advanced Manufacturing Systems and Manufacturing Automation, Guangzhou, China, 2000. Fan, I., Cooper, S., Li, G., Sehdev, K. & Grealy, M.T. "Knowledge-based Engineering as a CE Tool to Achieve Fast Design Iterations". Proc. ISPE International Conference on Concurrent Engineering, Bath, 1999. Sainter, P., Oldham, K. & Larkin, A. "Achieving Benefits from Knowledge-based Engineering Systems in the Longer Term as well as in the Short Term". Proc. International Conference on Concurrent Enterprising. Toulouse, 2000. Klein, R. "Knowledge Modelling in Design - the MOKA Framework", Proc. International AI in Design Conference. Worcester, 2000. Lovett, P. & Bancroft, C. "Knowledge Transfer for Knowledge Based Engineering". Proc. Technology Transfer and Innovation Conference, London, 2000. Li, G., Cooper, S., Garcia-Fornieles, J.M. & Fan, I. "Knowledge Reuse: Experiences Gained from Integrating Manufacturing Knowledge into Product Design". Proc. 1CED'99, International Conference on Engineering Design. Munich, 1999. Sainter, P., Oldham, K., Larkin, A., Murton, A. & Brimble, R. "Product Knowledge Management within Knowledege-based Engineering Systems". Proc. DETC'00, ASME 2000 Design Engineering Technical Conference and Computers and Information in Engineering Conference. Baltimore, 2000. Lagos, M. "MSc. Thesis: Engineering Knowledge Maintenance". Cranfield University. Cranfield, 2000. Structuring, Reuse and

[2]

[3]

[4]

[5] [6] [7]

[8]

[9]

[10] Hashim, K. & Key E. "A software reusability attributes model". International Journal of Computers Applications in Technology, Vol. 8, Nos 1/2, pp. 69-77. Corresponding author Dr. Ip-Shing Fan Cranfield University, Department of Enterprise Integration, Cranfield Bedford MK43 0AL, United Kingdom, Tel: +44 (0) 1234 754 073, Fax: +44 (0) 1234 750 852, E-mail: i.s.fan@cranfield.ac.uk, http://www.cranfield.ac.uk/sims/cim/people/fan.htm Bermell, Fan, Li 2001

106

ICED 01 - C586/131

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

NEW TECHNIQUES FOR DESIGN KNOWLEDGE EXPLORATION - A COMPARISON OF THREE DATA GROUPING APPROACHES
P C Matthews, P M Langdon, and K M Wallace Keywords: Design understanding; information analysis, classification and retrieval; knowledge acquisition; machine learning.

Introduction

The overall aim of this paper is to compare the utility of a wide range of data grouping methods used for the purpose of exploring the inherent structure of knowledge in design databases. For example, this could include knowledge about analytical descriptions of the similarities between various substances in a database of materials or the relationships between pairs of parameters in a database of mechanical designs. Grouping methods have been used previously for machine learning purposes [1], however our main aim is to produce human-usable knowledge from such systems. For this purpose, the principal objective is to contrast three different methods of data grouping: non-hierarchical clustering; hierarchical agglomerative cluster analysis; and partitioning around medoids. On the basis of this comparison we aim to evaluate the effectiveness of the techniques as data exploration methods for designers who wish to gain a greater understanding of a specific design space. The techniques used are examples from our research that represent techniques that are currently available. These include those that are conventional and novel; hierarchical and nonhierarchical; and with differing salience of implementation. The comparison will focus on four criteria concerning: (1) the assumptions made; (2) the main features of the grouping method; (3) the data input requirements and output format; and (4) the reliability and repeatability of the method. For each method an evaluation will be given along with a case study.

2 Clustering as data exploration: previous work

Designers frequently operate with large sets of objects, which can be of several types: parameters, materials, shapes, and so on. These sets are often larger than humans can cope with [2], and hence need to be grouped (or clustered) according to some criteria. An early example of data exploration was the computation of the 'linear discriminant' to differentiate between three different species of the iris flower [3]. This was a statistical method for identifying the linear expression from a given multi-variate distribution with maximal variance. This expression is then used to identify class boundaries. Clustering methods can result in exclusive sets, i.e. each object lies in exactly one group. Overcoming the single class membership limitation, hierarchical clustering methods modify the cluster membership requirement and therefore allow clusters to merge [4]. Hence, every

ICED 01 - C586/222

107

pair of objects will belong to some parent class to a certain degree. We contrast this with a non-hierarchical clustering technique that has the advantage of being able to associate any object with a number of groups. Such non-hierarchical methods were initially investigated with the aim of generating thesauri [5]. This is a non-hierarchical application as different words can have the same meaning (synonyms) while the same word can have different meanings (homonyms). These methods have all been applied to design [1, 2, 6], but with little attempt match method to type of design data. We summarise three design cases and describe a potentially appropriate technique for analysing the given design domain.

Clustering applications

For a given design domain, a number of features or criteria are selected that describe this domain, and the object collection is grouped according to these. Usually grouping is based on the notion of 'distance' between objects. This may be calculated in different ways and the choice of distance metric represents a critical assumption of grouping methods. Once clustered, the database of objects can be browsed according to the revealed natural groupings, if they exist. Selection can then be coupled with the designer's criteria, and selected members used to identify other objects within their natural cluster that might not have otherwise been identified. The analysis of these clusters can reveal implicit structure within the design domain. In this way, explicit knowledge may be extracted from relationships that are implicitly embedded within design databases.

3.1 Non-hierarchical clustering

Most clustering methods generate either exclusive partitions or hierarchies of objects, namely each given object belongs to only one 'parent' set. In a non-hierarchical clustering method, it is possible for an object to belong to several parent sets (see Figure 1). This is useful where the description used for the objects being classified does not necessarily discriminate totally.

Figure 1. Comparison between hierarchical (left) and non-hierarchical (right) clustering.

A Jardine clustering was implemented to generate non-hierarchical clusters of design objects based on a similarity between pairs [7]. This is useful when there is only one measure available to compare any two objects. The designer decides how much overlap, k, between groups is permitted. A large overlap value allows greater flexibility, at the cost of more computation. The Jardine algorithm involves checking all subsets of size k + 2, which is quite inefficient.

108

ICED 01 - C586/222

The result of the algorithm presents a novel grouping of design objects for different similarity thresholds, without having to repeat the expensive computation. This method has been applied to design and evaluation parameters from a gas turbine aeroengine combustor. Combustor design is based on empirical methods, which result in slow and costly design iterations. The aim was to group the design parameters and evaluations (design components) together according to similar types of behaviour, such that further investigation could be focussed on sets of components that were likely to be related. Traditional correlation and regression techniques were of little use here due to the highly non-linear nature of combustor design. Instead, a Self Organising Map (SOM) was used to 'learn' the design domain [6]. The SOM generates a simplified topologically consistent representation of the original distribution [8]. By analysing the component maps generated by the SOM, it was possible to measure the 'behavioural similarity' between pairs of components. A non-hierarchical clustering method is desirable, as it was not known if the components belong to exclusive groups. The Jardine algorithm generated sets of components with similar characteristics. These sets are then further analysed for relationships using more traditional methods, such as scatter plots. This represents a significant saving over directly examining all pairs of components. This novel method generated over 40 relationships between the combustor design components. These were then sent to domain experts for further verification. This provided the opportunity for the domain experts to evaluate the relationships for novelty and applicability. Of these relationships, 65.2% were thought to be accurate, 43.5% were believed to be important for a designer to be aware of, and 37.0% were thought to represent a few years of design experience. The overall result of this process is a method of extracting implicit domain knowledge from a database of previous designs. This results in a greater explicit understanding of the domain, and hence more rapid preliminary design phase. The technique, although computationally expensive, has proved to generate intuitive groupings that are easily analysed. The input format is quite flexible, permitting both quantitative and linguistic data to be processed, although the direct output from the system does require further processing to generate suitable human-readable relationships. However, this final process is quite simple. By testing on various subsets of the available data, it has also been shown to be quite robust.

3.2 Hierarchical agglomerative clustering

A standard methodological technique, hierarchical agglomerative cluster analysis, was employed as a novel exploratory technique for the classification of engineering materials. Classification plays a key role in materials science where an understanding and manipulation of materials depends on grouping by similarity and indexing. Designers will rank materials according to various properties, and select on the basis of which material best fits the criteria. However, this process can lead to early discounting of suitable materials if the selection criteria are erroneously biased. Forty materials were grouped on the basis of eight thermal and mechanical properties such as density, thermal properties and hardness and the resulting groupings compared to a conventional materials science classification. The same materials set was also clustered on the basis of the aesthetic aspects of their appearance, such as colour, transparency or reflectivity. The materials were clustered using a hierarchical agglomerative method yielding a hierarchy comparable to existing materials science taxonomies. A Euclidean distance measure was cal-

ICED 01 - C586/222

109

Figure 2. Materials clustering by the hierarchical agglomerative method.

culated between each pair of materials based on their parametric descriptions. Hence, the input parameters for this analysis were a complete set of quantitative measurements of a number of parameters or information about the presence or absence of certain features, such as opacity or produced-shape set. Grouping was carried out iteratively with an increasing stress or distance parameter. Grouping was on the basis of a single-linkage method whereby a candidate material is grouped with another material or an existing group of materials on the basis of the closest distance between them. Other linkage methods exist, for example a candidate could join with a single object or group on the basis of the average distance between them or the furthest distance. These methods were tried but did not produce great differences in the resulting hierarchies. The results showed that engineering material properties could be grouped by the method in ways that were deemed by a material scientist to reflect traditional groupings (see Figure 2). The method was successful in grouping aesthetic properties and process capabilities. For example, the clustering of materials on the basis of conventional engineering parameters produced similar hierarchies to science based groupings. However, some materials such as aluminium foams were grouped outside of the metals and epoxy/carbon fibre composites were grouped with metals rather than other polymer composites (see Figure 2). For the aesthetic properties, glass ceramics were grouped with alumina as non-transparent while soda-lime glass, acrylic and epoxy group together because of their potential for translucency. The technique was tested for reliability through the use of a range of grouping methods and distance metrics with the same materials set. It was found that the analysis was robust over methods for this data set and for the other sets reported. This data exploration technique has been applied in a trial [?] and shown promise for extending the approach to further sets of material, product or design attributes. It was also concluded that new material groupings resulting from the use of the method might give rise to new design opportunities.

110

ICED 01 - C586/222

3.3 Partitioning around medoids

Mechanical design concepts can be created by the combination of basic machine elements. DESYN is such a system based on an algorithm which exhaustively synthesises solutions [2]. However, due to the great variety and number of solutions to be explored, it is unlikely that a detailed understanding of the potential of all individual solutions will be achieved. The partitioning-around medoids method implemented a novel method of clustering the solution configurations to reduce the number of solutions that the designer needs to consider. This was done by presenting the designer with representative solutions (medoids) that were by-products of the clustering process, revealing hidden structure. Given a distance matrix for all objects that is calculated using a generalised Euclidean distance measure with both quantitative and qualitative input data, the technique reverses the conventional clustering approach and repeatedly partitions the data set to attain the required number of groups. This is managed on the basis of iterative selection of a set of representative group medoids and minimisation of average group member distance to the medoid. The method yields statistics about inter and intra group distances, enabling convergence on the hidden 'natural' data structure. The implementation was programmed in C and Perl within a research software prototype of a user interface intended to allow exploration of generated solution concepts in the mechanical design domain (see Figure 3). Initial experiments examined a clusterings of two sets of around 20 solutions resulting from a synthesis with solutions containing up to five elementary machine elements. Clustering was based on an element-pair feature count.

Figure 3. Graphical user interface for partitioning of solution space.

Figure 3 shows the output of the method after processing by the graphic user interface. Here, for a given cluster number the groups are shown as "sun" graphics each of which represents a grouping. The planet circles represent the group members. The average distance of members from the centre of the cluster is represented by the diameter of the "sun" circle. The membership and identity of the solutions is simultaneously represented in the fields on the right, which indicate the medoid representative of each set (the sun) when that cluster is clicked on. Different partitions can be generated and the relationship between group size and distance statistics visually examined. Selection of a solution can be used to initiate the creation of a 3D visualisation of the mechanical solution chain. The results of this method were compared with how designers would classify the same objects according to their engineering experience. These classifications were scored for percentage similarity to the classifications generated from a number of different DESYN clusterings of the same set. The results demonstrated a 69% agreement for a solution set of 3, 4, and 5 clusters and an 80% agreement for a solution set involving more than 5 clusters. This gives an

ICED 01 - C586/222

111

average score of 74% commonality compared with a 55% commonality resulting from random cluster testing. Hence, this method was taken to generate summaries of a given solution set that correspond to designers' experience. In addition, the method offers an unbiased overview of the solution space in the form of the representative medoids, while at the same time allowing detailed examination of individual groups and solutions.

Comparison of methods

Preliminary comparison has been made of three different techniques for data exploration. The four criteria that were applied to the three methods were: 1. Does the method require realistic assumptions; and what are the implementation issues arising? 2. Does the method group in a realistic and intuitive way? 3. Does the method require an input format that is difficult to achieve and can it produce output that is practically usable? 4. Does the method produce the same groupings for data samples from the same population, irrespective of order or sample size? Non-hierarchical clustering requires there to be a metric on the given space. Further, the designer needs to determine the amount of overlap the clusters can have and a threshold distance that will distinguish when two objects share a class. The algorithm was implemented in MATLAB, which makes it simple to interface with other mathematical code or access tabular data. This method is however computationally expensive both in time and memory requirements, and this can prove to be restrictive for very high-dimensional spaces and highly overlapping requirements (the case study reported here had 37 dimensions and required about 500Mb RAM and several hours computing time on a 300MHz Pentium class processor to process a 3-member overlap). The output generated is a series of sets containing objects that are similar to each other on the basis of the chosen metric. The non-hierarchical nature of the method means that it is possible for an object to be in more than one set. This output is strictly dependent on the distance matrix, and is therefore robust to re-sampling and re-ordering of the objects. The hierarchical agglomerative method requires conventional assumptions to be made about the data measurements. For example, it is assumed that a Euclidean distance metric adequately describes the distance relationships between objects in the data set. Other metrics are possible, but give rise to less intuitive relationships. It is also assumed that the data set does, in fact, cluster in the feature space, and that the analysis gives the same result with the use of different grouping methods. It is further assumed that features used to group objects are weighted according to their relative contribution to indexing. This method assumes that group membership will be exclusive though fuzzy and overlapping methods do exist. Implementation of the approach is ubiquitous, available in C and FORTRAN code form or in a variety of commercial packages, and the algorithm terminates quite quickly (under 1 second on a 300MHz Pentium class processor). The input requirements are simple: a tabulated list of measurements or categorical classifications are easy to generate. Output, however, is less straightforward. The method yields a hierarchical tree structure that does not, in itself, imply grouping. If present, the natural grouping of the data is indicated by the distance level at which the maximum rate

112

ICED 01 - C586/222

in cluster joining occurred. Output lists the distance at which objects joined to form the cluster tree and this representation is not well suited to data interpretation and the investigation of knowledge structure. Reliability and repeatability are easily tested by examining output stability with the use of alternative metrics and grouping methods or of data re-sampling or reordering. Partitioning around medoids requires the same assumptions about distance metrics as the previous method. However, the partitioning approach does not require a choice of grouping methods as the partitioning algorithm attempts to best fit the data to the required number of partitions. It is also assumed that the data set does, in fact, cluster in the feature space, but in this case the method yields statistics for fit that enable the grouping nearest to the natural structure to be obtained by altering the partition number. Like the previous method, it is also assumed that features used to group objects are weighted according to their relative contribution to indexing. Implementation of this method required the coding of the algorithm in C and the embedding of this into a user interface that managed input and output and the user's choice of parameters. This algorithm typically takes in the order of 10 seconds to complete on a 300MHz Pentium class processor. The output of a design synthesis algorithm was automatically processed for input to the partitioning algorithm and the output was presented to the user in graphical form as described in Section 3.3. The required input to the algorithm was similar to that of the previous method and the output took the form of partition membership lists and inter- and intra-group statistics. This output format is well suited to investigation of data structure as the partitioning yields a representative for each partition that can be interpreted in terms of the data set features. Accuracy of grouping is evident from the output statistics which also show the potential for automating the process of finding natural partitions. Reliability was tested using known test data sets and by re-sampling of large data sets to test for stability of partitioning.

Conclusions

We conclude that (1) non-hierarchical methods may be appropriate where the objects are likely to belong to more than one group; (2) hierarchical agglomerative methods allow a wide range of distance measures and grouping methods to be tried; and (3) partitioning around medoids gives a useful representative for each group, together with a rich statistical description of the data. Of these methods, the non-hierarchical algorithm provides a novel means of grouping objects. The objects grouped by this method are not constrained to be placed in one group, but rather are placed in as many groups as necessary. The number of groups that result from this method is determined by the designer setting a maximum distance permitted between objects. This method is however limited by its computational requirements. This paper has highlighted the strengths and weaknesses of these methods, with the objective of suggesting which method is most appropriate for a given clustering problem. These methods contribute to the design process by simplifying large databases of design objects. As discussed in this paper, these objects can take several forms ranging from parametric descriptions, material properties, and functional descriptions. This simplified representation can be used to gain knowledge from the given design domain by presenting the available information in a structure that permits a designer to readily observe both common and differentiating elements from within this domain. A direct result of this understanding is the ability to proceed through the design process more rapidly due to identifying the general design region a designer wishes to target. Further work is to be undertaken to provide specific guidelines aimed at helping de-

ICED 01 - C586/222

113

signers select appropriate knowledge exploration tools for any given design stage and product domain.

Acknowledgements
This work is funded by the University Technology Partnership for Design, a collaborative research project between the universities of Cambridge, Sheffield and Southampton; and with industrial partners BAE SYSTEMS and Rolls-Royce. The Materials science data set analysis was contributed by Kara Johnson and Mike Ashby. Patrick Langdon is an EDC Senior Research Associate supported by the UK EPSRC (grant number: GR/M232636). References [1] Y Reich and S J Fenves. Concept Formation: Knowledge and Experience in Unsupervised Learning, chapter The Formation and Use of Abstract Concepts in Design, pages 323-353. Morgan Kaufmann, Las Altos, CA, 1991. [2] P M Langdon and A Chakrabarti. Cluster-based browsing and visualisation of large mechanical design solution spaces. In H Bullinger and P H Vossen, editors, 8th International Conference on Human Computer Interaction (HCI99), pages 93-95, 1999. [3] R A Fisher. The use of multiple measurements in taxonomic problems. Annals of Eugenics, 7(2): 179-188, 1936. Reprinted in Contributions to Mathematical Statistics, John Wiley, New York, NY (1950). [4] L Kaufman and P J Rousseeuw. Finding Groups in Data: An Introduction to Cluster Analysis. Probability and Mathematical Statistics. John Wiley, New York, NY, 1990. [5] K Sparck Jones. Experiments in semantic classification. Mechanical Translation, 8(34):97-112, 1965. [6] P C Matthews, K M Wallace, and L T M Blessing. Design heuristics extraction: Acquiring engineering knowledge from previous designs. In J S Gero, editor, Artificial Intelligence in Design 2000, pages 435-453. Kluwer, Dordrecht, 2000. [7] N Jardine and R Sibson. The construction of hierarchic and non-hierarchic classifications. The Computer Journal, 11(2): 177-184, 1968. [8] T Kohonen. Self-Organizing Maps. Number 30 in Springer Series in Information Sciences. Springer-Verlag, Berlin, second edition, 1997. [9] K W Johnson, P M Langdon, and M F Ashby. Grouping materials and processes for the designer: an application for cluster analysis. Materials and Design, 2001. submitted.

Peter Matthews Engineering Design Centre, Cambridge University, Trumpington Street, Cambridge CB2 1PZ, England, Phone: +44 (01223) 332709, Fax: +44 (0870) 133 6961 http: / /www-edc . eng. cam.ac . uk/ E-mail: pml31@eng. cam.ac .uk IMechE 2001 114 ICED 01 - C586/222

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

COMPUTER-SUPPORTED SYSTEMATIC DESIGN AND KNOWLEDGE MANAGEMENT IN THE EARLY DESIGN PHASE
E Frankenberger Keywords: Design information management, knowledge management, systematic product development, product structuring, mechanical engineering industry.

Introduction: The importance of information availability and systematic work in the early design phases

The analysis and identification of the requirements, the search for solution principles and the analysis and decision of the solution variants are important 'critical situations' in every design process [1]. Especially in the early design phases 'task clarification', 'concept' and 'embodiment design', the course and main result characteristics of a product development project are determined. For example, a big amount of the later production costs is a consequence of the decisions for the solution principles taken in the concept phase, whereas the efforts and costs for design changes increase during the progress of a product development project. In order to make decisions between different solution variants in an early stage of a project in the most objective way, it is necessary to have access to as much relevant information about these solutions as possible. Investigations in industry indicate, that a major source of information is the experience of colleagues from former design projects [2]. When we take a look at the products in the field of mechanical engineering and industrial product development, this empirical result does not surprise: many companies develop complex products in various series, such as different types of chain-saws, electric tools such as drill hammers or different format sizes of offset printing presses. Between the product lines of those companies, the sub-problems to be solved are comparable to a certain extend. Consequently, a new design contains results of working steps, which are similar to the results of the same steps in former design projects. For example: the addressed set of requirements after a task clarification is likely to be similar, the set of solution-principles considered to solve a sub-problem can be derived from an earlier project, and the decision between different solution variants will be based on a similar set of criteria. Such engineering knowledge of a company is more or less located in the brains of the engineering designers. But this 'corporate' knowledge underlies different erosions: The capacity of the human brain is limited and the facts which designers remember underlie emotional filters. Moreover the access to the knowledge can be restricted or even can get lost totally: designers are not available because they are out, they are ill, or they retire or leave the company due to other reasons. Consequently, the aim must be to safe and to convert the individual design know-how into company know-how, which is entire, context related and accessible at any time.

ICED 01 - C586/262

115

It is obvious, that a structured access to relevant information is one key for the improvement of design work. Another success-factor is a flexible but systematic proceeding of the design work, as indicated by empirical studies [3]: A clarification of the task at the beginning, the structuring of the overall-problem into sub-problems, the search for solutions for the subproblems, the analysis of these sub-solutions, their combination to a concept and the evaluation of a solution are common steps in every systematic approach of problem solving and not limited to design tasks [4]. Results of these steps are a requirements list, a structure of sub functions, principle solutions with remarks about their characteristics, combinations of sub-solutions and evaluations according to criteria derived from the requirements. Figure 1 shows the steps and their results according to VDI 2221 [5].

Figure 1. Steps and results of design work in the concept phase according to VDI2221 [5].

When we compare these steps with the required design knowledge in the early design phases, it becomes obvious, that a methodical procedure in the concept phase produces exactly the information, which is also necessary in following design projects with similar sub-tasks. There is a direct synergy between methodical work in the early design phases and the capturing and reuse of design knowledge. For implementing this synergy, it needs special software for supporting systematic work in the early design phases, for compiling design information automatically in a structured way and for providing an easy access to it.

Situation of computer support in the early design phase

Up to now, computer support in engineering design is focused on the modelling of geometry with computer aided design (CAD) systems and on providing product related data for the following stages of the product life cycle, e.g. by product data management (PDM) systems. In the last years, only few approaches where introduced for supporting the determining steps in the concept phase, for example the tool 'Invention Machine', which focuses on the solution development by providing solution principles derived from existing patents or physical and chemical effects [6]. Nevertheless, it can be stated, that engineering designers start their work mostly without an appropriate access to the entire information, which was collected, in former similar projects. Very often this leads to a "reinvention of the wheel". Additionally,

116

ICED 01 - C586/262

information regarding rejected solutions is very seldom collected and thus not available for later discussions. On the process side, there are a lot of theoretical considerations available concerning systematic design, design methodology and knowledge management in engineering design. In industrial practice, systematic approaches in engineering design often struggle with the limitations of time, methodical education and support from the middle management [7]. Unfortunately, practice-oriented software-tools for supporting the daily design work based on systematic design are nearly not available.

Key demands and development of a systematic design and knowledge management tool

The general demands on a practice oriented software tool for knowledge management and systematic support in the early design phases are high. Under the permanent time pressure, working with the software tool has to speed up the design work from the first day of use, even in the first hour. It is obvious, that the awareness of the value of compiling information for later projects will not prevent the designers from switching back to their usual procedures, if the new tool would not make the actual working step significantly easier. This means, the tool has to support the designer in creating the design documents he need to create anyhow, but in a much more comfortable and automated way compared to paper and pencil or office tools such as Microsoft Word or Excel. The created documents need to be standardized according to norms and should be demanded by the management in order to fulfil standards such as ISO 9001. If these demands are fulfilled, working with the tool will be considered as a "quick win" even in the first time, when there is not the advantage of accessing relevant information or reusing documents from former projects. Regarding the methodological support, an education in systematic design should not be a prerequisite for working with the tool. It has to be very simple and flexible in operation and obvious in its general methodology. Driven by these key demands the software tool PROSECCO ('Programm zur strukturierten Erfassung von Konstruktionsdaten', program for a structured compilation of design data) was developed for the support of the early design phases based on systematic design and design methodology by Pahl & Beitz [4], Birkhofer [8] and the VDI-Guideline 2221 [5]. The development of PROSECCO started in 1994 as a diploma thesis at the Darmstadt University of Technology supervised by the author in cooperation with the company STIHL, the famous manufacturer of chainsaws [9]. The university spin-off company TRIGON SOFTWARE, founded by the diploma student Helmut Berg, elaborated the software in the following years. Since 1997, the software was sold to 40 Universities of Technology and Technicons in Germany, and to the product development departments of 16 installations in companies of various branches.

The user-concept of Prosecco

It cannot be the aim of this paper to explain the various functionalities of the software in detail; specific questions are addressed in the handbook [10]. This chapter introduces the concept for compiling design information in so-called "working-folders" and the structuring of these working-folders of different products and projects. A main idea of the working-folder concept is, that the design information is collected on every level of a problem in the same

ICED 01 - C586/262

117

way. On every level of detail, the information for each sub-function/component is collected with a four-step-procedure in a working-folder with the headers 'Requirements', 'Solution ideas', 'Conformity with requirements' and 'Evaluation of solutions' (see Figures 2, 3, 5, 6).

4.1 Analysis of requirements

The requirements can be collected in a structured way according to the guideline of main task characteristics [3], according the checklist following the product life-cycle [8] or according to a self defined systematic. The purpose is to structure the requirements into logic groups and to raise questions for an entire analysis of the task or sub-task. Prosecco also asks for a differentiation between demands ('musts') and wishes ('nice to have'). This differentiation is important for the later analysis, if a found variant is a solution to the problem or not. The values to the discussed requirements can be filled into a template and are thus available for the system. The requirements can be collected very quickly supported by the tool, either in a blanc new file or by changing an existing requirements list. The formatting work is done automatically by pressing a button. Figure 2 shows the template for collecting requirements and a formatted requirement list.

Figure 2. Template for collecting requirements and an automatically formatted requirement list.

4.2 Search for solution variants

The first step of a search for solutions is to differ the functions that should be solved. As an option, a decomposition of the problem can be chosen on this level in order to search for solution variants for each sub-function separately. The solution-variants can be discussed by their advantages or disadvantages. Moreover, general remarks such as patent numbers, telephone numbers of experienced colleagues or notes about the competitors can be collected. Additionally, sketches can be created easily by the tool or can be copied into the Prosecco graphic module from CAD and all major graphic programs. An useful tool for group discussions and presentations is the automatically formatted solution printout. Figure 3 shows the file 'solution variants' of a variant of the task "lifting jack" and the formatted solution printout.

118

ICED 01 - C586/262

Figure 3. Template for discussing solution variants and an automatically formatted solution printout.

Moreover, a morphological matrix can be created automatically, which provides an overview of the solution variants for all sub functions. Figure 4 illustrates a morphological matrix with the solutions for each sub function and an overview of the solutions with advantages, disadvantages and remarks, which can be plotted in large format for group discussions.

Figure 4. Morphological matrix and overview of the solutions for the lifting jack for cars with remarks.

4.3 Analysis of solution variants

The next step is a check, if the found solution variants to a sub function are solutions according the requirements or not. This check is done supported by the requirements list. If there is a contradiction to a demand, the solution is crossed out with a reference to the analysed reason for the contradiction. If there is only a contradiction to a wish, the reason is captured as well, but the variant is still a solution that will be evaluated in the next step. An interesting functionality of Prosecco is, that a change of a requirement can raise solution variants to be valid solutions again, which where dropped before due to contradictions with this requirement. Figure 5 shows the analysis of a solution variant with a contradiction to a demand.

ICED 01 - C586/262

119

Figure 5. Analysis of a solution variant with the reason for dropping the variant.

4.4 Evaluation of solutions

After the analysis, if the solution variants follow the requirements, only solutions are to be discussed afterwards in the evaluation phase. The evaluation in Prosecco is based on the technical-economical evaluation according to VDI-Guideline 2225 [11]. Criteria are defined and the solution variants are evaluated according to these criteria. Figure 6 shows how to put emphasis on specific criteria and the automatically generated strength diagram according to VDI 2225.

Figure 6. Evaluation of variants of the lifting jack and strength diagram according to VDI 2225.

4.5 Structuring design information

The working folders and their single files can be copied and can be taken as a basis for the documentation of new projects. The working-folders are saved in a structure compared to a Microsoft explorer system. The management should define this structure for each type of

120

ICED 01 - C586/262

products, in order to have a similar structure for similar projects. At Heidelberg, sheetfed offset printing machines are structured in a function and subcomponent oriented way. In Prosecco, any structure can be generated easily. Different product lines containing various projects with their product structures are saved in Prosecco. When starting a new project, any existing project or parts of it can be taken as a starting copy to speed up the work and to increase the quality. Thereby, a full text search function helps to find any piece of information in the system. Figure 7 shows a product structure with different levels as used at Heidelberg.

Figure 7. Product structure used for sheetfed printing presses at Heidelberg, and full text search.

Experiences and conclusions from industrial practice

At Heidelberger Druckmaschinen, a field test of Prosecco with five designers was conducted for 6 month in 1998 and 1999. The feedback of the designers was collected by a questionnaire and by a feedback-workshop. The result at Heidelberg was, that this easy structured computer tool could support systematic design work and knowledge-management in the concept phase. Experiences from other companies support, that the use of Prosecco in industrial practice is experienced to be easy due to the simple four-step-approach of the program. Designers did not need an extra training to work with the tool. At Heidelberg, the acceptance of the tool was high due to a given and well-known function-oriented product structure. Prosecco was also used as a tool for compiling design knowledge from colleagues before their retirement. In interviews structured by Prosecco, many details on components and sub functions of own and competitive solutions from yesterday and today were discussed and collected with their advantages and disadvantages. Heidelberg finally bought two floating licences of Prosecco. An important prerequisite for the successful use of Prosecco is the support of the management and the integration of the tool into the project management and design review culture of the company. This means the implementation of methodical design procedures with standardised documents, which the engineering designers have to create for the documentation of their concept decisions. The management has to ask for these documents for tracking the work in the determining early design phases. In this regard, Prosecco does not only support systematic work of the designers, it also asks for a systematic management culture which pays

ICED 01 - C586/262

121

continuous attention in also the early phases and not only in task forces, when avoidable mistakes due a former lack of leadership are hurting in later project phases. Today, there is still a gap between knowledge management in the early design phase (which is more or less reduced to the question of social contacts and communication), and PDMfunctionalities in the embodiment and detail design. Prosecco can help to compile the conceptual design knowledge and to link it to the further product data management. At Heidelberg, this task will be solved together with the implementation of a new PDM-system. References [1] [2] Badke-Schaub, P. and Frankenberger, E., "Analysis of design projects", Design Studies, 20, 1999, pp.465-480. Badke-Schaub, P. and Frankenberger, E. (1999), "Design Representations in Critical Situations of Product Development", Proceedings of the 4th Design Thinking Research Symposium, MIT, Boston, 1999. Pahl, G., Badke-Schaub, P., and Frankenberger, E, "Resume of 12 years interdisciplinary empirical studies of engineering design in Germany", Design Studies. 20, 1999, pp. 481-494. Pahl, G., Beitz, W., "Engineering Design", London, Springer, 1996. VDI-Richtlinie 2221, Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. Dusseldorf, VDI-Verlag, 1986. Lindemann, U., Amft, M., ABmann, G., Wulf, J., Birkhofer, H., and Wallmeier, S., "Rechnerunterstutzung fur fruhe Phasen der Entwicklung", F&M Feinwerktechnik, Mikrotechnik, Mikroelektronik. 106, 3, 1998, pp. 123-127. Jorden, W., Havenstein, G. & Schwarzkopf, W., "Vergleich von Konstruktionswissenschaft und Praxis; Teilergebnisse eines Forschungsvorhabens", Proceedings of ICED85. Zurich, Edition Heurista, 1985. Birkhofer, H. "Hohere Konstruktionslehre", Vorlesungsumdruck. TU Darmstadt, 1993. Berg, H., "Rechnerunterstutzte Losungsentwicklung komplexer Serienprodukte", Diploma Thesis, TU Darmstadt, 1996.

[3]

[4] [5] [6]

[7]

[8] [9]

[10] Berg, H. and Berg, W., "Prosecco-Handbook", Darmstadt, Trigon Software, Berg&Partner Software GbR, 2000. [11] VDI-Richtlinie 2225, Technisch-wirtschaftliches Konstruieren, Dusseldorf, Verlag, 1977. Dr. Eckart Frankenberger Heidelberger Druckmaschinen AG, SFE, Kurfursten-Anlage 52-60, D-69115 Heidelberg, Germany, Tel.: ++49 (0)6221-92-3567, Fax: ++49 (0)6221-92-6209, e-mail: eckart.frankenberger@de.heidelberg.com IMechE 2001 VDI-

122

ICED 01 - C586/262

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DEKAS - AN EVOLUTIONARY CASE-BASED REASONING SYSTEM TO SUPPORT PROTECTION SCHEME DESIGN

G West, S Strachan, J McDonald, A H B Duffy, J Farrell, and B Gwyn Keywords: Expert systems, case-based reasoning, web-based systems, knowledge acquisition, knowledge representation, design re-use, best practice

Introduction

This paper describes a decision support system being developed in conjunction with two UK utility companies to aid the design of electrical power transmission protection systems. A brief overview of the application domain is provided, followed by a description of the work carried out to date concerning the development and deployment of the Design Engineering Knowledge Application System (DEKAS). The paper then discusses the provision of intelligent decision support to the design engineer through the application of case-based reasoning (CBR). The key benefits from this will be outlined in conjunction with a relevant case study.

Overview of Protection Scheme Design

The electricity transmission grid transports electricity from the generators (e.g. power stations) to the distribution companies at high voltages. The voltage is then "stepped-down" to supply electricity to consumers via distribution networks. There is a requirement to protect the network and associated equipment from possible damage arising from faults on the transmission and distribution networks. The transmission network is composed of large numbers of expensive plant items, and a fault on the transmission network may also lead to a widespread power outage affecting thousands of customers over a large geographic area. In order to minimise the damage to transmission plant and the extent of any outages, protection schemes associated with transmission networks are generally more complex than those associated with distribution networks. This work focuses on the provision of intelligent decision support to protection engineers during the design of protection schemes for electrical power transmission networks. The protection design is dependant upon several factors including, the topology of the network requiring protection, the primary plant type and layout and the interfaces to existing protection schemes in the surrounding area of the grid. Each protection scheme design conforms to fundamental protection principles applied in conjunction with standard company procedures [1]. A common starting point for a protection engineer when confronted with the task of designing a 'new' protection scheme, is to assess the general protection requirements of the section of transmission network and associated primary plant to be protected. This usually involves the identification of past similar protection scheme designs from which specific features of the design may be re-used and lessons learned applied. Typically,

ICED 01 - C586/508

123

protection engineers will rely upon their own experience, or possibly that of a colleague when attempting to re-use design knowledge. In addition engineers will draw upon various references such as company standards, repositories containing network details and other relevant company resources.

The Requirement for Decision Support within the Existing Protection Design Process

The provision of decision support for engineers involved in the protection design process aims to foster a more co-operative and consistent approach to protection scheme design, through the promotion of 'best practices' [2]. This can be achieved by: Providing a single, 'virtual' source of information for the engineer to draw upon during the design process. Throughout this process there are many different documents, standards and databases which the engineer requires in order to successfully complete the design of a protection scheme. These are stored in both paper and electronic formats, and in a number of different locations. As a result, presently during the design process a disproportionate amount of time and effort is invested in the search and retrieval of relevant information required to perform the various design activities. Harnessing and leveraging the knowledge and experience of protection engineers, accrued over a number of years service within the industry, as a valuable company asset and resource. This also addresses the risk associated with the loss of knowledge and expertise associated with individuals departing the organisation. Promoting the sharing, dissemination and re-use of knowledge throughout the organisation. This is of particular value to engineers with limited design experience, where they may benefit directly from the lessons learned and knowledge captured from their more experienced peers. Exploiting existing historical design data and information associated with past protection scheme design projects.

Existing DEKAS Functionality and Architecture

4.1 The DEKAS Design Process Knowledge Models

The protection design process associated with each company was captured through an extensive series of knowledge elicitation sessions conducted with protection design experts from each company [3]. The captured design process knowledge was then represented graphically using the 'task' and 'inference' layers of the KADS knowledge modelling methodology [4]. These knowledge models illustrate the interaction between the various design process activities through their associated data and information flows. This process knowledge has been encoded within DEKAS using standard database and web (front-end) technology, and deployed via existing company intranets [5].

124

ICED 01 - C586/508

4.2 Integration of DEKAS with Existing Company Resources

As a design project progresses, the DEKAS web front-end can be used to navigate the design engineer through the various stages of the design process. DEKAS consists of a database containing links to existing company data and information repositories and resources, providing the engineer with access to all relevant data, information and documentation necessary to successfully perform the current design activity. These resources can be accessed through an 'information' layer, which provides supporting information relating to the use of a particular resource or a list of pertinent questions to be asked of a particular individual, (note that a resource may be defined as a document, database, spreadsheet or a liasing individual). An electronic file structure exists, encouraging all documents produced as part of a particular design project to be stored in a single, structured format. This document storage facility previously existed as a paper based equivalent. Although DEKAS does not profess to be a document management system, however in the absence of a proprietary document management system some extent of organised structure for document storage is required. This enables effective retrieval of relevant documentation via the links on the navigable web pages, and the CBR facility (discussed later). Integration with an 'off the shelf' document management system at a future date remains a possibility.

Intelligent Decision Support Provided by DEKAS

The decision support feature of DEKAS will be greatly enhanced through the incorporation of intelligent Case-Based Reasoning (CBR) functionality. This emulates existing work practices, which draw upon past experiences and lessons learned to derive the most appropriate 'solution' for a particular 'problem'.

5.1 Role of CBR within DEKAS

A CBR system typically consists of a library of cases (or a case base), where each case is represented by a case structure described by a number of predefined indexing parameters. These indexing parameters can then be utilised by the CBR algorithm to assess the similarity between individual cases as part of the CBR retrieval process. At the highest level, the CBR cycle is described in terms of the following processes [6]: RETRIEVAL of the most similar case/s. RE-USE of data, information and ultimately knowledge associated with the retrieved case, to solve the current 'problem'. REVISION of the proposed solution to meet the specific requirements of the current 'problem'. RETENTION of the 'new' case and associated solution for future application within the CBR cycle. This cycle effectively emulates the intuitive reasoning process adopted by protection design engineers at the inception of a design project. At present, knowledge of previous design solutions are restricted to, and reliant upon, the experience of individual engineers. Therefore

ICED 01 - C586/508

125

re-use of previous design knowledge and rationale requires engineers with extensive design experience to participate in the protection design process. The introduction of the CBR facility within DEKAS is intended to broaden and maintain the knowledge base available to design engineers within the organisation. This is achieved by consolidating individual experiences within a continually expanding case library. For each completed design project, the solutions applied and lessons learned are made accessible to all engineers through the application of case-based reasoning techniques within the existing DEKAS framework. The incorporation of CBR functionality within DEKAS will promote a more formal approach to the retention and dissemination of experiential design knowledge within each organisation. 5.2 Design of the Case-Based Reasoning Functionality Definition of the Nested Case Structure The topology of an area of transmission network and the primary plant configuration largely dictates the design of its associated protection scheme [1]. Therefore, network areas of 'similar' topology and plant layout will generally share 'similar' protection requirements. A basis for the comparison of different areas of transmission network, associated with current and previous protection scheme design projects, is necessary to establish any inherent similarity between the two. This basis for comparison requires characterisation of the network area through a comprehensive list of indexing parameters, which effectively constitute the case structure. The indexing parameters identified must be comparable across all cases and contribute directly to the matching process, i.e. they must have some degree of influence on determining how similar one case is to another. The construction of the case structure reflects the physical construction and topology of the transmission network it describes. Figure 1 illustrates the nested relationship of the case structures intended to describe an area of network, which is the subject of a protection design project. Each 'sub-case' structure represents a physical feature of the network (i.e. Substation, Bay, Plant, Line, etc.) which may itself be described in terms of a number of indexing parameters. In addition, each sub-case structure effectively represents an indexing parameter of the higher level case structure in which it is embedded. Arranging the case structure in this way allows each indexing parameter to be placed in the context of the various network features they describe. This in turn facilitates the matching of the design project on different levels of detail (i.e. project level, substation level, bay level, equipment level), without the requirement for separate case bases. The nested case structure arrangement enables a single case base to be implemented, eliminating unnecessary duplication of indexing parameters within different cases, and providing the flexibility required to accommodate the varying number of substations, substation bays and plant items contained within the network area requiring protection.

Figure 1. Nested Case Structure

126

ICED 01 - C586/508

Definition of the Weightings and Similarities

The 'degree of influence' a particular indexing parameter has in calculating the 'overall' similarity between two independent cases can be defined by the cumulative effect of the weighting and similarity values associated with the indexing parameter itself and indexing parameter value respectively. The contribution of the weightings and similarities attached to the complete set of indexing parameters detailed within the case structure, are combined through the implementation of the nearest neighbour algorithm. This provides an overall assessment of the similarity between the network areas associated with a current and previous protection design project. The roles of weightings and similarities in CBR are well documented [6]. The weightings and similarities applied within the DEKAS case-based reasoning facility have been derived through knowledge elicitation sessions with design experts. During the protection design process the impact of each indexing parameter on the determination of the 'most similar' previous case (i.e. protection design project) through the CBR matching process, will vary depending upon the current stage or activity of the design process. In instances where the indexing parameter makes no contribution to the overall similarity assessment, the weighting value associated with that parameter will be zero. Therefore, each indexing parameter must have associated with it, a separate weighting value relating to, and defined by each activity within the overall design process. The weighting attached to each indexing parameter can then be automatically adjusted to a predefined value, depending upon the stage/activity of the design process at which the CBR facility is invoked. Adjustment of the weightings in this manner is more representative of the intuitive approach currently adopted by engineers, than a CBR system implementing a static set of weightings neglecting the changing task objectives throughout the design process [7].
Integration of CBR with Modelled Design Process
As previously described, the CBR functionality of DEKAS is responsible for the identification of similar protection designs of the past. However, using CBR to return all data, information and documentation associated with a previous design at the beginning of a current design, is unlikely to be the most effective implementation of the CBR functionality for two main reasons. Firstly, at the beginning of the design process the current 'project' case (Figure 1) may be incomplete, with some indexing parameters only becoming available at later stages. Therefore, retrieved design documentation associated with other stages of the design process, not yet encountered by the engineer, may be less relevant. Secondly, providing the design engineer with all project documentation risks overloading the engineer. It is for the reasons described that an evolutionary approach, dependent upon the current stage of the design process, is adopted for the population of a particular case and the return of relevant design information (Figure 2). Therefore, as the design progresses, more information becomes available which can be used to populate the 'empty' indexing parameters describing the current design case. This evolving case description enables constant refinement of the CBR search as the design engineer progresses through the modelled design process. In addition, only information associated with the similar case identified and relevant to the design activity currently being performed by the design engineer is retrieved (e.g. an engineer performing the "produce technical specification" design activity will have the 'specification' document of the 'most similar' previous design project returned).

ICED 01 - C586/508

127

Figure 2. Evolution of Case with Design Process Consolidation of Lessons Learned for Re-use of Design Solutions

Often as an engineer progresses through a 'new' protection design, they are confronted with fresh challenges and problems, which may require an equally novel approach to derive a suitable solution. While the success of a particular design solution may vary, the ensuing lessons learned are always valuable. DEKAS provides the design engineer with the opportunity to formally document any specific 'lessons learned' associated with the various design process activities performed during a particular project. The CBR facility within DEKAS then offers engineers facing similar problems the opportunity to benefit from the experiences of their peers, by first alerting them to potential design problems and returning the associated lessons learned. This enables the engineer to either directly re-apply or refine and apply a previous solution to a specific design 'problem'.

Case Study - Using DEKAS to support the Design Process

This case study illustrates the use of DEKAS to support a protection engineer throughout the protection design process from start to finish. When presented with a 'new' protection design project, the design engineer's first activity is to launch DEKAS and register the project. This creates an electronic design file providing a designated location for the electronic storage of all future documentation created during the design process. The next stage is to navigate from the high level task model down to the appropriate design activity. Contained within the model of the current activity, are links to relevant information sources required to complete the activity. The output from this stage may be to create a particular document. This document conforms to a standard structure where information contained within it relates directly to the indexing parameters of the case structure. The automatic extraction of the indexing parameter values from the project documentation is transparent to the user, and avoids the need to explicitly populate the case structure, minimising duplication of effort. Once an activity has been completed and the output document stored in the electronic design file, the engineer can then navigate to the next activity within the modelled design process. In addition, links to project specific information including documents produced as a result of the previous design activity may also be provided. This is particularly useful when multiple design engineers are involved in the design or a change of design personnel occurs during a

128

ICED 01 - C586/508

project. This provides engineers with direct access to design documentation produced by other members of the design team. Where some of the indexing parameters for the current design have already been populated (from a previous activity) the CBR function can then calculate the most similar previous case(s) to the current design. Through the derivation of this model, it has been identified that a further useful source of information would be to consider technical specifications from similar designs. The current model has identified the type of document required, in this case the technical specification. This, combined with the CBR which has identified the most similar project, provides access to a similar technical specification stored in the relevant electronic design file. As the engineer proceeds through each design activity, more indexing parameters become known and the associated weightings will adjust such that relevant documents from another previous design project may be retrieved.

Figure 3. DEKAS Architecture

Conclusion

This paper describes the application of case-based reasoning techniques in the provision of intelligent decision support for protection scheme design engineers exhibiting varying levels of technical experience. The system effectively provides the user with knowledge and understanding of the practical constraints, commonly occurring problems, idiosyncrasies and lessons learned encountered during previous designs, and the subsequent design solutions applied. The design of a protection scheme from 'first principles' is a complex task involving the consideration of multiple constraints and inputs in conjunction with a comprehensive knowledge of protection design principles. Although circumstances may exist which dictate a protection scheme should be designed in this manner, adopting this as a standard approach on a day to day basis would generally prove impractical in terms of the time and effort required. Also, in view of the repetitive nature of the design process, and to a large extent the design solutions applied, the requirement for bespoke protection scheme design is often unnecessary.

ICED 01 - C586/508

129

This is particularly evident from the current method of protection scheme design which relies predominantly on the engineer's capacity for recalling previously designed schemes which exhibit similar protection requirements to that of the current design project. While other artificial intelligence techniques may provide some form of intelligent decision support (e.g. rule-based, model-based systems), these may be more aligned with a design approach from 'first principles'. In contrast, the existing design approach concentrating on the re-use of available design knowledge appears more predisposed to the application of casebased reasoning. This paper illustrates how case-based reasoning functionality can provide more effective and relevant output (i.e. decision support) when placed in the context of the individual design process activities [7]. The evolution of the case structure and the adjustment of associated weightings, driven by the design process activity, combine to present the engineer with the 'most pertinent' information from the 'most similar' design project contained in the case library. DEKAS therefore offers design engineers access to the right information at the right time throughout the design process, and promotes the sharing of valuable engineering experience retained within a constantly expanding case base.

Acknowledgements

The authors gratefully acknowledge the contributions of ScottishPower and National Grid Company to the work described within this paper. References [1] [2] [3] [4] [5] [6] [7] Wright, A., Christopoulos, C., "Electrical Power System Protection", Chapman and Hall, 1993 Schreiber, Ahhermans, Anjewierden, de Hoog, Shadbolt, Van de Velde and Wielinga, "Knowledge Engineering and Management", The MIT Press, 1999. Firlej, M., Hellens, D., "Knowledge Elicitation - A Practical Handbook", Prentice-Hall International, 1991 Wielinga, B.J., Schreiber, A.Th., Breuker, J.A., "KADS: A Modelling Approach to Knowledge Engineering, Knowledge Acquisition", Vol 4, 1992 West, G.M., Strachan, S.M., Moyes, A., McDonald, J.R., "Knowledge Management and Decision Support for Electrical Power Utilities", Proc. KMAC2000, 2000 Watson, I., "Applying Case-Based Reasoning: Techniques for Enterprise Systems", Morgan Kaufmann, 1997, pp. 15-38 Leake, D.B., Birnbaum, L., Hammond, K., Marlow, C., Yank, H., "Integrating Information Resources: A case Study of Engineering Design Support", Proc. ICCBR99, 1999

Graeme West University of Strathclyde, Centre for Electrical Power Engineering, Royal College Building, 204 George Street, Glasgow, Gl 1XW, Tel: 0141-548-4839, Fax: 0141-548-4872, E-mail: graeme.west@strath.ac.uk. IMechE 2001

130

ICED 01 - C586/508

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

KNOWLEDGE FOR PRODUCT CONFIGURATION

K Hadj Hamou, E Caillaud, J Lamothe, and M Aldanondo Keywords: Knowledge management, Configuration, Constraints.

Introduction

Nowadays, the growing demand for customisable products involves an increasing number of product variants and complexity of products, with shorter development cycles. Consequently, consistent and rapid solutions in order to guarantee the customer satisfaction are needed [1] [2]. Many approaches for efficient problem solving and knowledge representation have been proposed, such as standardisation, DFX approaches and configuration. Configuration task and the use of configurator software are becoming more and more important for industrial companies as combining pre-designed components makes up more industrial products. The availability and identification of knowledge for product modelling and analysis are very important to satisfy the wide range of customer requirements and reduce product design cycle time and errors. Our objective in this paper is to present an analysis of this knowledge required for product configuration. A configurable product must have a generic model that contains all the knowledge about the possibilities of adapting the product to customer needs. This model defines a set of predefined components, constraints on how they can be assembled into a valid product. It also defines constraints on how to gather functions required by the customer. First, we will define the configuration task and compare it to different design approaches. According to this definition, we will describe the different kinds of knowledge involved in configuration (generic models and configuration processes). Finally, this knowledge will be depicted and illustrated by an industrial case, underlining advantage and limits of configuration during the design process.

Design and Configuration

Basically, design is the process of giving a product a description that satisfies a set of constraints and the customer requirements. The objectives of configuration are alike. In this section, our purpose is to rank configuration within the typology of design processes. Design process is made up of a series of phases. In the phase of design proposal, the designer identifies the customer needs. The outputs of this phase are the initial product requirements. Then, the needs are defined in design specification. The conceptual phase allows generating and evaluating solutions. The product concept is developed in the embodiment design by defining the complete technical description of the product. Finally, each component is defined by specifying all the drawing details and the manufacturing information. Three types of design can be distinguished [1][3]:

ICED 01 - C586/571

131

creative: the designer describes new principles and new solutions, adaptive: the designer adapts existing principles and solutions, variant: the designer starts with an existing product and makes variations on the component dimensions.

Many authors define configuration as: "given: a generic model of a configurable product able to represent a family of products with all possible variants and options, a set of customer requirements, finding at least one component set that satisfies the customer requirements with respect to the generic model". Generally speaking, configuration generates component list and/or values for attributes, whereas all the components are standard or completely defined by parameters values during configuration and no new components are generated. Thus, configuration can exist in any customer/supplier relation when defining the product object of a deal. The basic configuration problem can be modelled as a constraint problem: the variables represent component properties. Each variable has a set of admissible values. The compatibility constraints describe the relation between components properties values (allowed combination of values). Constraint Satisfaction Problems (CSP) [4] are adapted to this knowledge: a solution to a CSP is an instantiation of all variables so that all constraints can be satisfied simultaneously. In order to match extensions of the basic configuration problem [5], extensions of the CSP basis have been proposed such as, for example: activity constraints that take into account the existence of components or families of components depending on other variable value or existence. Such activity constraints appear in Dynamic CSP [6], a hierarchical view of the generic model which is useful and can be modelled with Composite CSP [7]. Aldanondo [8] proposes a classification of the configuration problem diversity adding parametric components problem and components spatial layout problem. From these definitions, it appears that configuration is an intermediate form between adaptive and variant design: activity constraints are not considered in variant design for example, but the generic model is a restriction of the adaptive design.

Knowledge and Configuration

Product configuration requires a great deal of knowledge and skills concerning both the product being designed (generic model) and its configuration process. The purpose of this section is to present the various kinds of configuration knowledge.

3.1 Generic model

Most of the time, a generic model is composed of a hierarchical structure of product functions and a hierarchical structure of physical components. The identification of these two structures

132

ICED 01 -C586/571

is the first product knowledge-gathering job. For each structure, functions and components can be standard (attribute values are predefined) or parametric (attribute values can take a value in a predefined definition domain). The occurrence quantity of each function or component in a configured product is defined with an attribute. Once the functions and components have been identified, the next step deals with the various ways of combining: the functions the customer is interested in, the components the provider is interested in, the functions and components allowing to move from the requirements to the solution and interesting the designer.

These allowed combinations are represented with constraints and can refer to parameters with either continuous domains or discrete ones. Veron [9] shows that compatibility and activity constraints, proposed by Mittal [6], could match hierarchical generic modelling for configuration problem.

3.2 Configuration process

Some other knowledge can be related to configuration process. Once the generic model is defined, the way of using it as a designer assistant must be established. Two kinds of configuration processes can be identified: batch configuration and interactive configuration. In batch configuration, all the requirements are given in a single step and the configurator tries to find a solution (thanks to a CSP Solver) without the designer interaction. In that case, the requirement as a single variable value is replaced by a set of couples (variable value, preference). This provides the configuration solver with a larger searching space but requires from the configurator user some knowledge of requirements preferences. In interactive configuration, when a requirement is introduced, the configurator propagates it (thanks to a CSP constraint propagation engine) and reduces the remaining variable definition domains. In that case, the knowledge referring to how ordering the requirement inputs must be identified. In interactive configuration, the progressive configuration process replaces the classical requirement or variable value assignment by a multi-step reduction of each variable definition domain ending with a single variable value. Of course, requirement propagation is achieved between each reduction. This way of configuring requires the configurator user to identify some knowledge that allows refining his requirements progressively. In both of these two kinds of configuration processes, requirements are frequently the source of conflicts (a constraint cannot be respected). Theses conflicts can be avoided thanks to some modifications of the configuration process.

Application

Our application deals with a pre-design activity of a wiring harness from automotive industry. The wiring harness is a complex network. It is defined by the electrical connections between components. The connectors form the network terminals. The wires represent the connections. The wiring harness links together the switches and sensors to the activators for all electrical functions. It is made of wires, connectors, relays, fuses, electronic control units (ECU).

ICED 01 - C586/571

133

4.1 Wiring harness structure analysis

In this application, two kinds of tree structure of the wiring harness are identified: the functional structure and the physical structure. Functional structure The automotive industry today manages to supply customers with individualised products at low prices by configuring each vehicle individually from a very large set of possible functions and components. For example, the Mercedes C-class has far more than a thousand electrical functions. Our functional structure distinguishes six functional domains: comfort, security, safety, cockpit, lighting and engine control. Each functional domain contains various functional items that the wiring harness provides to the final user. Each of these items is either compulsory or optional, depending on the carmaker and the final consumer desire. A function item can also be identified at various requirement levels. For example: the auto-radio can have two or four loudspeakers with different diameters, the side-view mirror adjustment can be manual or electric. It can also turn automatically to see the ground as the driver reverses gear, the central locking can be activated from the door key or by the dashboard button, the driver's window goes down a little when the door is open, . . . Figure 1 depicts an example of the functional tree structure of a wiring harness.

Figure 1. Functional structure

Physical structure Likewise, a physical tree structure also identifies geographical areas in the car, as depicted in Figure 2. As a consequence, components that support a function can be localised in different areas. A component localisation can be either forced by the carmaker or chosen within an area list under ergonomical and technical constraints. The car physical structure separates five principal physical parts: Doors, Cockpit, Underhood, Front part and Rear pan. Each physical part contains one or several physical subparts. For example, the cockpit part comprises the dashboard, the roof and the seats. A subpart can also be divided in various areas representing

134

ICED 01 - C586/571

switches, sensors and activators locations. For instance, the driver door contains the switch panel area, the loudspeakers area, the window motor area, . . .

Figure 2. Physical structure

4.2 Wiring harness generic models

The wiring harness design consists in specifying the function requirement level, identifying switches, sensors and activators positions, defining connectors and fuses and giving wire routing into the car. A hierarchical bill of material makes the process complete. In these examples, we illustrate two generic models that consider two specific electrical functions: Side-view Mirror and Window Lifter. The description of each electrical function can be modelled with a DCSP framework using variables and six types of constraints [6]: Compatibility or incompatibility constraints between variables values; Require (resp. Require not) constraints: one variable existence (resp. non existence) requires the specification of another variable value; Always require (resp. Always not require) constraints: one variable existence (resp. nonexistence) requires the existence of another variable. We get the two function specifications using their Dynamic CSP models that compose the configuration generic models. Front Window Lifter Three requirement levels can define the Front Window Lifter function: at the lowest level, the windows are lifted manually, at the medium level, the window lifter can be activated in two modes. In the basic pulse mode, the window lifting starts and ends with an impulsion on the switch. In the optional automatic mode (continuous and pulse lifting), the window lifts as long as the switch is activated. When both pulse and continuous modes are selected, there are two technical ways of obtaining the function: either one switch supports both modes or one switch is needed for each mode. Moreover, switches can be located either on the dashboard or on

ICED 01 - C586/571

135

the doors. In that second case, the driver may have the control of his front passenger window but the driver door panel switch area does not allow locating four window switches, the highest level introduces the pinch protection system conditioning the activation mode (continuous mode in this case).

The right part of the Figure 3 illustrates the Dynamic CSP model that specifies this function. Side-view Mirror There also are three requirement levels for this function: the lowest level concerns a manual non-electrical control of the function, at the medium level, one (driver's door) or two (driver's and front passenger's doors) mirrors can be controlled electrically, at the highest level, the defroster on the mirror is added and both mirrors are electrically managed. In any case, switches that activate the function can be localised either on the door panel switch area or on the central panel area of the dashboard. Moreover, when two mirrors are managed by the function, there can be one mirror adjustment switch with a mirror selection switch or two mirror adjustment switches, one for each side-view mirror. The left part of the Figure 3 illustrates the Dynamic CSP model that specifies this function.

Figure 3. DCSP models : specifications of the Window Lifter and Side-view Mirror functions

Note that the nodes of the lowest levels of the functional and physical tree-structure appear in each Dynamic CSP model as variables. The same kind of DCSP model can link variables from higher levels of the two structures. For example, the model of the Figure 4 expresses that the Side-view Mirror requirement level must be less or equal than Window Lifter one. Such constraints exist when packages of functions are desired or when a function depends on another function. For example, the central locking of the doors involves the automatic lift of

136

ICED 01 - C586/571

the door windows. In the same way, there could be constraints between the power required by the various functions and the power of the admissible electronic control unit (ECU).

4.3 Wiring harness configuration process

In each Dynamic CSP model, a lot of variables are not initially active and their activation depends on other affectation of other variables. The user cannot affect a value to a variable as long as this variable is not active. Then, the DCSP model propagates impacts of the choices on all the variables belonging to the generic model. Nevertheless, there are numerous ways of leading the configuration process. Anteriority constraints enable to specify variable instanciation orders during the configuration process. As a consequence, they enable the user to configure the product in a predefined sequence. The "Require" and "Require Not" constraints of the DCSP model already implicitly specify such anteriority. But they refer to anteriority due to physical or functional characteristics of the product. Conversely, the other anteriority constraints refer to knowledge on how to configure easily. In our examples, such constraints are due to: the desire to answer some critical functions before configuring other functions, the desire to see how to configure the wiring harness on a critical area, the know-how of the designer whose aim is to fix variables that limit the search space as much as possible. Such a strategy means affecting first variables that appear in numerous constraints. For example, in Figure 4, an anteriority constraint is added between variable "Sideview Mirror Level" and "Window Lifter Level". Then, the discard of the value "low" for the "Side-view Mirror Level" variable eliminates the value "low" for the variable "Window Lifter Level". As a consequence, the variable "ECU Power" is activated and its domain is reduced to {"Medium"; "High"}. Such a reduction is not possible if the anteriority constraint is reverse.

Figure 4. Constraints between Side-view Mirror and Window Lifter functions

This example corresponds to a progressive configuration. Here, the anteriority constraints are used to structure the configuration and progressively reduce the definition domain of the remaining variables. In batch configuration, there is no need of anteriority constraints between the variables that express the user requirements, all these requirements being given at the same time. When other variables are not instanciated after the propagation, the configurator needs to fix them a value, and anteriority constraints can be used in order to reduce the search space.

Conclusion

In this paper we have presented the required knowledge for product modelling and analysis in a configuration environment. In the case of wiring harness configuration, two kinds of

ICED 01 - C586/571

137

knowledge are depicted: product knowledge and configuration process knowledge. The functional and physical structures identify variables. Product knowledge appears in constraints between these variables and is introduced in the configuration generic model thanks to the Dynamic CSP framework. In addition, we have discussed the knowledge on how to lead the configuration process adding anteriority constraints that guide the design. Configuration, in product design, enables a better representation of knowledge for product functional specifications, components selection and its ergonomical location. It is not efficient for manageing knowledge about geometric aspects of the product. In our application, exact position of components, wires routing in the car can hardly be integrated in the configuration generic model. This underlines a need of cooperation with a traditional CAD tool. The knowledge of design conflicts has not been studied in this paper: the Dynamic CSP framework enables to get explanation of design conflicts by tracing back variables that justify constraints violation. Capitalising these explanations in order to help the designer to formalise his knowledge and make a more robust generic model is a perspective of this study. References [1] [2] [3] [4] [5] Pahl G. and Beitz W., "Engineering Design: a Systematic Approach", 2nd Edition, Springer-Verlag, London, 1996. Caillaud E. "Knowledge engineering for concurrent engineering", International CIRP Design Seminar. Kluwer, 1999, pp. 229-238. Brown D. C., "Intelligent Computer Aided-Design", Encyclopedia of Computer Science and Technology, Eds. Williams J.G. and Sochats K., 1998. Mackworth A.K., "Consistency in Networks of Relations", Artificial Intelligence, vol. 8, pp. 99-118, 1977. Lippold C., Welp E.G., "Multi-Domain Configuration System for Analysis and Synthesis of Mechatronic Conceptual Designs", The 12th International Conference on Engineering Design ICED, Germany, 1999. Mittal S., Falkenhainer B., "Dynamic Constraint Satisfaction Problems", Proceedings of the Ninth National Conference on Artificial Intelligence AAAI, pp. 25-32, 1990. Sabin D., Freuder E.C., "Configuration as Composite Constraint Satisfaction", Proceedings of the Artificial Intelligence and Manufacturing Research Planning Workshop, AAAI Press, pp. 153-161, 1996 Aldanondo M., Moynard G., Hadj Hamou K., "General Configurator Requirements and Modeling Elements", ECAI Workshop on Configuration, Berlin, August 2000. Veron M., Aldanondo M., "Yet Another Approach to CCSP for Configuration Problem", ECAI Workshop on Configuration, Berlin, August 2000.

[6] [7]

[8] [9]

Jacques Lamothe DRGI - Ecole des Mines d'Albi Carmaux Campus Jarlard Route de Teillet, 81013 AM CT Cedex 09 France Tel (33) 5 63 49 31 50 Fax (33) 5 63 49 31 83 Jacques.Lamothe@enstimac.fr IMechE 2001

138

ICED 01 -C586/571

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

AN OPERATIONAL MODEL FOR DESIGN PROCESSES

M Y Ivashkov and C W A M van Overveld Keywords: Knowledge representation, process modelling, hierarchy, ontologies, semantics, architectural design, early design phases.

Introduction

A design process can be viewed as a sequence of actions, which comprise the transformation from an initial state, comprising the design goals, to a final state detailing a new product or service and how it should be created [1]. Commonly, a design process is seen as a knowledgebased exploratory and evolutionary process. Many models of a design process recognize phases of analysis and conceptual design [2], [3]. There is a variety of sub-activities in a design process and in this paper we concentrate on the conceptual construction of an architecture of the artefact to be designed (ATBD). The architecture forms the skeleton for all subsequent design stages; design support systems therefore require a representation of this architecture [4]. The fact that design problems are under-defined and open-ended complicates architectural design [5]. Even at the end of the architecture phase many alternatives are left open. It is often necessary to consider several of these alternatives and then to compare their suitability. The problem we want to study is how the designer can be assisted in maintaining a representation of the ATBD during the early design phases, where he1 has to generate alternatives and to make conceptual architectural decisions. Nowadays, design support systems (DSS) are used in this phase. DSSs aim to help designers to maintain complex structures of requirements, context, alternatives of an ATBD architecture, etc. According to [6], DSSs have to provide support for exploration, evolution, cooperation, integration, and automation throughout the design process. In order to perform these tasks, many DSSs contain domain-specific models for design knowledge representation and administration during a design process. These models, however, may cause a bias towards certain design styles. This may sometimes interfere with the intentions of the designer, or restrict his creative freedom. In this paper we will therefore consider a model for design knowledge representation that aims to be as empty as possible, whereas it should still be useful in taking the administrative burden off of the designer's shoulders. Also, our model tries to help designers integrate context, requirements, and alternatives for the ATBD architecture at hand. Furthermore, as our model invites the designer to think in terms of well-defined relations between the various concepts he uses, we think that our model also stimulates cleaner thinking about the design problem. Using the model it is easy to express ideas, but also questions, doubts and alternatives. The model allows documentation in a uniform way by means of well-defined semantics.
1

Everywhere in this paper, 'he/his' is short for 'she or he/her or his'

ICED 01 - C586/574

139

Related Work

Several authors address the issue of (formally) representing design knowledge in multidisciplinary contexts. Our work is similar to, and partially inspired by, Fujii et.al., [15] in the sense that a state transition model of a design process is used, and properties of the ATDB are expressed in predicates; transitions are defined by their effect on these properties. The underlying modal logic in [15] is based on the work of Brazier [16] et. al. Our model features less advanced automated reasoning, since we allow attributes (functions) of concepts that are not restricted to truth-values; hence we cannot apply formal logic manipulations to the same extent as [15] and [16]. (See 3.1). Some knowledge, however, that we do represent and manipulate explicitly comprises various forms of hierarchy. Our model caters for the various types of hierarchical relations that designers use in all stages of design. (See 3.3) Several authors explain the role of hierarchies in designing: according to Simon [10], hierarchies increase evolution speed and allow the decomposition of the ATBD. Douglas describes how a design problem can be reduced to a hierarchy of decisions or alternatives [5]. Therefore the machinery behind our model uses hierarchical relations from Object Orientation (OO) [7], extended with some operators to express intentional relations, together with notions from spreadsheets [8] and symbolic manipulation [9]. (See 3.1) Numerous models of design knowledge representation are based on hierarchical approaches. Such models can be divided into descriptive and prescriptive models.

2.1 Descriptive models

Descriptive models of design process are used for describing different kinds of products, design problems, specifications, and solutions. An example is the STEP library. STEP is a set of ISO [11], [12], [13] standards, which provides the exchange of engineering product data between databases and CAD systems. STEP is built on an information modelling language that can formally describe the structure and correctness conditions of any engineering information. The library consists of several parts, each consisting of a hierarchy of instances of entities in a data model. Examples of parts are classes of physical objects, classes of aspects of physical objects, etc. Classes of objects have a textual definition but also an intentional definition via a class of properties. Each class has to be associated to another class by types of associations (is-a, used-in, part-of, connected-with etc.). STEP does not support the design process of the ATBD. Alternatives to an ATBD architecture can only be partially expressed using optional associations with other classes. There is no computational engine to propagate decisions throughout an ATBD description.

2.2 Prescriptive models

Prescriptive models concentrate on the development and application of strategies, methods, techniques, and tools that are used for designing. An example is the KBDS system. KBDS [14] is a Knowledge Based Design System, which allows a team of designers to maintain a representation of the design process not only as a historical record of the development of a design artefact, but as an "active" repository of information. Alternatives are represented in the form of the space of design alternatives (SDA). There is also the space of design objectives (SDO) related to SDA. The SDO is used for both generation and evaluation of alternatives in SDA. The model allows the designer to keep track of several design alternatives at a time; evaluating an alternative design against a set of design objectives; and transparently accessing external applications. The ideas that we propose in this paper are in no

140

ICED 01 - C586/574

way as mature as either of the above models: for instance, a computer implementation is still under development. Still, we think that it is worthwhile to explore a model that has both descriptive and prescriptive sides.

An operational model for design processes

We propose a model for design processes that should allow denoting design processes for the sake of exercising, researching and teaching cross-disciplinary design skills. Here, 'crossdisciplinary' refers to design situations where several designers with substantially different backgrounds have to co-operate. We assume that therefore no single discipline-related design methodology is available, and both technological and non-technological issues should be taken into account. Our model typically relates to early design stages, when major architectural decisions are taken without the ability to rely on the detailed knowledge that is only available in later stages. We want the same model to govern requirements, context and architectural issues. The model should cope with administrating (the consequences of) alternatives for design decisions, and it must be possible to postpone decisions or revoke earlier decisions. If our model proves to be adequate (which is still to be assessed), it should be possible to give automated support, e.g. to ensure, as far as possible, consistency among various decisions. It should, to a large extent, take the administrational burden from the designers without enforcing a strict format upon the creative design process.

3.1 Basics of the model

To this aim, our model contains the following ingredients: concepts (classes or instances) attributes, which are predicates over these concepts few pre-defined attributes, such as 'has-a', 'is-a', needs-a', that occur in virtually all kinds of design situations the notion of a spreadsheet, as this is a familiar device for incremental 'what-if' -analysis in many disciplines the notion of partial and symbolic evaluation (see below), as this allows decisions to be postponed or revoked. Notice: traditional spreadsheets don't allow cells to be nonevaluated: they cannot propagate expressions, but only the (numerical, logical or alphanumerical) values of expressions. This is clearly insufficient for postponing decisions.

With this model, a design process is a sequence of tables. A table contains 0 or more rows; every row represents one concept. A table contains 10 or more columns; every column represents an attribute. We have 10 pre-defined attributes with pre-defined meanings. Also, the propagation of these meanings to other cells is well defined. This means that, if the designer defines or changes the value of one attribute, the values for related pre-defined attributes can be updated automatically. The pre-defined attributes come in two sets of 5 (=4+1). The two sets are each other's inverses, in the sense that 'has-a' is the inverse of 'part-of'. One pair of inverses is the 'classifies-

ICED 01 - C586/574

141

as' and 'instantiates-as' pair that connects classes and instances. The other 4 pairs of predefined attributes are defined for classes only. They are depicted in the above diagram. Some examples illustrate these pre-defined attributes: is-a(table) -> furniture; specializesas(furniture) => table; has-a(table) -> legs; part-of(legs) => table; instantiates-as(myfavourite-chair) -> chair; classifies-as(my-favourite-chair) => chair; needs-a(lamp) -> electricity; causes-a(lamp) -> light; et cetera. The expression after the arrows indicates the contents of a cell in the table. The user enters expressions after single arrows (->); the expressions after double arrows (=>) follow automatically from the meaning of one of the predefined attributes. A cell is characterized by a row (concept, say C) and a column (attribute, say A). The cell represents the expression A(C). If A(C) can be evaluated; it also represents the value of this expression, similar as is done in a spreadsheet. In all previous examples, evaluation was fully possible. In some cases, for instances with conditional expressions (see 3.2), evaluation is only partially possible. Indeed, the contents of cells can be more involved as we will explain below. With our tables, consisting of rows, columns and cells, we represent the design process as a state transition machine. The initial state is a table with 10 columns and 0 rows. A state transition can be one of: adding a concept (=adding a row); adding an attribute (=adding a column), or modifying the contents of a cell. It is assumed that the modification of a cell immediately invokes updating other cells if the pre-defined semantics of the attributes allows this. For instance, if the cell has-a(table) is filled with the word 'legs', and 'legs' is the name of an already existing concept, then the cell part-of(legs) is filled with the word 'table'. More complicated examples of updates will be explained later.

3.2 Expressions in cells

Attributes will often have multiple values. In order to express this, the expressions in cells may contain operators. Operators include: BOTH, ALT (abbreviation of 'alternative'), OPT (abbreviation of 'optional'), IF, ITE (abbreviation of if-then-else), IN, AND, OR, and other obvious relational operators for Boolean and numerical types. We illustrate some of these operators with examples: has-a(chair)->BOTH(seat, backrest, legs) gives rise to part-of(seat) => chair; partof(backrest) => chair; part-of(legs) => chair. needs-a(electric-lamp)->ALT(battery,220V). Notice that in this case no automatic deduction of allows-a(battery) or allows-a(220V) can take place. Also notice that the entries 'battery', '220V, and all other constants are left unevaluated unless the designer considers it worthwhile to identify concepts with these terms for further elaboration. Our system does not contain any ontological information about the domain; it only administrates the ontology as it builds up in the designer's mind. At a future stage, however, the designer may want to elaborate on, say, the battery: then he may introduce a concept 'battery' with attributes in its own right. has-a(chair)->BOTH(seat, legs, backrest, OPT(armrests)) expresses that a chair has a seat, legs and a backrest; armrests are optional. is-a(chair)->ITE(made-by-artist(chair),piece-of-art, furniture), where the first argument of ITE is a condition. ITE is an abbreviation for If-Then-Else. If this condition evaluates to 'TRUE', the second argument is returned; otherwise the third argument is returned. So in this case the value of the cell is-a(chair) is only defined if the attribute 'made-by-artist' returns a definite value for the concept 'chair'. But even if 'made-by-artist(chair)' does not evaluate to TRUE or FALSE (for instance, the designer hasn't made up his mind yet,

142

ICED 01 - C586/574

so the cell made-by-artist(chair) is still empty), we can use the contents of the cell isa(chair) in other expressions (which may or may not be evaluated in turn). The assignment of a definite value to any attribute may take place at any time; its effect will immediately propagate to all cells that depend on it. Similar, a definite value may be withdrawn at any time, and values that depend on it will loose their validity; the associated expressions, however, will continue to hold. If times-used(room)->BOTH(night, day), then has-a(room)->IF(IN(night, timesused(room)),lamp) evaluates to 'lamp'. So the operator IN(x, y) is used to check if x occurs in (the expression) y. If y in turn is a conditional expression, depending on condition K, the condition K is also accounted as a condition in the result of 'IN'. part of the pre-defined semantics of 'is-a' is the following: suppose, for concept x, attribute A(x)->E(x) where E is some expression in x. If is-a(y)->x, then we can automatically deduce A(y)=>E(y). This is consistent with the concept of inheritance from Object Orientation.

3.3 Transitivity, hierarchies and architectures

The 10 pre-defined attributes, has-a . . . is-caused-by, are transitive relations between classes. Transitive relations, such as (multiple) inheritance, are at the heart of hierarchies as they occur commonly in all sorts of design processes. For modelling design the exploitation of transitivity in concert with our operators has some attractive consequences. For instance, suppose we want to postpone the decision between the two architectures depicted here. Then we can simply write part-of (S1)->S; part-of(S2)-> ALT(S,S1). This allows further argumentation where both options are left open for a while. In a similar way, transitivity can be used to deduce about fulfilment of requirements or side effects. For instance, from causes-a(p)->r and needs-a(p)->s and causes-a(q)->v and needs-a(q)->r we may automatically deduce that needs-a(v) => s and causes-a(s) => v. Obviously, these argumentation patterns occur frequently throughout most design processes. Indeed, design is about the fulfilment of requirements, and it is crucial to assess if at a certain stage all requirements are fulfilled. Our model provides a natural mechanism to integrate these argumentation patterns (that involve stakeholders and their attributes and other terms from the context) with argumentation about technological or architectural aspects of the design. In the next section, we present a 'hand-made' example of a small design process that makes use of our model. For more realistic examples, a software implementation is indispensable. At the end of section 4 we comment on the current status of our prototype.

Example

As an example of a system to design we chose a prototype of a dynamic board (d-board.) The main idea of a d-board is to enhance the functionality of a normal lecture room blackboard (board.) A conventional blackboard serves in teaching processes, where a teacher writes or draws on the board synchronously with his oral presentation. Therefore, a snapshot of a board with the writing on it only captures a small portion of the meaning. The dynamical process, which carries a lot of the didactics, is lost. We aim to enhance the functionality of a board in

ICED 01 - C586/574

143

such a way that speech and drawn information are recorded in the chronological order for later usage, thus enhancing the meaning.

4.1 Dynamic board prototype

The starting point in the design process was made when we decided to enhance an existing board instead of building a completely new system. The first concepts introduced in the table are related to our Lecture room and a class of Boards that will fit the Lecture room. (See steps 1-6.) We can also introduce new attributes such as Area (steps 3-4). Our doubts about a board size can be expressed as alternatives. For instance, we restrict the board area to medium (m) and large (1), because these are commonly used in lecturing (step 7). The auxiliary devices, namely the Marker and the Eraser, are used as tools. Using the IS-A attribute they are generalized into the more generic concept Tool (steps 8-9). Any later modification of the Tool will cause automatic modification of both the Marker and the Eraser. For instance, adding an attached Wire to the Tool (step 10) causes automatic propagation of the Wire to the Marker and the Eraser. Notice that all the concepts we have introduced so far are either specific instances (My Lecture room) or generic classes (Lecture room, Board.) They are used to describe a context or system parts. In step 11 we introduce the concept of Understandability, which is of a different kind. It does not have a specific instance and furthermore it describes a requirement. Despite these big differences we treat all concepts in a similar way. The Understandability will increase if both video and audio components are present (step 12). After thinking about different alternatives we came up with the Microphone (Mic) to provide audio and the two alternatives, namely Camera and Digitizer, to provide video (steps 13-18). In steps 19-20 we decide to use a Camera for medium-sized boards and to use a Digitizer for large boards. For our purposes a Digitizer needs a special Interface ( I n t - c e ) and a built-in Microphone (step 21). The Interface of the Digitizer can be either wired or wireless (step 22). However, we know that a wireless interface is more expensive then a wired one. To express this knowledge, we add a new attribute Price and assign a value to it that corresponds to the Digitizer (steps 23-24). In a similar way we, can continue until the design is finished or no open alternatives are left. For instance, if we decide to use a large board then the table automatically maintains consistency and computes that a Board has a Digitizer with a Wireless Interface; the total Price will then exceed $400.

4.2 Software: prototype and future extensions

The table at the end of this section was hand-generated. However, we are developing a system to automate the administration of such tables. The core of this system is a parser, an expression evaluator, and an engine to propagate expressions between cells based on the predefined attributes. The first two components are now operational. In order to propagate expressions, thereby taking the semantics of pre-defined attributes and conditions into account, we propose to use, in every cell, an internal normal form. Such a normal form is a list of all possible return values of a cell (constants or concepts), where for every entry in the list we administrate the condition for which this value results. This normal form facilitates merging expressions, which is necessary, among other things for multiple inheritance. Finally, the core will be interfaced to a standard spreadsheet front-end, so that familiar interaction techniques automatically apply.

144

ICED 01 - C586/574

In this table we represent the dynamics of the design process. To that aim, all entries are prefixed with a rank number; these numbers count the subsequent actions (decision) of the design. If one cell contains two entries, with different numbers, this indicates that in the course of the process, the content of this cell was changed from the first to the second entry. Numbers with prime (e.g. 6') result from automatic propagation; in this case step 6 gives rise to the automatic update in the entry labelled 6'. Label 0 is given prior to the start of the design process. Abbreviations: 7) m-medium, 1-large 14) Mic -Microphone 23) Int-ce -Interface

Conclusions and Future Work

We study the problem of assisting designers in early design phases of interdisciplinary design situations where no dedicated design theory or methodology is available. Our approach is characterised in that is it generic but at the same time aims to give support in administrating,

ICED 01 - C586/574

145

postponing and revoking design decisions. We are in the process of implementing our ideas and using them in test cases with practitioners in order to show their practical usefulness. References [1] [2] [3] [4] [5] [6] Banares-Alcantara, R. (1991). "Representing the engineering design process: two hypotheses." Computer-Aided Design 23(9): 595-603. Hubka, V. "Design for quality and design methodology." J. Engang Des., 1992, 3(1), 515. French, M, J. "Conceptual design for engineers", 1st edition, The Design Council, London, 1971. Smithers T. "AI-based design versus geometry-based design, or why design cannot be supported by geometry alone." Computer-Aided Design 21, 1989, 141-150. Douglas, J.M. "Conceptual design of Chemical Processes", McGraw-Hill chemical engineering series, 1988, 5-20 Banares-Alcantara R. "Design support systems for process engineering. I. Requirements and proposed solutions for a design process representation." Computers & Chemical Engineering 19, 1995, 267-277. Booch, Grady. "Object-Oriented Design with applications." Benjamin/Cummings, 1991 Microsoft Corporation, "a handbook for Excel", Edition 5, Ireland, 1994 Stephen Wolfram, "the Mathematica Book", third edition, Cambridge University Press, 1996

[7] [8] [9]

[10] Simon, H.A. "The Science of the Artificial", The MIT Press Cambridge, Massachusetts London, England, second edition, 1981. [11] ISO 10303-41, PART 41: "Integrated Resources: Fundamentals of Product Description and Support", ISO, 1994. [12] ISO 10303-44, PART 44: "Integrated Resources: Product Structure Configuration", ISO, 1994. [13] ISO 10303-203, PART 203: "Application Protocol: Configuration Controlled Design", ISO, 1994. [14] Banares-Alcantara R. and H. M. S. Lababidi. "Design support systems for process engineering. II. KBDS: an experimental prototype." Computers & Chemical Engineering 19, 1995, 279-301. [15] Fujii, H. and Nakai, S.: "On Formal Representations of Multi-Disciplinary Design Process." Third International IFIP WG 5.2 Workshop on Formal Design Methods for CAD, 1997 [16] Brazier, F., van Langen, P, and Treur, J.: "A Logical Theory of Design." In J.S. Gero (ed.), Advances in Formal Design Methods for CAD, Chapman & Hall, 1995, 243-266. M.Y. Ivashkov, M.Sc., C.W.A.M. van Overveld, Ph.D. Stan Ackermans Institute, 5600 MB, Eindhoven, The Netherlands, Tel: +31 40 2474772, e-mail: m.ivashkov@tue.nl / k.van.Overveld@wxs.nl, http://www.sai.tue.nl/researclt/ 2001 Eindhoven University of Technology

146

ICED 01 - C586/574

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A COMMON LANGUAGE FOR ENGINEERING DESIGN PRACTICE AND RESEARCH

A Samuel, J Weir, and W Lewis

Keywords: commonly agreed terminology, design understanding, knowledge acquisition, representation and management

Introduction

This paper is about the language of engineering design. It builds on and extends the evidence and argument presented in an earlier paper presented at the Engineering Design Conference 2000 [1], where we argued that practitioners and researchers in engineering design (including ourselves) use terminology in engineering design too loosely. Design language is treated in the same way as any other spoken language, namely to provide context based interpretative reasoning. This rather cavalier approach to the fundamental tool of design, namely "codified reasoning based on language" has tended to relegate design to a soft discipline. In stark contrast, engineering scientists have long recognised the need for communicating messages in codified language distinguished by the consistent use of concepts, e.g. shear stress, strain energy, angular momentum in mechanics. Codifying information in clear and unambiguous terminology results in a significant increase in information density and reduced communication noise. If engineering design is to become a mature discipline then the design community must develop, and in fact "own", an agreed language consisting of precise meanings for codified terms and concepts, so that there is then established a common currency of communication between designers and researchers internationally. In the paper examples are given to demonstrate that in the absence of such a language discordant communications occur which retard research effort and impair intellectual progress. The authors have therefore embarked on a programme to develop a common language - a unilateral initiative at this stage but to be extended in the future to invoke the collaboration of the international design community. For this purpose a web site has been established at <http://www.mame.mu.oz.au/eng_design/language/>. The paper describes this programme, establishes its raison d'etre, and lists the most basic of the 100 terms and concepts for which definitions have been offered for international critique on our web site. The paper then identifies some of the paradoxes and difficulties which are inherent in this research.

ICED 01 - C586/095

147

Characteristics of a Design Language

Structure. In engineering science it is commonplace for ideas and concepts to be developed in a sequential manner over a period of time. In mechanics, for example, one can construct a concept map [2] to illustrate the development of concepts such as acceleration, force, moment, angular momentum from the fundamental irreducible quantities of mass, length, and time. Such a map is dominated by a characteristic flow of ideas. Design concepts, on the other hand, lack this sequential development, as is evident when a concept map is constructed to show the interrelationships between the terms identified and listed in [1]. It cannot be too strongly emphasised that the absence of a dominant sequential flow is a fundamental difference between the language of design and the language of science Consistency and precision. The need for consistency and precision has been discussed above. These attributes are necessary not only for effective communication with other designers and researchers, but also for recording the results of research for posterity. Influence of related disciplines. The presence of overlaps and borrowings of concepts from other disciplines is a complicating factor. Engineering design is a young, emerging discipline and as such must inevitably borrow terminology from other established related disciplines. Such borrowings must be continually monitored to ensure that the focus and integrity of engineering design as a discipline in its own right are not debased or downgraded. The need for such monitoring is one of the major themes of this paper. Multilingual Background. The engineering design research community is international, and records its deliberations in a range of languages. Important fundamental concepts in engineering design have often been first enunciated in languages other than English. Given that shades of meaning are difficult to transmit with precision between different languages, the task of clearly defining and exemplifying the meaning of terms in design multilingually presents an on-going challenge to researchers. A paradox of language used in design research . Researchers seek precision in the expression of ideas and argument and in the presentation of results, whereas imprecise thinking is embedded in the practice of designing The designer lives and works in an uncertain world - the designer has to cope with inherent uncertainties about the exact nature of the client's needs and whether his/her response will deliver the outcomes predicted. The very business of creation is imprecise. De Bono has drawn attention to the way creative people use "porridge" words to keep thinking going in an intellectually murky environment when confronted by an apparent dead end [3]. Design research demands consistency of definition, consistency of logic; design practice accepts whatever is required to achieve progress towards a satisfactory solution [4].

The CADENCE Project: Desirable Attributes of a Universal Design Lexicon

Our primary objective in this exploratory article is to develop a collective ownership of terminology (nomenclature and concepts) within the design community. We seek to engender open discussion of terminology, a discussion to which the whole design community may freely, and we hope willingly, contribute examples of usage for a Commonly Agreed Design Engineering Nomenclature: Concepts and Examples (CADENCE). An equally important

148

ICED 01 - C586/095

objective is to harmonise the communication protocols adopted by design researchers in a way that will reduce noise and the invention of new and unnecessary terminology in our communications. We have argued that it is important that design researchers have access to definitions that are exchangeable across linguistic barriers, and whose meanings are demonstrated by multiple examples. We consider the requirement for exemplified definitions to be crucial to the successful compilation of a lexicon of engineering design terminology. The CADENCE project at Melbourne seeks to embody the following desirable attributes: 1. Exemplified - each definition should be accompanied by several examples, preferably drawn from diverse fields of engineering design practice; 2. Simple - in accordance with the advice of Niels Bohr that "You should never speak more dearly than you think", the definitions should remain as plain and straightforward as possible. In particular, definitions should be based on a shallow hierarchy of concepts since, in general, complex, multi-level conceptual hierarchies of definitions are unlikely to be widely accepted; 3. Extensible- additional terms are easily admitted ; 4. Web-based - access to the lexicon, both for reference and for proposal of new terms, should be through the world-wide web; 5. Commonly agreed - building of the lexicon should occur collaboratively through argument and agreement between peers; 6. Scholarly - definitions should identify the proposing authority, with examples of usage from the engineering design literature; 7. Harmonised - where divergent usage of a design term is noted, or where multiple terms are in use for the same concept, such semantic alternatives should be incorporated into the lexicon, possibly with recommendations for preferred usage 8. Fuzzy - Where appropriate, imprecise terms may be included in the lexicon, e.g. the "porridge words " referred to above; 9. Multilingual - the lexicon is being established in English, with a structure that allows multilingual definitions and cross-references to be added in collaboration with the international design community; 10. Moderated - definitions moderated by the lexicon maintainers so as to maintain structure, consistency and order.

Design reasoning as language translation

When travelling abroad, people make use of several language devices to permit communication with the natives of foreign countries. One often learns common phrases or words in the foreign country's language to allow one to communicate even simplest of requirements, such as "where is the bathroom?" or " I need some butter". English speakers have been spoiled by the fact that most people whose mother tongue is different can speak English competently.

ICED 01 - C586/095

149

Followers of mature disciplines speak an agreed language of their own. Generally, all of their "clients" come from within their own discipline. There is no need for language translation. Designers, on the other hand, invariably negotiate with clients who are not design disciples. To break the communication barrier, we often resort to a "design pidgin" to manage the negotiation. We import terminology from the client's own discipline to permit translation of the client's needs into design requirements. We essentially spoil our clients by trying to speak their language rather than our own. In doing so, however, evaluative designers must be especially aware of the dangers of loose terminology, and careful not to import it into their reasoning about the design process. A key instrument in hardening the science of design (we refer to the study of design rather than the performance of it) is precise design communication. If at all possible, we need to avoid the many experiences of "Chinese whispers" either imported from other disciplines or developed within our own. The following are case examples. QFD - Quality Function Deployment, or customer driven quality. QFD [5] is a means used to formalise the process of translating customer's needs into design requirements. The terminology used to fill in the product planning matrix is "translating from the whats to the hows". We conjecture that the commonly agreed design code for the "hows" is criteria, or performance measures. Designers have been using these codes for considerable time, yet we readily adopt the language of QFD. We suggest that this ready adoption of QFD design pidgin has a lot to do with the apparent formal coding offered by QFD. In reality there is nothing mysterious about QFD. Yet the use of invented terminology to descripe its concepts and processes serves to obscure them from non-practitioners. For dedicated users of QFD, it offers a "safe", structured, environment to perform design enformulation, the translation of needs to technically realisable requirements and criteria. Ontology (from the Greek ovr- being, the present participle of to be and Aoyicc - the study of) The Oxford English Dictionary (OED) defines ontology as the science or study of being, that department of metaphysics which relates to the being, or essence of things, or to being in the abstract. All examples offered by OED relate to its use in the sense of the study of mind versus matter. However, the word has been adopted by the artificial intelligence(AI) community in a loose sense of classification of domain specific knowledge. Some examples follow: With an ontology, keywords and database concepts can be organized by capturing the semantic relationships among the keywords or among the tables and fields in databases. The semantic relationships provide an abstract view of the information space for offices [6]. Ontology annotation ... the organization and representation of such experiences must be defined in such a way that they can easily be retrieved and used for the solving of new problems [7], Seemingly, Ontology has been 'Chinese whispered' to mean taxonomy or classification of knowledge. Clearly the term has been adapted into design from the AI community, with whom we have substantial common ground (see for example [8]). Equally clearly, the AI community and some users within the design community have some agreed meaning assigned to this term. Yet its new agreed meaning is so divergent from its original interpretation, and so unnecessary that it just adds noise to an already noisy channel of communication in design.

150

ICED 01 - C586/095

Axiom - from the Greek aiwua - self evident truth. The OED suggests "a proposition that commends itself to general acceptance; a universally accepted principle; a maxim, rule or law. " Axioms, such as the five geometric axioms of Euclid, permit the development of the substantive deductive argument, exemplified by the development Euclidean geometry. Axiomatic design [9] seeks to establish some self evident truths (axioms) that will lessen the cognitive load of the designer in delivering (mapping) from designand to designal. Two typical axioms might be: Axiom 1: Independence of functional requirements eliminates the need for compromise; Axiom 2: Minimising information content reduces the complexity of a design. These "axioms" are rather obvious observations about design complexity [10]. We conjecture that no substantive deductive argument has resulted from "axiomatic design". One can certainly adopt clear and unambiguous observations about design. Calling these observations "axioms " tends to add further confusion to the agreed language of the discipline.

5.

Constraints on commonly agreed design terminology and concepts

Invariably design proceeds from a need, through many conflicts, to some comprehensive statement of objectives and requirements of the ultimate design (the result of the design process), and the way we might measure the success of the result (design criteria). It is this critically important human-directed aspect of designing that ultimately determines the majority of the features of the design result. The whole process is moderated by the level of wisdom the designer has about the domain of knowledge within which the design proceeds. Gaining wisdom in engineering design, whether domain-specific or general, is a process that is low in procedural content and is often difficult to articulate. This is the portion of the whole design experience least subject to rational analysis. Broadly speaking, the engineering design discipline is an embodiment of current engineering culture. In that sense, it encompasses the current practices, ethics and linguistic character of all that exists and all that has gone before it in engineering. In order that the commonly agreed design terminology may develop, some basic "atomic" terminology must be established first. It is these "atoms" or "unalterables" that will drive the development of the rest of the concepts and terms that grow from them. These "atomic" building blocks of words will permit free translation between concepts and terms expressed and exemplified by design researchers in their deliberations. One of the key objectives of the CADENCE project is to provide these translations in a clear and unambiguous way. In the semantic representation of knowledge [11] a "zero order" theory is a building block used to develop higher order theories. A major obstruction to clear communication is the lack of differentiation between design the verb and design the noun. In other languages there may be some useful distinction (in German we have Konstruktions and Konstruieren), but in English there is a clear need to distinguish between action and subject. As a possible set of identifiers we offer the following definitions: Designand: the collection of goal, requirements, criteria constraints and wisdoms (heuristics) that represent the subject of the design activity. That which is to be designed.

ICED 01 - C586/095

151

Designal: the outcome of the process of designing. Design: the act of processing the Designand into the Designal. We note that design is an integrating process. Hence in line with the mathematical notion of integration we have a "subject of integration", the integrand, the integration process that acts on the integrand and the result which is the integral. The terms designand, design and designal mirror this progression. At the origin of almost all design experience are the notions of design goal, design objectives, design criteria and design constraints. We offer definitions for these terms here together with designand, designal and design as the fundamental entities from which the whole compendium of design code might be constructed. We consider the following terms the most basic, "zero order" representation of design knowledge from which other higher order knowledge representations may flow (in approximately hierarchical order): goal (design goal): the primary functional objective of the designal (usually expressed in terms of a design need). need (design need): expression of a means for solving a problem, without reference to embodiment (e.g. "a means of removing dirt from clothing", instead of "a washing machine "). objectives: desired features, or characteristics of the designal, that determines its ultimate effectiveness or suitability for a given task (e.g. the driver's seat should be comfortable; the can opener should be safe, cheap and portable). conflicting objectives (also, occasionally, competing objectives): design objectives that negatively influence each other (e.g. low mass coupled with high strength, large volume coupled with small surface area; high reliability coupled with low cost). compromise: arbitration between conflicting objectives (e.g. accepting an increase in mass for a reduction in stress level). criteria: scales on which we measure the relative level of achievement of design objectives (e.g. the criterion for a "low mass" objective is mass in kg). See also performance variable. This is probably the single most misunderstood term in design. In journal articles we have seen various meanings ascribed to this term including objective, requirement and even constraint. A criterion is a clearly identified scale or measure associated with a design requirement. It may be subjective (e.g. comfort may be evaluated on a subjective survey scale or, in the case of the bed of a quadriplegic, by the number of bedsores generated per unit time) or concrete (e.g. maintainability measured by mean time to failure or mean time to repair). constraint: mandatory requirement to be fulfilled by the design (e.g. must be manufactured in Australia; must meet Federal Drug Administration Authority requirements, must be constructed in stainless steel). restriction(in fact, a relaxable constraint): non-mandatory, flexible, designs limit (e.g. "the cost must be less than some specified value"). See also constraint.

152

ICED 01 - C586/095

design variable: variables in the control of the designer (e.g. material choice; length; colour; number of spokes of a wheel). performance variable: output variables (not directly under the control of the designer, but indirectly determined by the values of the design variables) that describe the performance of a system in fulfilling design objectives (e.g. strength, cost, pump flowrate, engine power, mass). See also criteria. discordance: a measure of the conflict between design requirements and physical reality in a problem (e.g. material property limitations "required yield strength = 1 GPa; required operating temperature = 2000C"). As a degenerate example of discordance, the perpetual motion machine is a very (intractably) difficult problem because of the irreconcilable discordance between its requirements (that the system is closed and energy is to be continuously extracted from it) and physical reality (the first and/or second laws of thermodynamics).

As an example of how we may use these "zero order" terms to develop and exemplify higher order concepts consider QFD as described above. QFD seeks to use a formal procedure to translate from a design need to design objectives, within the specified set of constraints. It also seeks to identify and resolve conflicting objectives and establish precise restrictions and criteria.

Conclusions

The adoption of an agreed, codified terminology is essential for the advancement of engineering design as a scholarly discipline. A programme to develop such a terminology has been initiated by the authors and a set of 100 definitions proposed as the basis of a Commonly Agreed Design Engineering Nomenclature: Concepts and Examples (CADENCE) project. The 15 most basic of these terms are discussed in this paper. It is further essential that proposals for inclusion in the CADENCE lexsicon, whether from the authors or from other researchers, be critiqued by the community of design practitioners and scholars. To this end the web site <http://www.mame.mu.oz.au/eng_design/language/> has been established to ensure that as wide a cross-section of the design community as possible participates, agrees to, and so owns the results. There are similarities and differences between the proposed CADENCE lexicon and the accepted languages of engineering science. Similarities arise from the common need for clarity and precision, but there is one significant difference: the sequential flow of ideas which is inherent in science and dominates scientific language is absent in engineering design. It may be conjectured that this is a major reason why engineering scientists have difficulty in accommodating their thinking to the complexities of engineering design. An equally important objective is to harmonise the communication protocols adopted by design researchers in a way that will reduce noise and the invention of new and unnecessary terminology in our communications. Progress towards this aim can be achieved by various means including the following: 1. contributions to the CADENCE project by the design community;

ICED 01 - C586/095

153

2.

3. 4.

a monitored web site fully accessible by all. The Melbourne website has a starter list of approximately 100 design terms and concepts. Additions and modifications from the design community are welcomed; written contributions by snail or e-mail to design@unimelb.edu.au. All contributions must be accompanied by examples, and all contributions will be published and discussed; contributions to design journals and proceedings should be to be monitored by the editors to ensure consistency in terminology.

References
[1.] Samuel, A.E., Lewis, W.P. and Weir, J.G. A Common Language of Design for Excellence. Proc. Engineering Design Conference 2000. Brunei University, June 2000, pp. 439-448. Geldenhuys, A.E., van Rooyen, H.O. and Stetter, F. Knowledge Representation and Relation Nets. Boston:Kluwer, 1999. De Bono, E. Practical Thinking. Penguin Books, Harmondsworth, 1976. Simon, H.A. Sciences of the Artificial. Cambridge, Mass: M.l.T. Press, 1969. Clausing, D. (1993) Total Quality Management. New York: ASME Press Huhns, N.; Stephens, M.; IEEE Internet Computing v3 n5 1999 IEEE Piscataway NJ USA p 85-87 Landes, D; Schneider, K; Houdek, F; Int. J. of Human Computer Studies v51 n3 1999 Academic Press Ltd London Engl. p 643-661 1071-5819 Gero, J. S. (ed.) (2000b) Artificial Intelligence in Design'00. Kluwer, Dordrecht, 719pp Suh, N. P. (1988) The Principles of Design. Oxford:The University Press Samuel, A.E. and Weir J.G.(1997) A Parametric Approach to Problem Enformulation in Engineering Design, Proc. of International Conference on Engineering Design. ICED 97. Tampere Finland, August, (3): 83-90 Minsky, M. (1975) A Framework for Representing Knowledge. In The Psychology of Computer Vision. Ed. P. Winston. New York: McGraw Hill

[2.] [3.] [4.] [5.] [6.] [7.] [8.] [9.] [10.]

[11.]

Professor Andrew Samuel, Department of Mechanical and Manufacturing Engineering, The University of Melbourne Grattan St. Parkville Vic. 3010 +61-3-8344-6752 +61 - 3-9347-8784 aes@mame.mu.oz.au (c) IMechE 2001

154

ICED 01 - C586/095

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

USING SITUATION THEORY TO MODEL INFORMATION FLOW IN DESIGN1

Z Wu and A H B Duffy Keywords: design information management, information representation, ontology

Introduction

Information is vitally important to our life. Devlin (1991) [1] stated: "...that there is such a thing as information cannot be disputed, can it? After all, our very lives depend upon it, upon its gathering, storage, manipulation, transmission, security, and so on. Huge amounts of money change hands in exchange for information. People talk about it all the time. Lives are lost in its pursuit. Vast commercial empires are created in order to manufacture equipment to handle it. Surely then it is there..." Information flow is intensive during a design process, where delivering timely and appropriate information is required. Sonnenwald [2] identified 13 communication roles that emerged during four multidisciplinary design situations in the USA and Europe. She stated that participants from different disciplines, organisations and cultures come to the design situation with pre-existing patterns of working activities, and specialised work languages. Different methods to represent information flow activities are used, varying in different companies, different disciplines, and different teams, which may cause misunderstandings particularly among design teams composed of different organisations. In this sense, it is important to present information flow in a rigorous way. Eastman and Shirley [3] developed a model of design information flow. The model dealt with design information management, reflecting entities, constraints, design states, design document accessed modes, transactions, and version identifiers. But, the development of their model was not based upon a theoretical foundation. In this paper, we develop an alternative model to present information flow in design based on a foundation of situation theory. The model may serve to analysis design information system and provide a basis for investigating the situatedness of design information flow. To be able to represent information flow we should firstly study its phenomena. Based on Sim's formalism of design activities [4], the theory of Speech Acts [5,6], Computer Supported Cooperative Work (CSCW) [7], and other works [3, 8, 9] studying information flow, an example model for information flow in design is developed. A discussion of the strengths and weaknesses of this representation method is carried out.

1 Currently a research project, Collective Learning in Design, is carried out in CAD Centre, University of Strathclyde. The theory and model developed in this paper will be used to modelling information flow in a collective learning process.

ICED 01 - C586/185

155

Situation theory

Situation theory has been described as a mathematical theory designed to provide a framework for the study of information [1]. It grew out of work on semantics of natural language by Barwise and Perry, and initially stated in their book Situations and Attitudes (1983) [10]. The basic ontology of situation theory consists of entities [11]: spatial locations, temporal locations, individuals, relations, situations, types, and a number of other 'higher-order' entities. The objects (known as uniformities) in this ontology include the following [11]: individuals - objects such as people, drawings, computers, etc.; denoted by a, b, c. . . relations - uniformities individuated or discriminated by the agent (human or computer system, or machine) that hold, or link together specific numbers of, certain other uniformities; denoted by P, Q, R... spatial locations - regions of space; they may overlap in time or space, or one location may wholly precede another in time; denoted as l0, l1, l2 . . . temporal locations - points in, or regions of, time; denoted by to, t1, t2 . . . situations - structured parts of the world (concrete or abstract) discriminated by the agent; denoted by so, S1, S2 . . . types - higher order uniformities discriminated (and possibly individuated) by the agent, such as (TIM the type of a temporal location), LOC (the type of a spatial location), and IND (the type of an individual). parameters - indeterminates that range over objects of the various types; denoted by s , t,

Information is always taken to be information about some situation [11], and is taken to be in the form of discrete items known as infons (infon is denoted by a) [11]. It takes the form: R, ao,..., an, 1 or 0, where R is an n-place relation, a0, ..., an are individuals appropriate for R (often including spatial and/or temporal locations), and 1 or 0 reflect that individuals a0, ..., an do (1), or, do not (0), stand in the relation to R. Infons are 'items of information', which are not things that in themselves are true or false. Rather a particular item of information may be true or false about a 'situation'. Given a situation, s, and an infon, a, we write s ||=a to indicate that infon a is 'made factual by' the situation s, or a is an item of information that is true of s. Thus, s supports a. In future work, the criteria will be defined to evaluate whether s supports a.

A example model for information flow in design

Design is concerned with processing information [8]: external information is in the form of codes of practice, design guides, product specifications, etc., that is used, along with the knowledge of the design team, to create another "internal" information set which forms the design. Within the context of collaborative design, Sonnenwald [2] explored the communication roles in the design process. She stated that different specialists build on their past experience with artefact contexts, design contexts, or situations, and technical and

156

ICED 01 - C586/185

scientific knowledge, and that specialists, from varied disciplines, explore and integrate knowledge about the current (and evolving) artefact context, design context, and technical and scientific knowledge, and create new artefact, technical and scientific knowledge, and design experience [2]. Giarratano and Riley [12] developed a hierarchy of knowledge from low level to high level: noise, data, information, knowledge and meta-knowledge, which indicates the difference between knowledge and information. They defined information as processed data, and knowledge as special form of information. In this work, the focus is upon information flow, but there are intrinsic links between information and knowledge. It is suggested that knowledge in agents change while participating in information flow. In the domain of CSCW, there is considerable work studying information flow in design. The word "co-operation" suggests two or more participants communicating with one another. They carry out studies from different perspectives to improve the performance of communication. However, there is no generic model for information flow reflecting the phenomena of knowledge increment. This paper attempts to develop a model of information flow reflecting the phenomena of knowledge increment in agents, with consideration of senders and receivers, input information, goals and the knowledge state changes (See figure 2). Sim developed a formalism for design activities based on the corpus of published research work (see Figure 1) [4]. In his formalism, design knowledge, domain knowledge and knowledge of the current state of the design serve as input knowledge (Ik) to a design activity (Da) through which a new state of the design results and output knowledge (Ok) are modified or generated. The general goal of the design activity (Dg) is to reduce the complexity of the design problem. But, Sim's work focused on only a single agent. Information flow involves two or more agents. Sim's formalism for a design activity does not generalise the phenomena of information flow in design. However, it can provide a starting base. During the process of information flow, both sender(s) and receiver(s)2 may provide information to each other, and after interaction, their knowledge states may change. In a collaborative design context, both sender(s) and receiver(s) may include one or more agents.

Figure 1: Formalism for a design activity [4]

Dix [7] argued that co-operation couldn't be seen as communication 3 alone, but as communication with a purpose. That is, goals exist in agents in information flow. It is suggested that not only there should be a goal or a need for interaction 4 , but also goals for
After receiver(s) get the information from sender(s), reply(ies) may bo required in some occasions and may not be required in other occasions. 3 In the process of communication it is assumed that information flow takes place. 4 The concept of "interaction" is used here instead of "information flow". The reason is that it is consistent with the concept used in Sim's model, and interaction is a broader concept than "information flow".
2

ICED 01 - C586/185

157

agents to participate in the interaction. Take for example during the design process agent a, a design agent, receives information from agent b, a manufacturing agent, and agent c, a disposal agent. Both agent b and c provide their need or goal to the product design. In this case, agent a, b, and c's goals are to provide an optimal design in the perspectives of product design, manufacturing, and disposal, while the goal of interaction is to providing an overall optimal product design with consideration of these three perspectives. It is suggested that there are sender(s) and receiver(s) in information flow. That is, sender(s) provide(s) information to receiver(s). Agents can be senders and receivers. From interaction between agents, output knowledge (known as the change of knowledge states in agents) may be produced. In this example, the senders are agent b and c and the receiver is agent a. They have their own goals. The goal of interaction is fulfilled by compromise of its participants' goals if their goals conflict. Given this, a simple model of information flow can be developed as shown Figure 2. The model includes input information of sender(s) (Iis), input information of receiver(s) (Iir), interaction between agents (INTa), output knowledge of agents (Ok), the goal of interaction (Gint), the goal(s) of sender(s) (Gs), and the goal(s) of receiver(s). Output knowledge serves as input knowledge for current or future design of sender(s) and receiver(s). Given such a model one may ask what agents may be involved in interaction? Sonnenwald [2] identified 13 communication roles in multidisciplinary design situations: sponsor, interorganisational star, inter-group star, intra-organisational star, intra-group star, inter-task star, intra-task star, interdisciplinary star, intra-disciplinary star, interpersonal star, mentor, etc. Morse and Hendrickson [8] considered five communication modes within the context of traditional engineering design. Through their work [2,8], it can be concluded that participants in communication may be agents from different or the same organisation(s), design group(s), design task(s), and discipline(s).

Figure 2 An example of model in information flow in design

What are the input information in sender(s) and receiver(s)? In this paper, we study the input information based on the theory of Speech Acts [5, 6], which studies the philosophy of language. In studying the problem of how many ways of using language, Searle found that there are generally five ways, that is, five general categories of illocutionary acts [5]: Assertives. Speaker states something being the case. Directives. Attempts by the speaker to get the hearer to do something. Commissives. Commits the speaker to some future course of action.

158

ICED 01 - C586/185

Expressives. Expresses the psychological state specified in the sincerity condition about a state of affairs or a statement. Declarations. Brings about the correspondence between the proposition content and reality. For example, if a designer successfully performs the act of finishing the design of a component, then the component has been designed.

Based on these basic categories of illocutionary acts, we can categorise the input information of both sender(s) and receiver(s) (Iis, Iir), the goals of sender(s) and receiver(s) (Gs, G r ,), the goal of interaction (Gint), and the change of knowledge that may be derived from them (see Table 1).

Representation of information flow with Situation Theory

In this section we use situation theory to represent information flow based upon the model presented in section 3. As there are five illocutionary acts in conversation, every agent's communication with other agents may fall into such illocutionary acts. Suppose there are a group of agents (more than two) involved in a communication then the representation of information flow with situation theory may be summarised by a formalism as shown in Table 2, from which other representations may be derived. For example, the expression "Agent a1 believes that agent a2 can do the task b1," based on derived Assertives, may be represented as:

If we consider the time and location in making this expression, that is, "Agent a1 believes that agent a2 can do the task at time t and in location l", it can be represented as:

And we suppose that situation s support this expression, it can be further represented as:

Other representations may be derived similar to this example. Thus, using situation theory, we can represent other complicated information flow in the design process, such as:

where agent c knows that agent a believes agent b does not know information i at time t and in location l. Thus far, we have presented a representation of information flow in the design process based on a well-founded method, situation theory. Such an approach may help minimise misunderstanding in the research community when studying information flow in the context of collaborative design studies and could act as a base to codification for protocol analysis.

ICED 01 - C586/185

159

Table 1. Knowledge increment in agents through information flow 5

Input information Sender(s) Receiver(s)

Iis Iir

Goal of sender(s) Gs Input assertives

Goal of interaction
G int

Goal of receiver(s) Gr Evaluate or/and input assertives Informing sender(s) its capability Knowing sender(s) intention and providing evaluation to its (their) intention(s) Providing its(their) expressives or evaluating sender(s) expressives Sending feedbacks to the declarations

Knowledge change

Assertives

Assertives

Directives

Their (its) capability Evaluate sender(s) intention Expressives

Assigning the right tasks to the right agents. Informing intention(s)

Compromising different assertives Optimising assignment of tasks Sharing and evaluating intention(s)

New assertives

New knowledge of task assignment Sharing intention(s)

Commissive s

Expressives

Providing expressives

Compromising different expressives

Sharing expressives

Declarations

Evaluation to the declarations

Sending declarations

Sharing declarations

Knowledge of the changing design environment

Example: to illustrate the use of this table, we still use the example in this section: a manufacturing agent b (sender) sends it's requirements (input information of sender) to a design agent a (receiver) with its manufacturing goal (goal of sender). After receiving its information, if the goal of agent a (goal of receiver) has a conflict with that of agent b, agent a have to send its own requirements (input information of receiver) to agent b, and they negotiate with each other for a new goal (goal of interaction). In this process, agent a and agent b know the requirements of each other and learn how to produce a parameter optimised to both perspectives (knowledge change).

Table 2. Illocutionary Acts Assertives Directives Commissives Expressives Declarations

Representation of information flow with situation theory Meaning Agents a1, a2, . . ., an assert statement s1, s2, . . ., sn. Agents a1, a2, . . ., an direct agents b1, b2, . . ., bn to do the tasks t1, t2, . . ., tn. Agents a1, a2, . . ., an commit tasks t1, t2, . . .,

Representation assert, a1,a2, . . ., an, si, S2, . . ., sn, 1 direct, a1, a2, . . ., an,b1, b2,. . ., bn, t1, t2, . . ., commit, a1, a2,

tn, 1

an, t1 , t2, . . ., tn, 1

tn.
express, a1, a2, . . ., an, dl , d2, . . ., d3, 1 declare, a1,a2, . . ., an, c1, C2,
. . ., cn, 1

Agents a1, a2. . . ., an express attitudes d1,

d2, . . ., d3.
Agents a1, a2, . . ., an declare changes of the environment c1, c2, cn.

Strengths and weaknesses

Situation theory is a formal tool to study information flow in linguistics. The advantage of using this theory is it provides a well founded way to model information flow in design. It can serve as a tool to minimise misunderstandings of design information flow. It may also provide a way to represent and analysis an information flow system. Such a representation system may provide a clear understanding of the input and output knowledge of the agents and where the knowledge comes from and goes to. What's more, it serves as a basis for investigating the situatedness of information flow. Different situations will result in different information flow. Consequently, the study and modelling of information flow is only valid if put in relation to its situation. With consideration of time t, location l and situation s, the information flow changes as time, location and situation change. One situation may support certain type of information flow. But another situation may not support the same type of information flow. It is intended that the relationships of situations will be studied and the links between the change of situations and the change of information flow developed. Although the method of situation theory may bring some benefits, a weakness of this method is also identified: the theory is not widely known. Situation theory is originally developed in the domain of linguistics. Most researchers and design engineers may not know this method. In future work, the evaluation of the model and methodology will be carried out design practice. But, it is suggested that the model and theory developed in this paper may act as a conceptual framework for modelling information flow and developing CSCW systems.

Conclusion

This paper presents a first attempt to modelling design information flow with situation theory. Information flow in a design project can be rather complex. Effective and efficient management of information flow can play a vital role to ensure a successful product development. In this paper, a method, situation theory, is used to represent information flow in design, and provides a more formal and well-founded method for representation of information flow, with the purpose of minimising misunderstandings, a means of analysis information flow. In this paper, based on Sim's formalism of design activities, the theory of Speech Acts, CSCW, and other works studying information flow, an example model for information flow was developed.

ICED 01 - C586/185

161

The representation of information flow with situation theory is based upon the example model for information flow and illocutionary acts. A formalism of representation is provided and an example is used to explain it. Other representations can be derived from this formalism. The strengths and weaknesses of using this representation method were discussed.

Acknowledgement

We are indebted to Professor John Gero, Key Centre of Design Computing, University of Sydney for bringing to our attention his work on situatedness in design which stimulated our interest in this area. References [1] [2] [3] Devlin, K., Logic and information. 1991, Cambridge University Press. Sonnenwald, D., Communication roles that support collaboration during the design process. Design Studies, 1996, 17: p 277-301. Eastman, C., and Shirley, G., Management of Design Information Flows, in Management of Engineering and Management Perspectives, S. Dasu and C. Eastman editors. 1994, Kluwer Acacemic Publishers. p255-277 Sim, S. K., Modelling Learning in Design, in CAD Centre, DMEM. Ph.D Thesis. 2000, University of Strathclyde, 75 Montrose Street, Glasgow, Gl 1XJ, U.K. Searle, J., Expression and meaning: studies in the theory of speech acts. 1979, Cambridge University Press. Searle, J., Speech acts: an essay in the philosophy of language. 1969, Cambridge University Press. Dix, A., Computer support cooperative work: a framework, in Design Issues in CSCW, C.H. Duska Rosenberg editors. 1993, Springer-Verlag. p. 9-26. Morse, D., and Hendrickson, C., A communication model to aid knowledge-based design systems. AI EDAM, 1990. 4(2): p. 99-115. Macleod, A., and McGregor, D., Accessing of information for engineering design. Design Studies, 1994. 15(3), p 260-269.

[4] [5] [6] [7] [8] [9]

[10] Barwise, J., and Perry, J., Situations and Attitudes. 1983, The MIT Press. [11] Devlin, K., and Rosenberg, D., Situation theory and cooperative action, in Situation theory and its application, Vol 3, David Israel, Peter Aczel, Yasuhiro Katagiri, Stanley Peters editors. 1993, Stanford University, p 213-264. [12] Giarratano, J., and Riley, G., Expert Systems: Principles and Programming. 1998, PWS Publishing Company. Zhichao Wu CAD Centre, DMEM, University of Strathclyde, 75 Montrose Street, Glasgow Gl 1XJ, UK Phone: +44-141-548 2374 Fax: +44-141-552 7896 Email: chao@cad.strath.ac.uk Zhichao Wu 2001

162

ICED 01 - C586/185

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

SHAPE MATCHING AND CLUSTERING

S Lim, A H B Duffy, and B S Lee Keywords: Information classification, machine learning, taxonomies

Introduction

Generalising knowledge and matching patterns is a basic human trait in re-using past experiences. We often cluster (group) knowledge of similar attributes as a process of learning and or aid to manage the complexity and re-use of experiential knowledge [1, 2]. In conceptual design, an ill-defined shape may be recognised as more than one type. Resulting in shapes possibly being classified differently when different criteria are applied. This paper outlines the work being carried out to develop a new technique for shape clustering. It highlights the current methods for analysing shapes found in computer aided sketching systems, before a method is proposed that addresses shape clustering and pattern matching. Clustering for vague geometric models and multiple viewpoint support are explored.

Analysing Vague Shape

To pattern match and cluster vague shapes we must firstly identify the types of vagueness that may occur during geometric sketching. Then the criteria for identifying a cluster must be defined. Various methods address the problem of shape analysis as summarised in Tables 1 and 2. However, these methods consider precise shapes and are not appropriate for vague geometry. The following types of vagueness in conceptual geometric shapes cones in a variety of ways, as identified below [3]. Vague position of a line segment - In figure 1, because the line positions are not clearly expressed, we encounter two types of vagueness. Firstly, the open/closed status of the shape type is vague. It also includes the uncertainty of whether the ends of two lines meet to form a vertex. Secondly, the size of each element (i.e. a line segment) is vague. For example, the size of the right vertical line of the sketch in figure 1 will be determined by whether the sketch represents a rectangle or polygon.

Figure 1. Vague position, size, and close/open

Vague convex/concave vertex - Without any guidelines or contrast between light and shade, recognising a vertex as a 3D convex or concave shape from 2D sketches can be difficult. This type of vagueness occurs frequently in 2-D sketches of 3-D objects because of an optical illusion as illustrated in Figure 2.

ICED 01 - C586/273

163

Figure 2. Vague convex/concave vertex

Vague shape type - The type of shape of an object is often vague giving rise to more than one feasible interpretation of the shape. For example a line element may be interpreted as a straight line or as an arc and can result in different shape types as shown in Figure 3.

Figure 3. Vague shape type

Vague relative spatial relation - If an ill-defined geometric object has a vague surface, the distance between this and another object is vague. Figure 4(a) shows the possible relative spatial relation whether the surfaces of the objects are vague or not. In this 2D example, the boundary of the object 'a' and 'b' are vague. Considering the minimum and maximum boundaries, the intersection status between two objects can be recognised as vague intersection, intersection and non-intersection. In addition, a sketch representing 3D spatial relationships can lead to some confusion. In the 3D example shown in Figure 4(b), although the object 'a' and 'b' have precise surfaces, their relative spatial relation can be recognised as three different types, as the example sketch implicates vague co-ordinates.

Figure 4. Vague relative spatial relation

164

ICED 01 - C586/273

Table 1. Shape analysis methods (summarised from |4, 5]) Shape boundary points Boundary (external) algorithm Global (internal) algorithm Shape boundary Fourier transforms of the boundary Medial axis transform (MAT) Moment based approaches Shape decomposition into other primitive shapes Various fourier Moment-based approaches Allows an accurate reconstruction of a shape.

numeric or non-numeric Scalar transform technique Information preservation

Table 2. Summary of the existing visual perception methods (summarised on the basis of [5]) Theory Classification Gestalt theory Gibson's theory Note A non-computational theory of visual form. Concentrated around perceiving real three-dimensional objects as real objects, representations of real objects, and abstract (non-real) objects. Mostly qualitative and not computational. Appropriate for natural shape representation. Curve partitioning. Three-dimensional object recognition from unknown viewpoints and single two-dimensional images. Extended as Shape from shading, contour, texture, stereo, and fractal geometry. A procedure for morphogenesis based on multiple levels of resolution has been developed. Applied as - Combination of high curvature points and line segment approximations. - Measurement methods of the curvature of 3D surfaces. For a hierarchical deformation of the object. - The inference of the shape history from a single shape. - The inference of shape evolution between two shapes. When two arbitrarily shaped convex objects interpenetrate each other, the meeting point is a boundary point of concave discontinuity of their tangent planes.

Traditional Modern

Neuropsychological theory Fractal geometry High curvature points Lowe's system Marr's paradigm (shape from x) Morphogenesis Polygonal approximation of shape Symmetry-Curvature theorem The principle of transversality

Clustering and Customised Viewpoints

Computational clustering is performed using machine learning techniques. According to Reich [1], machine learning can be considered as explanation-based learning (EBL) or similarity-based learning (SBL). Because the ill-structured nature of design often precludes formalised theories of synthesis it has been suggested that SBL is more suitable for conceptual design [1]. There are two primary classes of machine learning techniques in the SBL approach: supervised concept learning and unsupervised concept learning. Supervised requires the user to support the learning process whereas learning is automatic in unsupervised. As Gordon [6] argued, markedly different results can be obtained when the same data set is analysed using a different clustering strategy. It is thus important to give thought to the

ICED 01 - C586/273

165

problem of selecting criteria for clustering that are appropriate for analysing the data being investigated. Manfaat [2] presented an approach, Customised Viewpoint-Spatial (CV-S), to support the effective utilisation of spatial layout design experience by generalising past spatial layout design cases and abstracting a single case into hierarchical levels of abstractions according to the designer's needs. He argued that the layouts of a space can be hierarchically clustered into groups based on the measures of similarities between the layouts. An example of different views is shown in Figure 5.

Figure 5. An illustration of abstraction of a spatial layout in four different viewpoints (adopted from [2])

Thus, pattern matching plays a key role in machine learning. It can be defined simply as the activity of matching patterns with the aim of finding similarities between them for the purpose of recognition and/or retrieval of similar patterns [7]. Patterns are matched for their similarity, grouped (clustered) together, and induction techniques used to generalise knowledge form the group members to reflect knowledge common to all in the group.

Multiple Clustering of Shapes

4.1 Clustering Vague Shape

A vague geometric shape can be identified by a hierarchy of shape probabilities ([3]). A childelement can be a straight line, curve, or a closed geometric shape such as a circle, rectangle, or triangle. One possible way of representing the shape vagueness of a child-element is through using probability. Consider an object in a sketch that has n elements (see [8]). The various possible alternative interpretations for each child-element can be represented in a hierarchical structure, with the lowest level populated by the 'primitives' of the element type.

166

ICED 01 - C586/273

The probability of the element being a particular geometric primitive can be obtained by mutiplying the probability of the element belonging to the appropriate group at each level leading down to the primitive in question. For example, in Figure 6, the (n)th element of object A has a 0.2016 probability to be a Closed-Polygon-Triangle derived from its probability of being a closed shape (0.64), a polygon (0.7) and a triangle (0.43), i.e. 0.64 * 0.7 * 0.45 = 0.2016.

Figure 6. Hierarchical structure of vague information [3]

The hierarchical levels and the class list in each level can be changed or extended. For example, if a designer needs to analyse a sketch stroke as abstracted symbols, rather than a geometric shape element, they could change or add some levels and specific classes. Also, the level of the hierarchical structure could be extended to represent a compound object that is made from more than one object. A distinct advantage of working in this way is that the complex task of analysing the shape type is reduced to a relatively simple and manageable one through determining the probability at each level, regardless of how complicated the object, and, ultimately the whole sketch, is. This classification hierarchy may provide clustering criteria of a vague geometric model as shown in Table 3. However, this requires further investigation.

ICED 01 - C586/273

167

Table 3. Classification Criteria for Clustering Criteria Sub Main Definition := has child elements Description of Criteria Classify an object by a presence of child elements. If an object does not have any child element, the object is most likely a primitive shape. Classify an object by a number of child elements if the object has any children. Classify an object by a presence of sub-objects. Classify an object by a number of sub-objects if the object has any sub-objects. Classify by a hierarchical depth of sub-object. Classify two-dimensional objects. Classify an object by a number of vertices. Classify three-dimensional objects. Classify an object by a number of surfaces if the object has three-dimension. A number of surfaces are analysed by the status of edges. Classify an object by the probabilities of each primitive. Classify an object by the probabilities primitives such as "closed" and "open". Classify an object by the probabilities primitives. Classify an object by the probabilities primitives. Classify an object by the relative spatial between sub-objects. of 1st level of 2nd level of 3rd level relationships

ca

Ca-1

cb

Cb-1
Cb-2

Cc
Cc-l

cd
Cd-1
Ce

= has a number of child elements = has sub-objects = has a number of sub-objects = has a hierarchical depth of sub-objects = is two-dimension = has a number of vertices = is three-dimension = has a number of surfaces := probability of a primitive. := 1st level primitives := 2nd level primitives := 3rd level primitives := has a relative spatial relationship

Ce-1

Ce-2

Ce-3

cf

4.2 Multiple viewpoint clustering

Some investigations have been conducted addressing multiple viewpoints. Howard-Jones [9] carried out an experiment in which subjects looked at a geometrical shape and generated as many interpretations of the shape as possible based on a different viewpoint. Duffy and Kerr [10] pointed out the need to support 'Customised Viewpoints (CV)'. Suwa et al. [11] insisted that 'discovering hidden features in a representation without being fixated to a single perspective of viewing' is one of the crucial acts in creative activities. Vague shapes may also be clustered differently depending on different viewpoints. Consider that objects A and B have various properties {Al Ca, Cb, Cc, C d } a n d {Bl Ca, Ce, Cf} respectively. If a designer considers that the property Ca is most important to cluster an object, then object A and B could be classified in the same cluster. In all other cases, they would be classified in a different cluster.

4.3 Shape matching

SPIDA matches topological patterns of layouts and the combined topological patterns and geometric shapes of layouts [2]. To illustrate the system's functionality Figures 6 and 7 each show 4 past design layout (cases), the former for topological matching and the latter for combined topological and geometric shape matching. On the right of each figure are

168

ICED 01 - C586/273

"required" layouts to be matched against the past design cases. Before proceeding the reader is invited to determine which cases best match the required layouts. You should attempt to decide the order of similarity of the layouts by determining for topological matching the cases that most reflect the required layout, where space B is adjacent to space C which is adjacent to space D, etc. For the geometric shape matching you should consider the overall shapes of the spaces and how they are related. The results of the topological matching between each of the past design cases and the required layout are shown in Table 4. In this table, for each case, the layouts are ordered from the most to the least similar. This order is based on an analysis of corresponding spaces. If there are more than one layout case that has the same number of corresponding spaces, they have the same ranking.

Figure 7. Topological Pattern Matching

Figure 7. Geometric Shape Matching

Table 5 shows the results of the combined topological and shape matching. In this table the cases are first ordered on the corresponding spaces and then on a shape dissimilarity measure. In this table, the layout cases are first ordered based on the corresponding spaces. They are then ordered based on a shape dissimilarity measure. The lower the measure the more similar the layout case is to the required.
Table 4. Results of Topological Pattern Matching Ordered cases Case 1 Case 4 Case 3 Case 2 Number of corresponding spaces 7 Table 5. Results of Geometric Shape Matching Ordered cases Number of corresponding spaces 4 Shape dissimilarity measure 0.00 0.47 0.23 0.29

6 4

2 3 4

Given the ability to match the layouts they then can be clustered according to their similarity measures [2].

Conclusion

Shape matching is a of key element in clustering geometric shapes. In this paper, we discussed about the clustering, customised viewpoints, and pattern matching regarding of shapes. Although there are various ways of representing vagueness, a hierarchical shape

ICED 01 - C586/273

169

clustering with multiple aspects could be one way of doing this, particularly when it is desired to define the shape type of the geometric object. Work is on-going to develop the techniques presented in this paper and for a system to support the re-use of past design shape cases. References [1] [2] Reich, Y. and S.J. Fenves, "The Formation and use of Abstract Concepts in Design", Concept Formation: Knowledge and Experience in Unsupervised Learning. p323-353 Manfaat, D., A.H.B. Duffy, and B.S. Lee, "SPIDA: Abstracting and generalising layout design cases", Artificial Intelligence for Engineering Design. Analysis and Manufacturing (AI EDAM). 12: 1998, 141-159 Lim, S., B.S. Lee, and A. Duffy, "Incremental modelling of ambiguous geometric ideas (I-MAGI)", Special Issue on Conceptual Modeling in Design Computing of the International Journal of Artificial Intelligence in Engineering, 2001. (to be published) Pavlidis, T., "A Review of Algorithms for Shape Analysis", Computer Graphics and Image Processing. 7: 1978, p243-358 Loncaric, S., "A survey of shape analysis techniques", Pattern Recognition. 31 (8): 1998, p983-1001 Gordon, A.D., "Hierarchical Classification, in Clustering and Classification". 1996, p65-121 Manfaat, D., A.H.B. Duffy, and B.S. Lee, "Review of pattern matching approaches", The knowledge Engineering Review. 11:2: 1996, p161-189 Lim, S., A. Duffy, and B. Lee, "Intelligent computational sketching support for conceptual design", International Conference on Engineering Design (ICED'0l). Glasgow, UK. 2001 (submitted) Howard-Jones, P.A., "The variation of ideational productivity over short timescales and the influence of an instructional strategy to defocus attention", Proceedings of Twentieth Annual Meeting of the Cognitive Science Society. 1998

[3]

[4] [5] [6] [7] [8]

[9]

[10] Duffy, A.H.B. and S.M. Kerr, "Customised Perspectives of past designs from automated group rationalisations", International Journal of Artificial Intelligence in Engineering, Special Issue on Machine Learning in Design. 8(3): 1993, p183-200 [11] Suwa, M., J. Gero, and T. Purcell, "Unexpected discoveries: How designers discover hidden features in sketches", Visual and Spatial Reasoning in Design. 1999.
S W Lim CAD Centre, Dept. of DMEM, University of Strathclyde, James Weir building, Glasgow, Scotland, UK, Gl 1XJ, UK. Tel: 44-(0) 141-548-2374, Fax: 44-(0) 141-552-0557, Email:sungwoo@cad.strath.ac.uk, URL:http://www.cad.strath.ac.uk/~sungwoo/Home.html

Sungwoo Lim 2001

170

ICED 01 -C586/273

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

THE PRODUCT DEVELOMENT PROCESS ONTOLOGY - CREATING A LEARNING RESEARCH COMMUNITY

P K Hansen, A Mabogunje, O Eris, and L Leifer

Keywords: Research Cumulation, Classification, Indexing Research

Introduction

In a prior paper, we argued that the inherent complexity of product development research, and the variation in research methodologies and settings result in the lack of qualitative cumulation of research findings, and advocated the need of applying an ontological approach to overcome the problem [1]. Specifically, we developed an initial ontological framework to facilitate the sharing and comparison of methods, variables, and results. Furthermore, we illustrated our approach by feeding the findings of published studies into the proposed framework as concrete examples. Our data set consisted of the findings from 19 papers published as the Delft Protocol Workshop [2]. In this paper, we test and develop our initial ontology further by applying it to a much larger data set: all of the papers published in the proceedings of the International Conference on Engineering Design, 1999. Naturally, the broader and more comprehensive scope of the new data set challenges our assumptions and framework. In this study, our goal is to devise a repeatable validation method that improves the initial ontology. Our ultimate goal is to apply the resulting validation method repeatedly in order to make the ontology comprehensive and consistent.

The Ontological Approach

An ontology can be defined as the specification of a conceptualization [3]. That is, an ontology is a description (like the formal specification of a program) of the objects, concepts, entities, and relationships that can exist in some area of interest. A conceptualization is an abstract, simplified representation of the area of interest. In our context, an ontology becomes a specification medium accessed by researchers for making ontological commitments. Its affordance is the consistent communication in a domain of discourse without necessarily operating on a globally shared theory. The term "ontology" is mostly applied in the development of large, enterprise-wide information systems to support consistent product development across a geographically distributed organization. This is achieved through the use of a pre-defined ontology that enables enterprise-wide consistency and commonality through the interoperability of processes, systems, and databases [4]. Other purposes are development of systems for

ICED 01 - C586/361

171

supporting different disciplines of engineering design work by providing ontologies of for example functional concepts [5]. Ontologies are often equated with taxonomic hierarchies of classes, however, ontologies need not to be limited to these forms. Within the field of product development, several attempts have been done to apply a taxonomic approach. Our initial attempts at composing a framework were built on a similar taxonomically understanding. However, after preliminary analysis of data, we decided that an ontological approach would give us more freedom in achieving our goal due to the looser and pragmatic structure it entails.

The Initial Ontology

The examples mentioned above are all characterized by a high degree of formalization due to their focus on computer integration. We intend to apply the idea of ontology in a less formalized way because we are interested in a conceptual representation of product development processes that enhances our qualitative understanding. In order to develop the attributes and sub attributes of the "Product Development Process" category of our initial ontology, we manually reviewed the Delft Protocol Workshop findings [2]. The analysis of the nineteen papers that made up the findings of recognized research groups from several countries enabled us to formulate an initial structure of objects, main attributes, and sub attributes cf. table 1.
Table 1. Initial Ontology for "Product Development Process". Objects
Actors Skills Knowledge Roles Motivation Values Emotions Class Paradigm Cognitive Information processing Problem-solving Decision-making Function-evolution Problem-solution interaction Mediation

Main Attributes

Sub Attributes/Thesauri
structural, discursive, expert experience, common sense, explicit, implicit, episodic chair person, monitor, summarizer, note taker, timekeeper, expert, chief designer, project manager, designer commitment, goals views, preferences tension Action gathering, recognizing, accessing, visualizing, perceiving, reviewing, managing adopting, referring, proposing, structuring, generating examining, analyzing, synthesizing, reasoning, inferring, deducing decomposing, reinforcing evaluating, checking, testing, monitoring controlling, conflict handling, negotiating, persuading, arguing listening, speaking, documenting gesturing, moving, touching, riding, wearing verbal, graphic, textual, physical ambiguous abstract, concrete internal, external decision, alternative, criteria, arguments, problem, solution, concept, methods, constraints, intention geometry, material feature, function, structure, behavior, state appearance, feel

Activities

Social

Information

Information sharing Physical Object-engagement Representation Level of detail Level of abstraction Source Interpretation (context) Property Performance Position Organization Physical layout

Artifact Environment

172

ICED 01 - C586/361

The conceptualization of the phenomenon "Product Development Process" has strong analogies to the problem of modeling processes in general. This is particularly the case when the aim is to simulate processes. In particular, we have got inspirations from the development of a computer-based project simulation tool, Virtual Design Team [6]. The conceptual model of a "Product Development Process" includes the five objects: Activity, Environment, Actor, Information, and Artifact. Although many researchers imply such a conceptual framework, the objects are rarely referred to explicitly. Rather than referring to an "Actor" most researchers refer to some of the "Attributes" of an actor, e.g., the skills, the roles, the knowledge, or more likely, to some "Sub Attribute" describing for example the specific skills of an actor. In essence, the lack of an explicit framework is what makes comparison between different research findings so difficult. Our initial analysis of the Product Development Process topic consisted of a number of iterations where empirical sub attributes were identified and structured. The objects and the structuring of the main attributes were products of theoretical considerations; they were our own interpretations. The sub-attributes appeared explicitly in the published material and constituted the data. Although the structuring effort was rather labor-intensive, we believe that the richness of the manual procedure we employed proved to be more effective in making accurate distinctions than the employment of an automated approach. However, the identification of sub attributes and the categorization of main attributes are not enough to construct an ontology; that would yield a taxonomy. An ontology differs from a taxonomy by highlighting the non-linear relationships and dependencies between the identified categories. Therefore, the structure presented on Table 1 does not quite constitute an ontology. Our conceptualization of the Product Development Process contains many undetermined links (Figure 1).

Figure 1

The undetermined links in the conceptualization of the Product Development Process

Therefore, the goals of this study are twofold: 1) Test the empirical validity for the sub attributes by applying the structure represented on Table 1 to a larger data set, and refines the sub attributes as necessary. 2) Identify relationships between objects.

ICED 01 - C586/361

173

Analyzing the ICED99 papers

Given the amount of work such a test would require we decided to limit the analysis to include only the "Actor" object. That is the aspect of product development processes related to humans and the attributes associated with humans. The proceedings of the Conference on Engineering Design 1999 included 381 papers covering the broad field of product development processes. Apart from providing an ideal updated empirical basis for this study, the proceedings confirmed the need we advocated for an ontology: The 381 papers all have a title and three to four keywords, and are divided into predefined themes. However, it is difficult to pinpoint the papers with overlapping research interest. We analyzed the papers by using a number of different text analysis tools. We concluded that many of the available text analysis tools were too detailed to provide the digest type of information that we need. The most efficient type of tool turned out to be the indexing tools utilized by major Internet search engines. Our analysis procedure was as follows: 1. Update sub-attributes. 2. Using an automated search tool, search for updated sub-attributes in all 381 papers. 3. For papers with no hits, verify that the actor object is not addressed. 4. For papers with 1 -2 hits, ignore due to lack of significance. 5. For papers with 3 or more hits, verify actor object is addressed. 6. Determine and present object hit accuracy. 7. Enrich our understanding of sub-attributes and refine them. 8. Determine relationships between objects. The automated search revealed that many of the originally identified sub attributes were illdefined. A term like "Knowledge" was associated more with information and data than with knowledge of an actor. The ability to make such distinctions requires an additional syntactic dimension analyses. We have been applying such methods in prior studies [8], and based on these experiences we recommend this dimension to be added later when refining the ontology. The iterative searches enabled us to refine the initial sub attributes as described in table 2. The new sub attributes are derived from the initial sub attributes. However, they are considered to be more generic and less ambiguous.
Table 2. First version of refined Ontology for the Actor object in "Product Development Processes". The asterisks signals that any derived words would be included Objects Actors Main Attributes Skills Knowledge Roles Motivation Values Emotions Sub Attributes/Thesauri talent*, abilit*, skill*, experti* experience*, aware*, understand* responsibi*, role* enthusiasm*, incentive*, commitment*, motivat* belief* emotion*

The application of the ontology shows that the most frequent attributes addressed in the papers are "Skills", "Knowledge", and "Roles" and not surprisingly, that the attributes "Values" and "Emotions" are the least covered, see table 3. Table 4 illustrates the number of main attributes addressed in each paper. The automated search revealed that a significant part of the papers (26%) did not cover the Actor object at all. Upon reviewing these papers manually for content, we found that they typically dealt with

174

ICED 01 - C586/361

specific devices, generic processes, modeling, evaluation tools, representation and information exchange tools, etc, and that they indeed did not cover the Actor object.
Table 3. Number of papers covering the Actor main attributes. Skills Knowledge Roles Motivation Values Emotions Main Attributes: Number of papers

158

194

130

61

13

13

Of particular interest were the papers covering three or more main attributes. These papers accounted for 21% of the total number of papers. A manual review showed that the papers had a significant focus on the Actor object - only 4 papers out of 89 can be questioned according to their classification. This roughly translates to a 93% automated search accuracy in the Actor object.
Table 4. Number of main attributes covered per paper. Number of Main Attributes Covered: Number of papers

6
0 (0%)

5
4 (1%)

4
15 (4%)

3
60 (16%)

2
105 (28 %)

1
99 (26 %)

0
98 (26 %)

The review also revealed that our original suggestion of classifying the Organization attribute as a part of the Environment object was questionable (see table 1). Following our original empirical material [2] this seemed obvious, but the review of the larger and much more diversified empirical material [7] revealed that there was a link between the organization object and the Actor object. In particular, the applications of teams in product development processes are closely related to the Actor object. We shall elaborate this relation further in our next review. Secondly, the review showed that it was appropriate to aggregate some of the attributes. The application of the attributes Motivation, Values, and Emotions in the papers had conceptual relationships. We therefore suggest that the three should be aggregated into one attribute. The attributes Skills, Knowledge and Roles seemed to coexist to a large extent. More than 57% of the papers with three or more attributes covered includes all the three and 91% cover at least two of the three. We therefore suggest that the three should be aggregated into one attribute.

Implications and discussion

Based on the results, we refine the Actor object in "Product Development Processes" by including more accurate and representative sub attributes for each (Table 5).
Table 5. Refined Ontology for the Actor object in "Product Development Processes". The asterisks signals that any derived words would be included Objects Actors Main Attributes Skills, Knowledge, Roles Motivation, Values, Emotions Sub Attributes/Thesauri talent*, abilit*, skill*, experti*, routine*, experience*, aware*, understand*, tacit*, unfamiliar*, familiar*, eligib*, responsibi*, role*, novice* enthusiasm*, incentive*, commitment*, motivat*. belief*, emotion*, curious*, relax*, resistance*

Ideally the Actor object should not be viewed in isolation. The conceptualization of the product development process should be included as a whole (as represented in Figure 1). However, our experiences so far tell us that we have to move slowly when conducting such empirical reviews and that we need to iterate to ensure reliable results.

ICED 01 - C586/361

175

To test the current state of the ontology we have made a search for the 20 papers with the highest quantitative match within each main attribute (see table 6).
Table 6. The 20 papers with the highest quantitative match within each main attribute. The numbers refer to the volume number of the proceedings and the page number in the volume. The papers in bold are the ones that appears in more than one main attribute.

Paper ranked by best quantitative match

Skills, Knowledge, Roles Motivation, Values, Emotions 1-0195, 3-1581, 2-1263, 3-1565, 3-1611, 2-0899, 3-1651, 2-0793, 1-0095, 1-0153, 3-1547, 3-1413, 3-1657, 3-1837, 2-0905, 2-0893, 1-0329, 1-0119, 1-0365, 1-0189 2-0793, 1-0473, 1-0165, 1-0195, 1-0551, 3-1413, 2-0643, 2-0727, 3-1565, 2-0661, 1-0265, 3-1525, 2-0805, 1-0033, 2-1259, 1-0047, 2-0923, 1-0325, 2-0893, 2-1263

From the result sharing and generating research motivation standpoint, there are a couple of different ways of interpreting table 6. First, it is possible to identify researchers that share professional interest within a particular area. For example, figure 2 shows a cluster of researchers in the skills-knowledge-roles main attribute.

Figure 2. A cluster of researchers working in the area identified by the main attributes - skills-knowledge-work based on the papers ranked by the best quantitative match.

Second, it is also possible to drill further down and find the overlap between a specific paper and the average of papers or a selected group of papers. For instance the results in table 6 indicate that the two papers 1-0195 [9] and 2-0793 [10] provide a comprehensive view of the two first main attribute of the Actor object. A closer review reveals a significant overlap in research interest although the two papers are to be found in different volumes of the proceedings which corresponds to different research areas and share no keywords (see table 7). Furthermore, it was interesting to see that the two papers share no references.
Table 7. Brief review of three papers with a high quantitative match within different main attributes.

Eckert et.al. [10]

Keywords: Expertise, Creativity, Design Psychology, Aesthetic Design Differences between expert and novices; Different types of knowledge; Experts, novices, innovators Personal challenges; Burnout and staleness

Ritzen et.al. [11]

Keywords: Change Process, Key Factors, Implementation Activities Adopting new methods; Acquiring knowledge about new methods; Role of management Willingness to chance; Commitment to environmental tasks; Resistance

Skills, Knowledge, Roles

Motivation, Values, Emotions

176

ICED 01 - C586/361

Conclusion and further work

This paper reported the findings of the second stage of a continuing effort for developing a product development processes ontology. So far, our findings indicate that product development research results can be catagorized by the application of a taxonomy and that this could potentially lead to a higher degree of cumulation of research findings. However, there are many possibilities for improving our approach. First of all, we need to enhance the ontology by accounting for the relationships between objects, and the dependencies between the content of the objects. Secondly, we need to consider more effective and illustrative ways of representing the results. We strongly invite our peers to contribute to the framework as we see cross-validation and community participation as a crucial step in taking our work beyond its initial phase. References Eris, O., Hansen, P., Mabogunje, A. & Leifer, L., "Toward a Pragmatic Ontology for Product Development Projects in Small Teams", Proceedings of the 12th International Conference on Engineering Design", Technische Universitat Munchen, Munchen, 1999 [2] Cross, N., H. Christiaans & K. Dorst, "Analyzing Design Activity", John Wiley & Sons, Chichester, 1996 [3] Gruber, T.R., "A translation approach to portable ontologies", Knowledge Acquisition, 5(2), 1993, 199-220 [4] Uschhold, M et al "The Enterprise Ontology," The Knowledge Engineering Review, Vol. 13, Special Issue on Putting Ontologies to Use, 1998. [5] Kitamura, A.M. & Mizoguchi, R., ,,Meta-functions in Artifacts", Papers of 13th International Workshop on Qualitative Reasoning (QR-99), 136-145, 1999 [6] Levitt, R.E., Cohen, P.G., Kunz, J.C., Nass, D., Christiansen, T., & Jin, Y., "The Virtual Design Team: Simulating How Organizational Structure and Communication Tools Affect Team Performance" in Carley & Prietula (Eds.), "Computational Organization Theory", Lawrence Erlbaum Associates, 1994 [7] Lindeman, Birkhofer, Merkamm & Vanja, "Communication and Cooperation of Practice and Science, Proceedings of the 12th International Conference on Engineering Design", Technische Universitat Munchen, Munchen, 1999 [8] Mabogunje, Ade, "Measuring Conceptual Design Process Performance in Mechanical Engineering: A Question based Approach", Dissertation, Stanford University, 1997 [9] Eckert, Stacey & Wiley, "Expertise and Designer Burnout", Proceedings of the 12th International Conference on Engineering Design", Technische Universitat Munchen, Munchen, 1999 [10] Ritzen, Beskow & Norell, "Continuous Improvement of the Product Development Process", Proceedings of the 12th International Conference on Engineering Design", Technische Universitat Munchen, Munchen, 1999 First authors name: Poul Kyvsgaard Hansen Institution/University: Aalborg University Department: Department for Production Address: Fibigerstraede 16, 9220 Aalborg OE Country: Denmark Phone: (+45) 9635 8935 Fax: (+45) 9815 3030 E-mail: kyvs@iprod.auc.dk IMechE 2001 [1]

ICED 01 - C586/361

177

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

THE APPLICATION OF AN AUTOMATIC DOCUMENT CLASSIFICATION SYSTEM TO AID THE ORGANIZERS OF ICED 2001
A Lowe, C A McMahon, T Shah, and S J Culley Keywords: Design information management, information analysis, classification and retrieval, taxonomies

Introduction

It has been estimated that engineering designers can spend as much as 30% of their time searching for and accessing design information, particularly 'informal information' [1]. According to Sutton [2], only ~15% of an organisation's documentation is stored in structured databases that can be easily searched and retrieved. Companies working in 'knowledge intensive' industries therefore require improved tools and applications to allow them to organise and manage access to the intellectual capital contained within all of their information assets. An influential study within a large automotive company [3] found that engineers often fail to find useful information that exists in an organisation because: they may not be aware of all the relevant information available within an organisation the cost (or time) to obtain the information in a useful form may be prohibitive

Computer-based storage and developments in communication and networking technologies have led to an 'explosion' in the quantity of relevant information that is available to engineers both within and external to organisations. Keyword based search tools can be used to perform specific queries, however often the results tend to be indiscriminate (with users provided with an overwhelming number of 'hits' or no 'hits' at all). Browsing search strategies provide a complement to keyword searches, however they require the pre-classification of documents into meaningful categories. Kanapan and Taylor note that company Intranets (and Extranets) have been seen as a means of engineering organisations gathering and sharing information within and between organisations [4]. However, "...the organisation of the shared information is usually ad-hoc and is not designed to efficiently serve the diverse information needs of workgroups". The manual classification of documents is obviously one option, however the authors have observed from previous informal studies with practising engineers that attempts to raise the level of manual organisation for documents are often unpopular and ineffective. The use of computer systems to assist in the organisation of informal information is therefore considered to be an important challenge in building improved information support systems for engineers.

1.1 Scope of the paper

This paper can be read in two ways; in one sense it describes the application of an existing automatic classification approach to the organisation of engineering information into technical topics on the basis of the textual content of documents [5], however it also provides some interesting insights into the vocabulary used by the design research community. Initially a survey of the use of keywords by authors of engineering design conference papers is presented. These have been used to help identify the nine conference themes and a

ICED 01 - C586/433

179

corresponding set of recommended keywords to represent the main technical topics associated with these themes for the ICED'0l conference. Following on from this is a description of the operation and review of the performance of a computer system that is used to automatically classify documents into categories, according to their textual contents. Next, the application of the system to the classification of abstracts submitted to the ICED'0l conference is presented. Finally, a number of conclusions and recommendations for further work are given. This work is similar in some respects to that reported in [6], [7] and [8]. However, the work reported in these papers describe design document learning systems [6]/[7] and Latent Semantic Indexing approaches [8] to document indexing and retrieval.

Survey of the use of keywords in ICED'99 and TMCE 2000

The rationale behind the analysis of the use of keywords by authors of engineering design papers is to aid the grouping of the papers into useful combinations, particularly by having an integrated and prescribed list of keywords and themes. As sources of data, the authors of this paper extracted the keywords from 390 documents published in the 12th International Conference on Engineering Design (ICED'99), and a further 73 documents from the 3rd Tools and Methods in Concurrent Engineering Symposium (TMCE 2000). These were considered to be representative of a broad and a more limited technical domain respectively. Unique keywords and phrases were initially identified from those used by paper authors and then the frequency of these terms was determined. Note that those differing only in terms of capitalisation, plurals, punctuation or UK/US spelling variations were merged. The results from the analysis of the frequency of keywords used by paper authors are shown in Figure 1.

Figure 1. Analysis of keyword usage frequency by authors of ICED'99 and TMCE 2000 conference papers

The results clearly indicate the lack of a standardised terminology used by researchers and practitioners within the engineering design domain. Some argue that such a lack of a consistent terminology is a constraint on the ability of design from maturing into a scientific discipline [9]. Whether or not this is the case, the lack of consistent use of keywords certainly reduces their effectiveness as an aid in information retrieval. In the particular context of this paper, the keyword analysis was used to generate a recommended keyword list for the associated conference themes (totalling 247 recommended keywords). The themes are presented below in italics, and the number of keywords for each is indicated in brackets:

180

ICED 01 - C586/433

(i) Design Theory and Research Methodology (24), (ii) Creativity and Innovation (10), (iii) Product and Systems Modelling (25), (iv) Design Methods, Techniques and Tools (35), (v) Knowledge and Information Management (19), (vi) Organisation and Management of Design (33), (vii) Design Education (21), (viii) Engineering Design in Industry (36), (ix) Current Issues (44).

3 Outline of the automatic classification system 3.1 Classification system outline

The system adopts a standard constraint-based classification approach, in which pre-coded sets of constraints are used to relate the textual content of documents with particular technical topics or themes [5]. The sets of constraints for each theme contain terms and term phrases, possibly including additional features such as constraint and term weighting factors, or means to allow the combination of multiple sets of constraints. For the classification of ICED papers, the nine conference themes represent the categories into which papers are classified and the prescribed keywords provide the evidence of whether papers should be associated with a particular category (note that both UK and US spelling variations of the constraints were included). For the ICED papers, terms in the document collection index were stemmed (i.e. reduced to their grammatical roots) and case-folded (i.e. all converted to the same case such that queries are case insensitive). Note also that commonly occurring stopwords (e.g. the, and, it, etc.) were not removed from the index, since some of the constraints include such words. A diagrammatic outline of the experimental system is presented in Figure 2.

Figure 2. Outline of the constraint-based classification system

3.2 Measuring performance

Precision and recall are extensively used to evaluate the performance of classification systems. Perfect system performance would be indicated by a precision of 1.0 for all values of recall. In practice there is a performance trade-off and system precision inevitable falls as recall increases. As previously noted, the system processes a series of classification heuristics against a set of documents to determine appropriate conference themes. There are two subsets that are used to calculate the precision and recall. The computer system generates an answer set of suggested conference themes (the SUG set). There is also a set of assigned themes that represent the 'correct' answers that an expert has decided as being actually relevant (the ASS set). There is a further set that comprises the suggested results within the assigned results (i.e. the intersection of ASS n SUG). Precision and recall are calculated as follows:

Interpolated precision values have been calculated and are used in the results presented in this paper (i.e. so that precision-recall 'curves' are non-increasing). The results are ranked according to measures of the degree to which documents can be associated with the conference themes. The most straightforward means of calculating this 'strength' of

ICED 01 - C586/433

181

association is by measuring the frequency of occurrence of constraints associated with the themes. Note that this approach does not take into account that some terms are more indicative of a particular theme than others. More complex ranking measures can include term weightings and means of accounting for the relative scarcity of terms both within particular documents (which will be a factor of the length of documents) and in a collection of documents as a whole. However, the authors found that the ICED collections analysed in this paper are relatively insensitive to the choice of ranking algorithm (due to the similar length of papers and also the relatively small size of the collection). Therefore the results presented in this paper are based on ranking using a simple measure of the frequency of occurrence of theme constraints.

Testing the system

The full papers from the proceedings of ICED'99 (totalling 390) were used for the purpose of initially testing the classification system. To a large degree, the performance of the classification system is dependent on the 'quality' of the theme constraints (i.e. how accurately the constraints reflect the particular document themes). This issue is discussed in section 5 in relation to the classification of ICED'0l papers into the relevant conference themes previously identified (and using the recommended keywords as constraints). An additional factor that is independent of the definition of the constraints, and discussed in this section of the paper, is a consideration of the location of the occurrence of constraints within particular zones or sections of a document.

4.1 Experimental methodology

A zone-based model of an ICED paper can be considered to comprise the following [10]: title, keywords, 'snippet' (the first 400 characters in a document), headings (the section headings used within documents), introduction & conclusions (a combination of the introduction and conclusion sections) and body text (i.e. the full-text excluding the title, keywords, introduction, conclusion and references). It is postulated that the occurrence of constraints within different document zones will provide different degrees of evidence of whether a document is related to a theme. To test this proposition, 'zoned' papers from the ICED'99 conference were classified into the nine ICED'0l conference themes. Note that prior to indexing the papers, a series of document pre-processing steps were carried out on electronic versions of the papers. Documents were all converted into HTML with paper title and keyword fields identified as <meta> tags and, where appropriate, the document headings converted into <hl>, <h2>...<h n > tags. The determination of the assigned set for the 390 ICED'99 documents was carried out manually by the authors of this paper by making judgements as to the relevance of documents against the conference themes. Papers were assessed as either relevant or not-relevant to each of the various themes and hence were associated with any number of multiple themes. The results for each of the nine themes were then combined into a single average figure for each document zone. Whilst the classification performance for each of the themes can vary considerably, the average plots provide a means of isolating the effect of zoning.

4.2 Document zoning results

Figure 3 illustrates the results comparing the performance of the classification system for various different document zones. The 'whole paper' line represents the baseline plot against which the others should be compared. It is apparent that the document keywords, title and 'snippet' provide the greatest likelihood of containing textual evidence to support the classification into themes that match the human assignments. This confirms the expected finding that 'important' terms are featured in a paper's title and mentioned early in the

182

ICED 01 - C586/433

document. The body text and the introduction & conclusions provide similar results in comparison with the baseline. Whilst it is expected that the body text would be a less rich source of theme constraints than the baseline (which is indeed the case), it is perhaps surprising that the introduction & conclusion zone results do not exhibit better performance. Another surprising finding is the heading plot which suggests that paper authors do not use particularly descriptive headings within documents. If the results for the ICED'99 papers can be generalised to represent technical reports (i.e. expository text), this suggests that automatically generated tables of contents might not necessarily provide a good source of subject descriptors with which to browse documents.

Figure 3. ICED'99 precision recall results to investigate zoning effects

Analysis of the ICED'0l abstracts

Experiments on the accepted ICED'0l abstracts were used to measure the effectiveness of the constraint matching approach for the classification of abstracts against each of the individual conference themes (using the prescribed keyword list as the theme constraints). The results for the ICED'0l abstracts provide some insights into the way in which authors have selected the themes for papers, in addition to the 'quality' of the prescribed keyword list suggested by the conference organisers. Results were gathered for the entire abstracts and also for the abstract body text (which comprises the whole abstract excluding the title keywords).

5.1 Experimental methodology

The assigned sets for the ICED'0l collection were chosen by the actual authors of the abstracts. When submitting abstracts, the authors were asked to choose a single conference theme that they judged the be the most appropriate match for their paper. From the 375 abstracts invited to submit full papers, 334 of the abstracts included at least one suggested conference theme (292 papers were associated with a single theme and 42 with a choice of either two or three themes that authors considered to be relevant). Abstracts which did not include an assigned theme were not included in the following analysis. For the documents assigned to multiple themes, it was assumed that they were partially associated with each of the multiple themes (i.e. a document assigned to two themes was considered to be 'half associated' with both themes and so on). The accepted abstracts did vary in length, however

ICED 01 - C586/433

183

as previously noted in section 3.2, it was found that the results were insensitive to the choice of ranking algorithm (and hence the simple term frequency similarity measure was used). In addition, document pre-processing was carried out in a similar manner to that previously outlined in section 4.1.

5.2 ICED'0l classification results

Figure 4 and Figure 5 illustrate the varying performance of the system in classifying the abstracts into each of the different conference themes. When submitting abstracts for the conference, authors were asked to select descriptors from the prescribed keyword list, and hence it should be expected that the whole abstract would be very likely to contain terms related to the theme selected by the author (as is the case). Note however, by ignoring the title and keywords in the analysis this influence is eliminated (Figure 5), and consequently the classification performance is adversely affected.

Figure 4. ICED'00 precision and recall results - entire abstract

Figure 4 and Figure 5 can be used to indicate the quality of the keywords and phrases that are used to associate the abstract with the particular themes. It is apparent that the Current Issues and the Engineering design in industry themes perform particularly poorly, providing some evidence that the keywords used in the prescribed list do not match well to the content of abstracts. In section 2 it was noted that the Current Issues and the Engineering design in industry themes were associated with 36 and 44 keyword-constraints respectively, which is a larger number than for the other themes. All things remaining equal, the expected effect would be to increase the classification recall at the expense of precision. This does not appear to be the case in comparison with the other themes, indeed, the Current issues theme has the largest number of constraints but also the poorest recall. This certainly suggests that these two themes are not adequately represented by the recommended keywords. Another important factor is undoubtedly the less 'concrete' nature of these two themes. Authors were asked to select only a single conference theme to be associated with their abstracts. It was observed that, where possible, authors had a tendency to choose the more technical topics from the conference themes. It is considered that the Engineering design in industry theme (and Current issues) is likely to be widely applicable to a large number of abstracts, often as a secondary theme.

184

ICED 01 - C586/433

Figure 5. ICED'00 precision and recall results - body abstract (i.e. not including title or keywords)

The Design techniques and tools theme perhaps provides the best contrast to the Current issues and Engineering design in industry. This theme also has a large number of associated recommended keywords (35), although it provides the best classification results. It is considered that this can be attributed to higher 'quality' nature of the constraints (that are easier to define due to the more 'clear-cut' nature of theme). When considering the conference themes that are automatically suggested by the system, it was found that when using the entire abstract, ~60% of abstracts are 'correctly' assigned when taking into account only the single theme that has accumulated the most evidence (i.e. the system suggests the same themes as those selected by the authors). This rises to ~72% if either of the top two themes are included, ~85% for the top three, rising to a maximum ~90%. The fact that the maximum value does not reach nearer 100% indicates that in 10% of cases, authors have assigned a theme to their abstracts but not used any of the recommended keywords associated with the selected theme. The results for the classification of the abstract body text collection (i.e. excluding the title and keywords) determined that ~42% of abstracts are correctly assigned using the single highest automatically assessed theme. This rises to ~60% for the top two themes, ~72% for the highest three, rising to a maximum of ~80%. This is an encouraging finding in that the relatively crude automatic classifier can be used to 'correctly' identify ~80% of the themes identified by authors when the classification of an abstract into multiple categories is permitted (as is the case in an electronic classification system where an electronic document can be virtually classified into multiple locations).

Conclusions

The initial stark conclusion shown is the lack of an agreed terminology by researchers and practitioners in the engineering design domain. One of the implications of this lack of consensus is a reduction in the effectiveness of 'un-prescribed' or freely chosen keywords as an aid in information retrieval. The results demonstrate the effectiveness of a conceptually simple textual constraint-based document classifier in organising ICED'0l abstracts, using a prescribed keyword list developed from the initial keyword use survey and a set of associated/integrated conference themes. An analysis of the effect of document zoning indicates that the occurrence of theme constraints within particular sections of technical

ICED 01 - C586/433

185

documents provides differing levels of evidence as to whether a document should be associated with a theme. Most notably the title, snippet and keywords provide the most significant evidence, with the textual content of document headings being a surprisingly poor indicator of a document's content. The classification approach has been shown to be particularly effective in well-defined technical subject areas, although inevitably less successful in conference themes that are less distinctive (e.g. the Current issues and Engineering design in industry themes). Note that the techniques described are currently being used with a very much expanded hierarchically decomposed set of design related research topics. This is to facilitate the assignment of papers into specific technical areas and to assist in the identification of subtopics and paper groupings for the preparation of the programme for ICED'0l.

Acknowledgements

Part of this work was carried out under the IDEA project which is funded by the UK EPSRC (grant number GR/L90170). The authors would like to thank this project's industrial sponsors (Airbus UK, CSC and TRW Aeronautical Systems) for their assistance. References Court, A. W., Culley, S. J. and McMahon, C. A. "Information Access Diagrams: A Technique for Analysing the Usage of Design Information", Journal of Engineering Design. 7, 1996, p. 55-75. [2] Sutton, M. J. D. "Document Management for the Enterprise: Principles Techniques and Applications". John Wiley and Sons Inc, 1996, New York. [3] Salzberg, S. and Watkins, M. "Managing Information for Concurrent Engineering: Challenges and Barriers", Research in Engineering Design, vol. 2, no. 1, 1990, p.35-52. [4] Kannapan, S. and Taylor, D. "Multi-Perspective Information Projection: Structuring Hypermedia Information in Engineering Development Projects", Proceedings of ASME DETC, Sacramento, California, 1997, DETC97/EIM-3721. [5] Paijmans, H. "Comparing the Document Representation of Two IR Systems: CLARIT and TOPIC", Journal of the American Society for Information Science, vol. 44, no.7, 1993, p. 383-392. [6] Dong, A. and Agogino, A. "Text Analysis for Constructing Design Representations", AI in Engineering, vol. 11(2), 1997, p. 65-75. [7] Reich, Y., Konda, S. L., Levy, S. N., Monarch, I. A. and Subrahmanian, E. "New Roles for Machine Learning in Design", AI in Engineering, vol. 8(3), 1993, p.165-181. [8] Wood, W., Yang, M. and Cutkosky, M. "Design Information Retrieval: Improving Access to the Informal Side of Design" Proceedings of ASME DETC. Atlanta, Georgia, 1998, DETC98/DTM-5665. [9] Samuel, A., Lewis, W and Weir, J. G., "A Common Language for Design", Proc. EDC 2000. Brunei, UK, 27-29 June 2000, p. 439-448. [10] MacLeod, I. A., "Storage and Retrieval of Structured Documents", Information Processing and Management. 26. 2, 1990, p. 197-208. Chris McMahon University of Bristol, Department of Mechanical Engineering, Queen's Building, University Walk, Bristol BS8 1TR, UK, Tel: +44 (0)117 9288100, Fax: +44 (0)117 9294423, E-mail: chris.mcmahon@bristol.ac.uk, http://www.dig.bris.ac.uk/staff/chris/chrisnew.html IMechE 2001 [1]

186

ICED 01 - C586/433

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

ANALYSIS AND CLASSIFICATION METHODOLOGY FOR OBJECTIFICATIONS IN COLLECTIVE DESIGN PROCESSES

A Verbeck and K Lauche

Keywords: Information design; empirical study

analysis, classification

and retrieval: taxonomies;

co-operative

Introduction

Objectifications or artefacts such as sketches, documents, CAD models or tools play an important role in the design process. They help the designer to externalise ideas and also function as a means of communication within teams and as objects for knowledge management in organisations. As collective design processes highly depend on the successful exchange of ideas and information during meetings and in distributed teamwork, it is vital that objectifications are employed in a way that actually supports the design process. As a result of our interdisciplinary design research, this paper introduces a taxonomy to diagnose the use of objectifiactions. It covers the individual function, the benefit for the team and the contribution to knowledge management of any given document. If a range of relevant documents is diagnosed with this tool, the results can be used to give feedback about the forms of communication and documentation within the R&D process. In this paper, we explain the importance of objectifications and our theoretical approach, describe the tool and give an example on how it was applied.

Importance of objectifications for the R&D process

We understand the process of designing as a constant dialogue between the mental processe thinking and the outward expressions. Perceptions of the outward world are internalised and become part of the mental representation. They are then externalised into drawings, sketches or physical models [1]. Experiments showed that participants instructed to sketch their ideas spent more time on sketching but arrived at better results at an overall shorter time than the controls [2]. The reason for this is seen in the limited human mental capacity: The sketch works as an external buffer and thereby frees higher order mental capacities. Also the sketching itself helps to find a form by "thinking with the hand". This manual part of designing is particularly effective in early phases for rough sketches. From his studies of freehand sketches in a conceptual design experiment, Pache [3] suggested to so see sketches as a script of the designer's dialogue with his product representation. By combining geometrical elements, symbols or written terms, the sketch tells a technical story to someone familiar with the context. Roughly drawn shapes can function as abstract elements, representing a variety of concrete, exact shapes that are already put into a spatial-relational context. Form this dialogue and the visual perception during sketching, creative, unintended mechanisms can result in the occurrence of new design ideas on a high level of abstraction.

1CED 01 - C586/456

187

By this process of interiorisation and exteriorisation, designers create new objectifications and at the same time relate to existing objects around them. Every design starts within a world of already existing artefacts and produces new elements for our material culture. Activity theory has emphasized the role of objectifications in the individual development of mental capacity and in the historic development of a culture [4]. Figure 1 shows the theoretic framework of objectifications in the design process.

Table 1. Artefacts or objectifications mediating between the subject (designer) and the object (task) [4]

Objectifications or artefacts mediate the design process between the subject, the designer or the team, and their object, the task, and they mutually influence each other. Beyond this individual function, there are also elements of how a community, which might be a company or a professional body, communicate. The use of artefacts is influenced by the rules and conventions such as a methodology. Their role for the exchange of ideas and knowledge also depends on the division of labour among the team members and the departments. Weber [4] showed that objectifications that have been developed together increase the cohesion among team members. It implies that the more time a team spends generating and modifying an artefact, the better for the social process. This will be vital for co-operation but may not be desirable form an economic point of view. A knowledge management approach would recommend that documents should be accessible and understandable for a wide range of people but would not suggest that everybody should be involved. This dispute is not resolved in this paper. However, the tool gives an account of all the different aspects for a comprehensive diagnosis. From the results, actions can be derived that take the specific context of the company in account. Examples for objectifications are: knowledge memories (e.g. databases, protocols of team meetings), visualisations in the problem solving process (e.g. physical models, photographs, sketches), documented general practices (e.g. principal solutions for design problems, user hints, heuristic rules), reference books (e.g. catalogues), tools and facilities (e.g. software tools).

188

ICED 01 -C586/456

Description of the tool

In design science, objectifications have mainly been researched at the individual level. So far, there has been little methodological guidance available for extending this research to social and organisational aspects. Protocol analysis normally does not deal with artefacts for more than one situation, and social sciences offer apart from interviews and questionnaires only content analysis of elicited statements. However, much information can be obtained from existing documents. Therefor, for developing this tool, we draw on our theoretical understanding of objectifications and on ethnographic approaches. We combined document analysis for descriptive features and content with questioning involved people about the background of a given artefact. This usually serves as a door opener to the history of a project. Objectifactions become key elements for understanding design. The tool combines aspects of three areas: the individual function, the team building aspect and the benefit for knowledge management. It can be used to study collective design processes as a supplement or substitute for extended observations. The tool can also be applied to diagnosis of use and storage of collective knowledge and its materialisation for practical purposes. It provides the basis of an assessment of how documents and models fit the needs of the design process or conform to a certain knowledge management approach. The entire set of all objectifications or a defined subset is analysed and evaluated.

3.1 Overview
The tool consists of five parts: formal features, localisation in the process, individual function, team function and organisational aspects of knowledge management and cost-benefit ratio. Aspect 1. Formal features Criteria content and people involved type (slide, sketch, physical model, software) features (colour, 2/3D, manual / CAD) formal notes like date, initials , index For the lifecycle of the project: initiation, pre-selection, conception and planning, realisation, introduction, commercialisation for the cognitive problem solving process: situation analysis, goal setting, forming of concepts, choice of concepts, evaluation, decision 3. Individual function analysis storage evaluation solution finding communication documentation internal exercise legal requirement Hacker, Sachse, Schroda [2] Pache. Romer, Lindemann, Hacker [3] Systems Engineering Source

2. Localisation in process

1CED 01 - C586/456

189

4. Team function

generation usage effort needed further development maintenance by cither one / two / several or / all members with cither the same or different disciplinary background from either the same or different departments Knowledge management function: transparency, acquisition, sharing, development, use, storage of knowledge Retrieval individual, collective store, effort and restrictions of access Usefulness Information contained, problem specific, solution oriented, iterations needed, cost-benefit ratio, readability to others, generalisations to other problems
Table 1. Sections and criteria for the classification tool

Weber [5] Lauche, Ehbets Muller, Grote [6] Verbeck, Lauche. Weber [10]

5. Organisation

Konda et al. [7] Probst, Raub, Romhard [9]

The results for the sections 1-3 are descriptive, for the sections 4 and 5 ratings are given to evaluate the appropriateness.

3.2 Individual function

The tool contains an introduction into the concept and function of objectifications and an instruction to the classification guidelines. The application combines the description of features and interview questions. First, an artefact is characterised by its content (what is shown in it), its type (drawing, model, software, text) and physical appearance (2D/3D, colour, handmade /CAD). The second step, which may require questions to people involved with it, is the localisation within the product development process and in the problem solving cycle. The individual function is categorised according to observation or interview information. So far, research suggests that simple models are mainly used for task clarification and solution development. For these stages, CAD programmes were seen to offer only little help as they demand exact decisions and are not as intuitive as sketching [4]. Complex models and prototypes are mainly used in later stages. The function for the individual design process and the stage of the product life cycle are classified in the suggested tool.

3.3 Function of a collective objectification for the team

The exteriorisation of mental processes is not only important for the individual problem solving. It also serves as a means of communication and team building. For the collective

190

ICED 01 - C586/456

materialisation, Weber coined the term common objectification [5]. Some or all members of a team transfer their individual knowledge and experience in a joint action into a materially shape. By exteriorisation, the members make their knowledge available to others. They thereby create a shared meaning within and between the disciplines [6]. The members can use the collective knowledge and improve the objectification continuously. For the team building function, it is crucial which parts of the objectification were made together. The more an artefact is used and transformed by the group, the bigger are its impact on social bonds and the team identity. Weber showed that for teamwork in manufacture, the number and quality of collective objectifications correlates with co-operative attitudes in the team [5]. Therefore, objectifications can be used as an indicator for team cohesion. Following these results the usage of an objectification is classified for its team-building function. It is distinguished whether one, two or several members or the whole team create, use, modify or maintain an objectification and if these people are from the same or different professional background and department. The scale from 0 to 4 implies that the unifying potential is higher if more diversity is integrated into the artefact and if more collective effort is put into it. The team scales are defined in fairly behavioural terms so that they can be observed or recalled easily. From our observations on the use of artefacts for developing a common language in team meetings, we have seen that it is important to remain the visual image used in the meeting for the protocol [6J. It will be easier to recall what was actually presented, and the unfinished layout stimulates further brainwork on the topic better. Any transformation into word processing or CAD may be helpful for presenting results but always implies an interpretation. A public protocol has also helped to keep meetings more structured and to integrate different ideas into one solution.

3.4 Information distribution and knowledge management in R&D teams

From the organisational perspective, objectifications are a codified corpus of knowledge and become an issue for knowledge management [7]. They serve as a memory of the organisation that thereby acquires, develops, shares and stores knowledge of its members. From this perspective the transparency and re-usability by any other person is most important. In the previous sections, the focus war on the process, the result was only of secondary interest. In this section, we look at the corpus of abstracted knowledge that has been extracted from the activity of designing. It is not necessarily decontextualised but it has to be available and accessible to others to be of interest for the organisation. A technical solution can be seen in [8]. We differentiate the benefits for knowledge management following a classification of Probst et al. [9]. Transparency refers to overviews of external and internal knowledge. Acquisition means that existing knowledge is imported by the organisation whereas development refers to the generation of new knowledge within the organisation. Within the organisation, knowledge can be shared, used and stored. The document is classified to serve one or more of these functions. From our experience, we would also like to emphasize that the storage of information is a critical aspect and that it is essential to have a central storage of the knowledge, which enables all involved team members to access the knowledge whenever they need it [10]. A delay in the access for one or more team members can cause a delay for the whole R&D process. An institutionalised character of the other tasks can be of great usage and therefore a planned cycle can be of value for the knowledge management.

1CED01-C586/456

191

Figure 2. : Eight aspects of knowledge management [10].

In a second step, the accessibility of the objectification for all participants is analysed. For each person, it is listed whether the artefact is in their individual store or in a collective drive or place. It is also noted who is allowed to access it and how much effort it takes. The last step is the evaluation of the business profit of the particular artefact for the value of the information contained, the task adequacy, the effort for reuse and retrieval, the cost-benefit ratio, the transparency for other people and the transferability for other problems. These economic criteria need not conform to the psychological criteria for the design or the team process.

Example

We have used the tool in case studies in Swiss mechanical industry [11] and have since refined the methodology. We studied a range of objectifications in one team consiting of members from different departments and external suppliers. Part of the project was the design of a software tool for customer driven design that should support sales and offering. We observed an internal and an external software designer discussing their concepts for the interface between the external and internal database together with potential users within the company.

Figure 3. A collective objectification emerges from a discussion and is transformed into a poster used in the next session.

192

ICED01-C586/456

In the first step, the two engineers arrange existing material and draw on a big sheet of paper and thereby discover where they had different concepts of how the interface should be. The result is still rough and flexible; it invites to take part in the discussion. The artefact mirrors the collective design process. It scored high for team scores but low for readability to others and retrieval. In the second picture, the sketch has become a printed file. One of the engineers took the job to transform it for later presentation. It has become brighter and more colourful, more explicit in content and final in layout. However, the printout is less flexible than the original sketch. Other members of the team used the second artefact as a result without developing it further. Hence, the team score went down. The file would have been easy to change but it was not available to the other team members. Therefor, the score for knowledge management was not as good as could have been for an electronically stored document. A detail description of this example was used case study to introduced the tool in a class on research methods for social science students. The students were given the background information and two objectifications. They successfully work according to the instruction and received similar results.

Conclusions

We suggested a research methodology that can be applied not only to the individual sketching and modelling, but also to objectifications made and used by a group of designers. The classification draws also on the readiness for knowledge management systems. The tool proofed helpful to access to the history of former developments that we analysed for critical success factor in the upcoming project. It also provided a token to start an interview in a comfortable atmosphere as some designers feel more at ease to show an object than to give a verbal description of their work. However, the tool cannot be applied for pure document analysis as not all information requested is static and readable from the document or object itself. A detailed instruction makes the tool available for academic research as well as for knowledge management assessment in industry. The pilot use in social science education suggests that the analysis of objectifications is a promising method for empirical research not only in design studies. However, we believe most benefit is achieved when interdisciplinary research teams share their research methods and their understanding of artefacts. The tool is intended to turn our experience into codified knowledge for the design research community. References [1] [2] Leont'ev, A.N., Activity, Consciousness, and Personality, Englewood Cliffs: PrenticeHall, 1978. Hacker, W, Sachse, P. & Schroda, F., Design Thinking - possible ways to successful solutions in product development, In: Birkhofer, H. Badke-Schaub, P. & Frankenberger E. (eds.), Designers - The Key to Successful Product Development. London: Springer, 1998. Pache, M., Romer, A., Lindemann, U., Hacker, W., Mechanismen und Strategien beim Einsatz von Handskizzen in friihen Konstruktionsphasen. Kongress der DGPs. Jena 2000.

[3]

1CED01-C586/456

193

[4] [5]

Engestrom, Y., Miettinen, R and Punamaki, R. (eds.). Perspectives on Activity Theory. Cambridge, UK: Cambridge University Press, 1999. Weber, W.G., Collective Action Regulation, Common Task Orientation, and Common Objedifications in Advanced Manufacturing Systems, Proc. of TEA'97. p. 283-285, 1997. Lauche, K., Ehbets Muller, R. & Grote, G., Collective Conceptualisation in Early Phases of Innovation Processes. Proc.of Design 2000. Dubrbvnik, 119-124, 2000. Konda, S., Monarch, I., Sargent, P. & Subrahmanian, E., Shared Memory in Design: a Unifying Theme for Research and Practice, Research in Engineering Design, 4, 1992, p. 23-42 Reich, Y., Konda, S., Subrahmanian, E., Cunningham, D., Dutoit, A., Patrick, R., Thomas, M., Westerberg, A.W. and the n-dim group, Building Agility for Design Information Systems. Research in Engineering Design. 11, 1999, p. 67-83. Probst, G., Raub, S. & Romhardt, K., Managing Knowledge. West Sussex: Wiley, 1999.

[6] [7]

[8]

[9]

[10] Verbeck, A., Lauche, K. & Weber, W.G., Objectifications and sociotechnical features supporting integrated R&D teams to cooperate, Proc. of ICED 99. p. 217-222, 1999. Dr. Kristina Lauche Department of Psychology University of Aberdeen Aberdeen AB 24 2UB Scotland UK Tel. +44(0)1224272280 Fax +44 (0) 1224 273211 k. lauche@abdn.ac .uk IMechE2001 Dr. Alexander Verbeck ESEC S A Hinterbergstrasse 32 CH-63 3 0 Cham Switzerland Tel. +41-41-7495111 Fax +41-41-749 52 50 Alexander. Verbeck@esec. com

194

ICED01-C586/456

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN 1CF.D 01 GLASGOW, AUGUST 21-23, 2001

MODULARITY IN SUPPORT OF DESIGN FOR RE-USE J S Smith and A H B Duffy

Keywords: Design Methods, Design Tools, Modularity and Standardisation, Life-cycle

Introduction

We explore the structuring principle of modularity with the objective of analysing its current ability to meet the requirements of a 're-use' centred approach to design. We aim to highlight the correlation's between modular design and 're-use', and argue that it has the potential to aid the little-supported process of 'design-for-re-use'. In fulfilment of this objective we not only identify the requirements of 'design-for-re-use', but also propose how modular design principles can be extended to support 'design-for-re-use'.

Modular Design and Re-use

Modular design involves the creation of artefact variants based on the configuration of a defined set of modules. Modules are commonly described as a group of 'functionally' or 'structurally' independent components clustered such that 'interactions are localized within each module and interactions between modules are minimised' [1]. The principle aims to create variety, reduce complexity and maximise kinship in designs and across product families. Due to the fact that individual module functions and/or structures must eventually combine to realise the overall function/structure of the artefact, the modules can never truly be independent and must be defined together with the system to which they belong. Thus, further 'between module' or 'interface' constraints must be considered for modules to be successfully configured to meet overall system requirements In exploring why modular design so readily maps to the 're-use' perspective we consider some of the major benefits of the approach, including: efficient upgrades; improved design understanding; improved knowledge structures; improved knowledge management; improved knowledge utilisation; reduction in complexity; reduction in costs; rapid product development [2,3,4]. These benefits support increased utilisation of experiential knowledge for new product development and thus provide an approach on which to actively support 're-use'. However, despite the existing evidence as to its benefits, 'little work has been done on these research issues' [3] and 'modularity has been treated in the literature in an abstract form' [5]. That is there is a need for approaches 'to determine modules, represent modularity, optimise modular design and assess the impact of modularity on the design process' [5].

ICED01-C586/046

195

Supporting 'Design for Re-use'

There is a current drive towards modular structuring of products, motivated by the body of evidence as to its benefits. Despite significant correlations between the two, currently no modular design methodology specifically emphasises support for 're-use'. In the 're-use' field studies have shown 'design for re-use" can have a significant impact on the realisation of 'reuse' related benefits [6], Since it suffers from the most notable lack of support, of all the reuse processes [7], the potential for a modular design methodology/tool to support this process is examined. Modular Design in support of 'design for re-use' would be better facilitated by: Supporting the dynamic knowledge generated by the designer within the designer's different viewpoint requirements, as the design proceeds from the abstract to the concrete, and mapping knowledge relations between these for improved design understanding. Supporting module generation based on various viewpoint and/or lifecycle objectives and facilitating a mapping between each to optimise module definition and design. Supporting the re-use of generated modules and their associated knowledge through the provision of an explicit formalism for design knowledge, dependency knowledge and module definitions. Facilitating the exploration of 'design by re-use' by mapping potential design changes/decisions onto the previous modular solution and its associated development knowledge.

3.1 Current approaches

Current approaches fail to fulfil the requirements of a modular design methodology for re-use, as outlined above. The majority of approaches focus solely on a particular viewpoint, generally a functionally or structurally orientated one. Existing approaches to modularity can be grouped into 3 distinct categories: those based on function, on the potential means or technical solution of realising this function, and finally on physical parts and/or components. Modularity from a functional viewpoint is the focus of research by Huang and Kusiak [5], where sub-functions, those that must initially be realised to fulfil the overall artefact function, are grouped or clustered to form 'functional' modules based on their relation to, similarity to, or dependence on one another. Chang and Ward [8] and Erixon [9] provide examples of 'behavioural modularity' based on the technical solutions or means of fulfilling the functional criteria of a design. The component/part view and its inter-relations are the focus of Sosale et al [1], and Kamrani [10]. Here termed, 'structural modularity' its focus is predominantly on later-life cycle objectives i.e. low level 'nuts and bolts' assembly, process planning, service, maintenance, parts re-use, recycling and disposal. Here, Sosale et al are seen to focus on modularity for recycling and disposal whereby well defined physical parts are grouped into modules based on their similarity in areas such as life span, material, maintenance level, disposal method, recycling capabilities, etc. Kamrani [10] expresses concern that 'conceptual design modules' and those of a 'functional to technical nature', cannot meet the constraints of later stages of design. Likewise, it can also be argued that due to the nature of 'structurally' orientated modules they fail to capture and/or explicitly represent knowledge from earlier conceptual phases of design or more generalised knowledge. There is a need to develop a methodology which allows the designer to examine

196

ICED 01 -C586/046

and express modularity throughout the design process to promote a deeper understanding of: the nature and evolution of modularity; life-cycle objectives and modular trade-offs; and to promote systematic extraction and representation of design knowledge from project inception 'for re-use'.

3.2 Modular approaches that consider more than one viewpoint

There is increasing recognition that modern design methodologies require to support the multiple viewpoints of design within a coherent and integrated structure [11-13]. Viewpoints, within the context this research, represent structured views of 'engineering design' required by the designer in order to evolve the engineering design process to a suitable conclusion [14]. The prime concern of this research however is the support of the design life-cycle phase, from 'requirement to artefact definition', and how best to support the knowledge generated through this 'for re-use'. Secondly, we define a life-cycle objective to be the expression of a required and/or preferential need with respect to an individual or group of artefact stakeholders from various stages of the entire artefact life (of which the 'design process' can be considered only one part i.e. customer, designer, manufacturer, assembler, user, maintainer, disposer). Salheih and Kamrani [13] note that the principle of modularity 'can be applied in product design, design problems, production systems, or all three'. Thus acknowledging the need to support different aspect of the product life-cycle with the modular principle. However, although the methodology deals with 4 stages of design, modularity and its associated benefits are neither expressed nor attained until late in the design process. Thus abstract knowledge important for the maintenance of knowledge for re-use [15], is not supported, nor modularised, and consequently the approach fails to maintain design knowledge 'for re-use'. Jiao and Tseng [12] plan for modularity across 'views' but their interpretation differs. 'Engineering design' is dealt with in only one view, the technical view, while the others constitute alternative stages in the life cycle of a product. However, their "views" are independent in that issues relating to different business functions are dealt with in different views.

A Modular Design Methodology for Re-use

Current approaches do not adequately formalise, nor maintain, the knowledge behind defined modules nor facilitate mapping between different viewpoints of the 'engineering design process' and consequently they are too inflexible to fully support 'design for re-use'. The authors' proposed approach focuses solely on views in the 'design process' with the intention of furthering our understanding of relations and constraints within, and across, viewpoints to aid the realisation of modularity from project inception. By developing methods to define and manage modularity from the higher level 'functional' view to Mower level' parts, geometry and physical characteristics, we aim to take into account life-phase modular needs during design while utilising the principle as a tool to extract, manage and enhance design knowledge 'for re-use'. For successful support of 're-use', 'a modularisation strategy must be incorporated at project inception' [16] and be evident throughout the product development process and beyond. The difficulties in achieving this support include the notion that modularity is not a constant property (what is modular in one viewpoint may not be in another) and that modularity can be achieved in different forms (different modular structures support different modular objectives). It is suggested that a deeper understanding and more

ICED01-C586/046

197

adequate support of; 'within', 'between' module, and across 'viewpoint' relations would aid in the management of such difficulties. Relations are far more complex than the 'functional dependence' or 'physical link' of relations utilised in current approaches to modular design. There are complex dependencies involving functional, mechanical, information, energy and material relations and constraints.

4.1 The components

The following presents novel 'modular design methodology for re-use' which aims to address the previously outlined issues and inadequacies of modular design support. The methodology consists of 4 main elements: a knowledge formalism, an interdependency matrix application, a clustering mechanism and a mapping mechanism. 4.1.1 Element 1 - Knowledge Formalism The methodology will utilise elements of a previously developed knowledge formalism [17]. The formalism takes a Multi-Viewpoint Evolutionary Approach to formalising both current working design knowledge and knowledge related to the domain. Thus, it has the ability to support and formalise knowledge of an evolving design over the viewpoints inherently adopted by the designer as shown in figure 1. As we are predominantly concerned with supporting 'design for re-use', a process carried out during design itself, our initial focus is on the CWK formalism.

The approach allows the designer to formalise knowledge within viewpoints as concepts (encapsulating knowledge of the designer's ideas of the design) with attributes (input matters, output matters, behaviour properties, principle properties, parts, etc.) and constraints (both on the concept and attributes; see Figure 2a) and relations between concepts (Figure 2b). Concept constraints indicate application conditions whilst attribute constraints represent dependencies between individual attributes. Between concept relations can have a type (Has-kind, A-kindof, A-part-of, Has-part, Functional-dependency, Physical link) and a direction (see Figure 3). Relation constraints consist of pre and post relation constraints. The formalism also notes a causal link relation across viewpoints, Figure 1.

Relation (type, direction) Figure 2 (a) - Concepts, attribute and constraints (b) Relations between concepts

198

ICED01-C586/046

This formalism is utilised as it supports the evolution of a design whilst defining relation/dependency knowledge between concepts both within and across viewpoints of design. 4.1.2 Element 2 - Interdependency Matrix Application A matrix application (see Figure 3) can provide a representation of the formalised concepts, relations and their constraints, which aids in the formalisation, detection and analysis of; concept dependencies, concept duplication/redundancy, potential modular solutions based on matrix interpretation rules and other grouping/clustering techniques (element 3), and module definition.

Figure 3 - An Interdependency Matrix Application

4.1.3 Element 3 - The Clustering Mechanism Various clustering and grouping techniques are currently under investigation to support the module design and optimisation process. The techniques are required to support module design based on a number of criteria, including: Maximisation of internal relations between concepts. Minimisation of external relations between concepts. Concept, attribute and relation constraints. Significant lifecycle objectives i.e. manufacturing, maintenance, technology life-spans etc. Maximum and minimum module number and size.

4.1.4 Element 4 - The Mapping Mechanism A mapping mechanism is required to support modularisation from project inception and capture knowledge of the evolution of the modular design solution. The mapping mechanism is a key element of the methodology's 'design for re-use' support as it allows capture of both the final solution and associated development knowledge to permit a deeper understanding of 'how' and 'why' the solution developed from the abstract to the concrete. The mechanism would also support analysis of the effect of a change in 'modularity' focus i.e. change of constraints, life cycle objectives and/or module size/number. Further, when utilised in a 'by re-use' scenario the mechanism could allow analysis of the impact of design changes and support partial re-use of the design solution (modules) and their associated knowledge.

ICED 01 -C586/046

199

Figure 4 - Mapping Mechanism

4.2 The application process

The envisaged application process of the above methodology involves an iterative application loop which supports the generation of modules as the design evolves from the abstract to the concrete as shown in figure 5.

Figure 5 - Envisaged Methodology Application Process

200

ICED01-C586/046

4.3 The Application Field

The methodology is currently under development in the field of marine design in conjunction with BAE Systems Marine Ltd (Forward Design Group) and Alenia Marconi Systems. The marine field was chosen based on the findings of a previous study in the area which highlighted a significant correlation between support for the process of 'design for re-use' and the achievement of 're-use' related benefits [6], More specifically, we focus on the potential modularisation of the engineering (hardware) design of a weapons systems command console. The console was chosen for a number of reasons including: New Generation Console Development: The console is currently undergoing a significant redesign which results in easier access to documentation on previous generation consoles, and the ability to analyse the results of the methodology's application against both the new console design solution and the process undertaken to achieve it. Sufficient Complexity: The console's requirement to integrate a number of differing functions, mechanisms and technologies is expected to result in the development of a more robust methodology. Embodiment of Ship Design Issues: The console must take into account a number of ship design issues, including: Ship Class Maintenance, which requires that all previously designed ships in that class must be of similar outfitting to ensure adequate integration of all ship systems. As the design and manufacture of a naval ship class can span decades this is an especially pertinent issue in the design of a console which embodies technologies subject to rapid development (processors, video, VDU's, control mechanisms, etc). System Integration, which requires that elements of individual ship systems (propulsion, waste water, navigation, communications) must be designed to not only integrate within the individual system to which they belong but the ship as an entire system. Long in Service Life Span, which requires specific emphasis on both the robustness of components and the minimisation of retrofit requirements of individual ship systems. Thus, these issues provide a case with significant life-cycle objectives on which to base the development and analysis of the methodology.

Conclusion

The correlation between the principles of modular design and the requirements of 'design for re-use' has been presented. The main issues that attribute to the inadequacy of current modular design approaches in supporting this process have been highlighted and discussed. To address these issues a 'modular design methodology for re-use' has been presented that is currently being developed in a bid to provide better support for the relatively neglected process of 'design for re-use'. References [1] Sosale, S., Hashiemian, M., and Gu, P., "Product Modularisation for Re-use and Recycling", ASME, Design Engineering Division, DE, Vol.94, pi95-206, 1997

ICED01-C586/046

201

[2] [3] [4] [5]

Miller, T.D., "Modular Engineering of Production Plants", International Conference on Engineering Design, ICED '99, Munich, August 24-26, 1999 O'Grady, P., and Liang, W., "An Object Orientated Approach to Design with Modules", Computer Integrated Manufacturing Systems, Vol. 11, No.4, p267-283, 1998. Muffato, M., "Introducing a Platform Strategy in Product Development", International Journal of Production Economics, Vol. 60, p!45-153, 1999. Huang, C.C. and Kusiak, A., "Modularity in Design of Products and Systems", IEEE Transactions on Systems, Man and Cybernetics - PartA: Systems and Humans, Vol.28 No. 1, January, pp 66-77, 1998. Duffy, A.H.B., and Ferns, A.F., "An Analysis of Design Reuse Benefits," in Proceedings of the International Conference on Engineering Design, Munich, 1999. Smith, J.S., and Duffy, A.H.B., "Product Structuring for Design Re-use", Proceedings of the 5th WDK Workshop on Product Structuring, February 7-8, Tampere University of Technology, Tampere, 2000 Chang, T., and Ward A.C, "Design-in Modularity with Conceptual Robustness", ASME, Design Engineering Division, DE, Vol.82, Part.l, p493-499, 1995. Erixon, G., "Modular Function Deployment - A Method for Product Modularisation", Doctoral Thesis, Manufacturing Systems, The Royal Institute of Technology, Stockholm, 1998.

[6] [7]

[8] [9]

[10] Kamrani, A.K., "Modular Design Methodology for Complex Parts", 6lh IIE Annual Engineering Research Conference, Miami Beach, Florida, USA, p391-396, May, 1997. [11] Jarventausta, S., and Pulkkinen A., "Enhancing Product Modularisation with Multiple Views of Decomposition and Clustering", Proceedings of the 5th WDK Workshop on Product Structuring, February 7-8, Tampere University of Technology, Tampere, 2000 [12] Jiao, J., and Tseng, M.M, "A Methodology of Developing Product Family Architecture for Mass Customisation", Journal of Intelligent Manufacturing, Vol.12, p3-20, 1999. [13] Salheih, S.M, and Kamrani, A.K., "Macro Level Product Development using Design for Modularity", Robotics and Computer Integrated Manufacturing, Vol.15, p319-329, 1999. [14] Kerr S.M., "Customised Viewpoint Support for Utilising Experiential Knowledge in Design", Doctoral Thesis, DMEM, University of Strathclyde, UK, December, 1993. [15] Smith., J.S., and Duffy., A.H.B., "Re-using Knowledge: Why, What and Where", Submitted to the International Conference on Engineering Design, ICED '01, Glasgow, August 21-23, 2001. [16] Burke, G.P, and Miller, R.C., "Modularisation Speeds Engineering, Vol.102, Part.l, January, p20-22, 1998. Construction", Power

[17] Zhang, Y., "Computer-based Modelling and Management for Current Working Knowledge Evolution Support", Doctoral Thesis, DMEM, University of Strathclyde, UK, May, 1998. Joanne S Smith CAD Centre, DMEM Department, University of Strathclyde, M209, James Weir Building, 75 Montrose Street, Glasgow, Gl 1XJ, Scotland, UK Tel: +44 (0)141 548 3020 , Fax: +44 (0) 552 0557, E-mail:jo@cad.strath.ac.uk , URL- www.cad.strath.ac.uk JSSmith2001

202

ICED01-C586/046

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

CAPTURING AND CLASSIFYING INFORMATION IN UNDERGRADUATE DESIGN TEAM PROJECTS

P A Rodgers Keywords: Design rationale, design education, student design teams, information analysis, classification and retrieval.

Introduction

As the complexities involved in new product design and development processes increase, the capture, classification and representation of design information takes on ever-greater significance. Capturing the information design teams analyse and utilise during their decision making tasks is often referred to as the design rationale [1, 2]. Design rationale methods and tools promise effective overall design process management, more efficient use/reuse of design knowledge, and improved design documentation. The major objective of this paper is to investigate these claims using an existing design rationale technique in a "live" undergraduate design team project. The paper begins by defining the concept of design rationale in the next section. The paper then develops to describe, in detail, the undergraduate case study and the rationale captured during the design project presented. The paper finishes with results of the case study exercise, conclusions and indications for future work.

Design Rationale Methods

Design rationale generally includes not only the reasons behind a design decision but also the justification for it, the alternatives considered, and the argumentation leading to decisions made. However, as Shipman and McCall [3] point out, design rationale can be viewed in three different ways: Communication: capturing and retrieving naturally occurring communication (e.g. design discourse) among members of a design team. The recording of design communication is not meant to have any effect on the design process. Documentation: the documentation of information about design decision making, including what decisions are made, when they are made, who made them, and why. Argumentation: the reasoning that designers use in framing and solving problems. This includes both the reasoning of the individual designer and the discourse among team members in a design project.

It has been suggested that the more structured argumentation perspective of design rationale has the potential to solve many of the acquisition and classification problems associated with design decision making activities [4]. Perhaps the best-known example of this perspective on

ICED 01 -C586/118

203

design rationale is the Issue-Based Information System (IBIS) framework for argumentation proposed by Rittel et al. [5, 6]. This approach to design rationale is based loosely around four organisational atoms, namely: Issues: topics that must be resolved before a design specification can be generated; Positions: may be solutions or methods for resolving issues; Arguments: ideas that either support or refute a position; References: documents cited in support of arguments.

During the design process, team members raise issues and take positions according to their opinion, expertise, training and so on. To justify their positions, they support or object them with arguments. To strengthen their arguments, they cite references. The four atoms or nodes described above can be connected by a variety of links to produce an IBIS network such as that shown in Figure 1.

Figure 1. IBIS Network Example (after Cao and Protzen [7])

The undergraduate design team project study described in the next section adopts this view of the term design rationale and utilises Rittel et al's IBIS framework for capturing and indexing the design discussions made during the student design team project.

Capturing and Indexing Design Rationale: A Case Study

The case study described here involved second year undergraduate interdisciplinary design students working on a "social design" project at Napier University in collaboration with

204

ICED 01 -C586/118

Penicuik High School, a local secondary school near Edinburgh (Figure 2). The project included the students working in small teams of three to four, on the redevelopment of selected areas of the school in consultation with members of the school including pupils, teachers, and school governors. The overriding goal was simply to improve the social, physical, and mental well being of the users of the school (i.e. pupils, teachers, and ancillary staff) through the redevelopment of a particular area or aspect of the school experience.

Figure 2. Secondary School Environment (Exterior - left; Interior - right)

Solutions generated during the project included new and improved secure bicycle parking systems, a concept for a transportable bag/ desk/ chair, and the redevelopment of both interior and exterior areas of the school (e.g. gallery for school art, playground furniture/ shelter).

Figure 3. Student Team Design Rationale Project Example (using the IBIS framework)

ICED01-C586/118

205

During the fifteen-week project students were asked to record and to organise their discussions and decisions using the IBIS framework outlined earlier in Figure 1. Each project team was asked to propose issues, state positions, raise arguments, and cite references as their design progressed over the course of the project. Figure 3 illustrates a small section of the design rationale framework for the student team's secure bicycle parking system project which is described in greater detail in the following sections.

3.1 Case Study Project: Secure Bicycle Parking System

The team involved in the development of the secure bicycle parking system described here consisted of four interdisciplinary design students namely Aaron, Alexis, Gian and Ma. The project commenced with the team meeting representatives of the school including pupils, teachers, ancillary staff (i.e. school caretaker, office staff), and school governors. This forum provided everyone with the opportunity to discuss particular aspects of the "school experience" from a number of diverse perspectives. During this meeting a number of relevant major projects under the theme "school regeneration" surfaced. For example school pupils highlighted the present unsuitable indoor and exterior sporting facilities, staff members suggested the improvement of the staff resource room as a suitable project, and both staff and pupils indicated the lack of secure storage for their bicycles as a major weakness of the school environment.

3.2 Bicycle Parking System Issues

After consultation with the school caretaker and the pupils in particular, the design team set out to design a new secure parking system for bicycles. A number of initial issues, which were identified by the design team, are shown in Figure 4. The key single issue of how bikes are attached to the secure system presented the design team with a number of problems, however. In an attempt to address this specific issue, the team generated a number of positions (design solutions) that are described in greater detail in the next section.

Figure 4. Initial Secure Bicycle Parking System Issues

206

ICED01-C586/118

3.3 Bicycle Parking System Positions

A number of solutions (positions) were generated to meet the issue of attaching the bikes securely. The IBIS framework produced by the design team has highlighted this single issue as significant in the development of the secure bicycle parking system. A selection of the important positions (concepts) developed to resolve the issue of how best to attach the bikes securely are shown in Figure 5.

Figure 5. Secure Bike Parking System Positions Examples

A number of arguments both in support and refuting the above positions (Figure 5) and others were raised by the design team during the project. These are described in more detail in the next section.

3.4 Bicycle Parking System Arguments

Arguments against the position illustrated at the extreme right of Figure 5 included: "kids would not be able to push their bikes up the ramp" (Isla); "the gap underneath may inadvertently act as a trap for children" (Alexis)', "BMX-style bikes would not be accommodated in the ramp concept as it stands" (Giari); "the height of the ramp sides may be problematic for some bicycle gear mechanisms" (Aaron); "there may be difficulties actually locking the bikes to the ramp system" (Gian); "access to lock and unlock bikes near the middle of the ramp configuration may be difficult" (Ma).

ICED01-C586/118

207

Although many of the students' arguments were not backed by official documents that they may have cited, several arguments posited were strengthened by references to experts in the field (i.e. school janitors, local architects, engineers and so on). A process of iteration followed in the secure bicycle parking concept with several variations on issues, positions, and arguments being discussed and recorded until the design team developed a final scheme to present to the school. Figure 6 shows one of the final presentation scale models for the secure bicycle parking system developed by the team. The main idea behind the design solution shown in Figure 6 is that each site-specific secure bicycle parking system would comprise any number of individual modular units. For instance, the system shown in the model (Figure 6) comprises a total of 5 individual secure units.

Figure 6. Presentation Scale Model of the Secure Bicycle Parking System

Presently, a committee comprising pupils, teachers, governors, and parents of Penicuik High School (near Edinburgh) are in discussions with the student design team concerning greater development of the scheme. The intention is to finance the completion of at least one sitespecific modular unit within the school. The student design team are currently addressing issues regarding the materials' specification, manufacturing limitations and budgetary implications.

Conclusions and Results

Although it has been suggested that the argumentation-based "design rationale" technique of IBIS offers a natural framework to record design information as structured arguments, it can be difficult to acquire design information using this representation effectively [8]. Generally speaking the results obtained during this study concur with the view of Grant [8] and of other

208

ICED01-C586/118

researchers in the field. That is, the students within this study experienced difficulties initially with the terminology used in the IBIS framework, and encountered problems over categorising their deliberations. Furthermore, the majority of students involved in this study indicated specifically on several occasions that the structure of IBIS was "too restrictive" and was interfering with their creative design activities such as generating solutions. Also they noted many times that they were overly preoccupied recording the design rationale of the group and not spending enough time designing. In an effort to alleviate this problem, a couple of the design teams attempted to audio record their deliberations as they worked. However, this was not successful as the amount of background noise heard on playback hindered complete translations of the decision making and argumentation that had occurred. Generally speaking the design teams relied on their collective memories and tended to rely on retrospectively recording their design rationale throughout the duration of the project. In summary, although the end results of the design rationale exercise (using the IBIS framework) were fairly impressive the procedures adopted by the students were disappointing. Specifically, the retrospective manner in which the design teams captured their decision-making rationale. This may be due, in part, to the relative inexperience of the students involved in the case study (i.e. 2nd year undergraduate design students). Future work on this theme may include the utilisation of final year design students during their major project.

Acknowledgements

The author would like to thank everybody at Penicuik High School who were involved in this project. In particular Paul Beards, the head of the Design and Technology department, for his co-operation and support. The author would also like to acknowledge the dedication and diligence of the 2nd year BDes Interdisciplinary Design students throughout this very fulfilling collaborative project. References [1] [2] LEE, J., "Design rationale Systems: Understanding the Issues", IEEE Expert. 12 (3), 1997, pp. 78-85 Burge, J. and Brown, D.C., "Reasoning with Design Rationale", in J.S. Gero (Ed.), Artificial Intelligence in Design 2000. Kluwer Academic Publishers, Dordrecht, The Netherlands, 2000, pp. 611-629 Shipman, F. and McCall, R., "Integrating Different Perspectives on Design Rationale: Supporting the Emergence of Design Rationale from Design Communication", Artificial Intelligence in Engineering Design. Analysis, and Manufacturing (AIEDAM). 11 (2), 1997, pp. 141-154 MacLean, A., Young, R., and Moran, T., "Design Rationale: The Argument Behind the Artifact", Human Factors in Computing Systems. CFfl '89 Conference Proceedings. Austin, Texas, 1989, pp. 247-252 Kunz, W. and Rittel, H., "Issues as Elements of Information Systems", Working Paper 131. Center for Planning and Development Research. University of California. Berkeley. 1970.

[3]

[4]

[5]

ICED01-C586/118

209

[6] [7] [8]

Rittel, H., "On the Planning Crisis: Systems Analysis of the First and Second Generations", Bedriftsokonomen. 8, 1972, pp. 390-396 Cao, Q. and Protzen, J.P., "Managing Design Information: Issue-Based Information Systems and Fuzzy Reasoning System", Design Studies. 20, 1999, pp. 343-362 Grant, D., "Argumentative Information and Decision Systems", Design Methods: Theories. Research. Education and Practice. 26, 1992, pp. 1524-1588

Dr Paul A. Rodgers School of Design and Media Arts, Department of Design, Napier University, Merchiston, 10 Colinton Road, Edinburgh EH 10 5DT, Scotland, UK. Tel: +44 (0)131 455 2678, Fax: +44 (0)131 455 2292, Email: p.rodgers@napier.ac.uk, URL: http://www.napier.ac.uk/depts/design/home.htm

IMechE2001

210

ICED 01 -C586/118

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

INCORPORATING INCENTIVES INTO DESIGN DOCUMENTATION TOOLS

T Lloyd and L Leifer Keywords: Motivation, incentives, documentation tool, survey.

Introduction

There is a critical flaw with the current design documentation tools that inhibit them from being effective. Many documentation tools focus on reducing a designer's effort to perform documentation, while leaving the responsibility of motivating the designer to perform documentation solely to the company employing the tool. If the company is in tune enough with its designers to know what kind of incentives, such as monetary or recognition awards, motivate them to comply to management wishes, then the combination of effort reduction and incentives can be quite effective. For example, Ford has built an easy to use on-line database of more than 2,800 proven automotive best practices worth an estimated $1.25 billion [1]. Ford's Best Practices Replication Process uses a high profile recognition system that publicly scores the knowledge contribution of each plant as an incentive to support knowledge sharing and design documentation. However in the absence of such compliance incentives, reducing design capture effort alone is often insufficient motivation to do documentation. At first it may appear that capturing design knowledge because it will be advantageous to future designers working on the project, would be sufficient incentive for designers to do documentation. However for designers who are under pressure to meet project deadlines, juggle several design tasks at once, and still perform documentation for potentially someone else's future benefit, this incentive falls short [2]. In the absence of incentives for documentation compliance, designers naturally prioritise the tasks that give them immediate benefit over documenting. In companies that lack strong rewards for design capture and knowledge sharing, the designers' value to the company and thus job security are typically dependent on the success of their projects. Therefore, tasks that have a more immediate impact on the success of the project tend to get done first, then if the designers have time, they consider the tasks that will have longterm effects on the project and the company, i.e. documentation. Even when the effort required to capture the design is relatively low, there is always an opportunity cost associated with the documentation effort. When the opportunity cost is perceived to be higher than the benefits of documenting, designers will not willingly pay the price to document. For instance, De Long and Fahey take note of a printed circuitboard design team that refused to document their lessons learned per management orders because the time spent reflecting on their experiences would ultimately cost the team some billable hours. It was not until management established an account for charging time spent in collecting lessons learned that the team followed orders [3]. The team perceived their value in terms of billable hours and not in terms of documentation or knowledge sharing.

1CED01-C586/472

211

Until management supplied an incentive that was equal to the opportunity cost, the team did not comply with management's wishes. In essence a documentation tool's success or failure depends on the potency of the company's documentation compliance rewards. In order to attenuate the tool's dependency on company culture, it is necessary to incorporate documentation incentives within the tool. Since designers prioritise tasks that have an immediate benefit to them, such as the project's success, it is hypothesised that motivation to do documentation will increase by enabling design capture to have a more immediate impact on the success of the project. A documentation tool that not only captures the design process, but also gives meaningful feedback to the designer, will encompass viable documentation incentives. However, which of the many potential feedback tools available through documentation will a designer find particularly rewarding and motivating? Perhaps the answer is found in the understanding of why designers are motivated to do design work in the first place. For it may be possible to build upon these 'pre-existing motivations' to establish an incentive that is already known to have some weight or rather pull with designers. As an initial effort into incorporating incentives into design documentation tools, this paper endeavours to: 1. establish a baseline of how motivated designers are to do documentation; 2. examine designers' pre-existing motivations to do design work to identify the types of feedback designers might find rewarding as incentives; 3. examine the importance of several design activities to determine which activities documentation tools should supply feedback; and 4. explore the challenges for designers to record design rationale to establish key areas for documentation effort reduction.

Methodology

To investigate the ideas presented here, an exploratory survey was completed on 31 mechanical engineering design students and on 35 engineering professional designers. The sampled students were all Stanford University students enrolled in a graduate-level 30week long project design course that attempts to model an accelerated research and development cycle. The course requires an extensive project status report every 10 weeks and documentation is approximately 30% of the student's final grade. The survey was conducted about 22 weeks into the course on 17 students (a response rate of 81.0%) and then it was repeated about 14 weeks into the course on the following academic year on a new set of 14 students (a response rate of 46.6%), thus totalling 31 students. The average design experience of the students was 3.15 years from school projects plus 1.12 years from internships and professional experience. The sampled professional designers all worked at a Palo Alto, California design consultant firm called IDEO Product Design. There was only a 36.8% response rate. Of the professional designers 51.4% are solely in the mechanical discipline, 17.1% are of mechanical and product disciplines and the remaining where solely industrial (8.6%), interaction (8.6%), and other (14.3%) disciplines. The average professional design experience of the professional designers was 8.9 years with 42.9% having had 2 or more years of management experience.

212

1CED01-C586/472

The survey was self-administered and contained five core questions and a set of background design experience questions. Figure 1 shows the five core questions stated in the professional survey. The first and second academic versions differ from the professional version when requesting percentage of time spent on design activities, the major column divisions are for the course experience and for professional experiences. In addition, the first academic version also omits the first core question.
1. Rank the following design task by how much you enjoy doing them? Where 1 is most enjoyable and 8 is least eniovable. Identifying - problem identification Brainstorming - idea and concept generation Benchmarking - users and existing designs and concepts investigation .Decision making - idea and concept selection Prototyping - prototyping concepts and components Documenting - capturing the design rationale Evaluating - getting feedback on brainstorming, benchmarking, decision making, mock making and or documentation Reflecting - looking back on the design process and evaluating what went well and not so well Other 2. What percentage of time do you typically spend on the design process from your experience at your current company and from your experience at your previous companies? At Current Company Identifying Brainstorming Benchmarking Decision making Prototyping Documenting Evaluating Reflecting Other 3. What motivates you to do design work? 4. What do you feel is most challenging about recording your design rationale? 5. How important is the following to you as a designer? Indicate High importance with an H, medium importance with M, and low importance with a L. _Staying technology current Knowledge about previous relevant designs ^Communication with co-workers Time management _Knowledge about venders and manufacturers Recording your design rationale Observing the potential user Generating a variety ot ideas Other At Previous Companies Identifying Brainstorming Benchmarking Decision making Prototyping Documenting Evaluating Reflecting Other

Figure 1. Professional Version of the Survey's Five Core Questions (survey format slightly adjusted to conserve space)

The survey was designed to gain insight into four main issues. The first core question asks the subjects to rank the enjoyability of a series of typical design tasks. The purpose of this question is to establish a baseline for how the subjects feel about documentation. The higher the task ranking the more enjoyable and thus motivating the task is likely to be. By comparing the sampled data to other case study data, the second core question along with the background questions are used to check for possible abnormalities in the sampled data set that might indicate that the sampled set is biased. The third and fourth core questions' are designed as open-ended questions to permit the subjects to briefly express their thoughts on their design motivation and their challenges to documentation. The purpose of these questions is to test the variability of design motivation and to succinctly get at the heart of the documentation problem. The fifth core question extracts what is important to designers by asking them to rate typical information centered design activities. A coding scheme is required to statistically analyse the third and forth core questions since they are open-ended. Table 1 and 2 show the coding scheme used in the analysis. The coding scheme was developed while examining the subjects' responses to each question.

1CED01-C586/472

213

Typically responses to each question expressed several sources of design motivation and challenges to recording rationale, respectively. Coding Schemes used in Designer Motivation analysis
Table 1. Coding scheme for the third core question, "What motivates you to do design work?"

A response was marked as the code if the subject's answers... Included reference(s) to prototypes or the end product, or included variations of the word create, such as inventing, creation, or building Creative Included the word "creative" or "creativity" Fun Included the word "fun" Help Indicated meeting needs or improving situations or someone's life Social Indicated interaction with people, such as teams, co-workers, or customers Solving Problems Included a variation of the phrase "problem solving" or references the end solution (as opposed to the end product) Coding Schemes used in Challenges to Design Rationale Recording analysis
Table 2. Coding scheme for the forth core question, "What do you feel is most challenging about recording your design rationale?"

Code Create

Code Opportunity Cost Format/Medium Details Skill Time

A response was marked as the code if the subject's answers... Included a variation of the phrase " rather be doing X" Referenced a particular documentation medium or format Indicated level of content detail or precision Indicated personal inability at a skill such as drawing, writing, or communicating Include the word "time"

The survey responses were fairly regular for the majority of questions, however, there were some irregular responses that were rejected for the following reason or adjusted in the following manner instead of rejecting the answer. For the first core question, if it was obvious that some subjects rated the design tasks as opposed to ranked the design tasks as was asked, their response was not included in the ranked results. Unfortunately almost half of the professional subjects rated instead of ranked, which was not foreseen as a potential problem from the pilot study. For the second core question, when time spent on the design activities did not total exactly 100% as anticipated, the percentage for a task was calculated as the ratio of the time spent on the design task and the sum of time spent on all the design tasks. For all questions, if a subject skipped a question, the non-response was not included in the results and the sampled size was readjusted accordingly.

Survey Findings

3.1 Checking Sampled Data for Cultural Bias

As this survey did not select its subjects randomly from all possible designers, but sampled only a small subset of the designer population designing in northern California, the findings may have an inherent bias due to the clustering of the sample pool. To investigate the extent of this potential bias, the subjects were asked for the percent of time spent on various tasks in the design process and the results are shown in Figure 2. It is believed that

214

1CED01-C586/472

division of time is a good indication of cultural values, and that differences in cultural values would be the most likely source of bias error. Since this study is concerned about developing conclusion for documentation tools, a documentation cultural bias would have the largest impact on the survey findings. Comparing the sampled data to previous design research data revealed that the average percent of time spent documenting for the students and professional designers sampled were statistically similar to a study performed by Crispin Hales on New England designers between 1982 to 1986[4].

Figure 2. The average percentage of time spent on the design process for both the professional and student designers surveyed.

3.2 Establishing the Baseline of Documentation Motivation

Figure 3. Comparing the enjoyable nature of design tasks as an indication of designers' motivation towards the task.

To measure how designers feel about documentation as compared to other design tasks, the subjects were asked to rank the enjoyability of eight common design tasks. As shown in Figure 3, the results indicate that documenting is the least enjoyable task with an enjoyability score of 0.2. As motivational theories suggest, task enjoyability is an indicator of motivation to perform the task, higher enjoyability corresponds to higher motivation and lower enjoyability corresponds to lower motivation [5]. As designers work through the design process, they are more motivated to work on seven other design tasks as opposed to

1CED01-C586/472

215

documentation. This establishes a baseline for comparing improvements in documentation motivation relative to other design tasks. As documentation tools incorporate incentives, the relative rank of documentation enjoyability changes in accordance to the power of the incentives.

3.3 Designers' Motivation and Design Activity Importance

As noted in the introduction, the possibility of forming incentives that are aligned with designers' pre-existing motivations to do design work might be a powerful way to motivate designers to do documentation. However, in order to take advantage of these preexisting motivations within a tool's framework, there are two prerequisites. First, the preexisting motivations have to be fairly common across designers and second, these common motivations must lead to incentives that can be administered solely by the tool. The first prerequisite is necessary so the tool is not overwhelmed by having to determine a designer's pre-existing motivations from a multitude of possibilities. The second prerequisite is necessary to ensure the tool's incentives are independent of the company culture in which the tool is deployed.

Figure 4. Compares the occurrence of coded motivations to do design work in an effort to identify the commonality of these motivations between designers.

The survey asked, "What motivates you to do design work?" and the percent of subjects expressing a particular motivation are shown in Figure 4. There is some variation in the percent of shared motivation between the students and professionals, but there is a substantial agreement that the ability to create something motivates them to do design work as 37.5% of the combined responses were coded as such. Only 10.9% of all the responses could not be codified by the six categories and is a good indication that the first prerequisite of motivation commonality is satisfied. The second prerequisite is harder to evaluate from the findings alone, but each of the high frequency response categories suggest a viable point to start exploring incentives that will have a wide appeal to designers. Since designers already have an appreciation for the categories, meaningful feedback on the design process should be relevant to one or more of these areas. However, giving relevant feedback based on designers' motivation alone is not enough, the feedback must be given on design tasks of high importance. As described in the introduction, designers prioritise tasks that have an immediate impact on the project's success. The survey asked the subjects to rate the level of importance of 8 typical design activities that accesses or builds on information. Figure 5 shows the results are similar

216

1CED01-C586/472

between the students and the professionals and that there is no drastic variation of importance, which is possible an effect of the question's low resolution. Designers consider communication with co-workers and generating ideas of high importance, while considering recording design rationale of only medium importance.

Figure 5. Rating the importance level of several design information activities as indication of activities in which designers would prefer feedback.

Using the top designer pleasing results from design motivation and design activity importance, it appears a documentation tool that rewards documentation by providing feedback related to enhancing the designers ability to create the end product from the designer's correspondence between co-workers would encompass a powerful documentation incentive. However, it is important to remember the tools ultimate effectiveness not only depends on the potency of its incentives, but also on the lack of effort required to do documentation. The next section looks at the primary areas that documentation tools need to address so that incorporating incentives into the tool will have a net benefit to designers.

3.4 Primary Areas for Documentation Effort Reduction

Figure 6. Compares the occurrence of coded response to recording design rationale challenges to reveal the primary areas requiring documentation effort reduction.

1CED01-C586/472

217

In order to get a better understanding of the obstacles associated with documentation, the survey asked, "What do you feel is most challenging about recording your design rationale?" For these responses developing a coding scheme was more difficult than for the motivation responses, as indicated by the larger portion of responses unable to code. However, a significant 26.3% felt lack of time or time management was hindering capturing design rationale followed by undeveloped personal communication skills such as writing and drawing at 19.3%.

Summary and Conclusions

By building documentation incentives into the documentation tool, the tool's dependency on its environment can be attenuated. Understanding designers' pre-existing motivations to do design work may point to the kinds of feedback designers find rewarding when geared towards important design activities. This coupled with documentation effort reduction, may be the path to inventing effective documentation tools. Towards exploring this idea, the survey results established a list of designers' pre-existing motivation to do design work, and how common each motivation is between designers. It also determined designers' perspectives on the importance of design information activities and the major challenges to documenting design rationale. The next step towards incorporating incentives into documentation tools is prototyping several incentives developed from designers' most common pre-existing motivations and design activity importance. Following this, the next step is incorporating these incentives into an existing documentation tool that exhibits high levels of documentation effort reduction. Following the advancement of these steps, the prototype will be tested using both student and professional interactive focus groups. References [1] [2] Stewart, Thomas A., "Knowledge worth $1.25 billion", Fortune, 142 (13), 2000, p302 Grudin, Jonathan, "Why CSCW applications fail: Problems in the design and evaluation of organisational interfaces" , Proc. Conference on Computer-Supported Co-operative Work. ACM, 1988, pp. 85-93 De Long, David A., Liam, Fahey, "Diagnosing culture barriers to knowledge management", The Academy of Management Executive, 12 (4), 2000, p113-127 Hales, Crispin, Analysis of the engineering design process in an industrial context. 2nd Ed., Gants Hill Publications, England, 1991,p28-32 Chung, Kae H., Motivational Theories and Practices. GRID Inc., Columbus, Ohio, 1977

[3] [4] [5]

Tamsha Lloyd and Larry Leifer Stanford University Center for Design Research, Mechanical Engineering Department, Building560 Panama Mall, USA, Tel: 650.723.0159; 650.723.2062, Fax: 650.725.8475; 650.499.6481 E-mail: tanisha@cdr.stanford.edu; lcifer@cdr.stanford.edu , URLhttp://www-cdr.stanford.edu/CDR/cdr.html IMechE2001

2is

1CED01-C586/472

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

SCALING-UP DOMAIN KNOWLEDGE REPRESENTATION IN THE DEVELOPMENT OF KNOWLEDGE INTENSIVE CAD FOR PROACTIVE DESIGN FOR MANUFACTURE
X-T Yan, J Borg, and F Rehman Keywords: Knowledge based engineering, knowledge representation, proactive life-cycle design, knowledge based system scaling, design reuse

Introduction

Various product realisation tasks have been traditionally arranged to take place as a sequence of activities carried out by different groups of engineers. This obviously leads to a long product development lead-time and high cost. Research work under concurrent engineering theme has improved the product lead-time by promoting concurrent task execution of major tasks in product realisation. This has made significant contribution in reducing product leadtime and cost due to re-work caused by a lack of foresight of downstream implications of decisions and a lack of activity co-ordination among different engineers. This concurrent engineering philosophy has made important impacts on manufacturing companies in producing variety of products with shorter lead-time and lower cost. This approach largely focuses on promoting tasks being executed concurrently. Through such concurrent execution, tasks can overlap and the whole duration of a project hence significantly reduced. Recent research work has taken this thinking a step further by intensively promoting concurrent consideration of a product as well as product realisation systems at early design synthesis stage [1], This is based on the finding that 70% or more of a project total cost is committed at the design stage. It is only through intensive exploration of decision space that a engineer can be sure that an optimum design solution has been generated at the end of the design stage. This intensive exploration should be carried out for both solution space of the product itself and more importantly exploring the solution space of product realisation systems. Through such explorations, the influence of any product realisation systems on the product can be clearly predicated fully considered at the design stage. There is an increasing trend that a designer has to consider product life issues such as design for manufacturab;7/fy and "the number of 'Hides' is increasing [2]. To capture the essence of this research approach, a term of 'Design Synthesis for Multi-X (DFZX)' has been coined in this research to distinguish the approach taken in this project. Unlike more traditional design for multi-X, this approach brings the concept of using life-cycle knowledge to much early stage of design, e.g. at the synthesis process. This is aimed at eliminating the drawbacks of traditional afterdesign-analysis approaches. The results of these analyses are rather late as the design solution has already been generated. The analysis also has a segmented viewpoint as often each of these analyses is carried out from only one perspective e.g. design for manufacture etc. This research argues that through an intensive exploration of solutions spaces using product realisation process knowledge usually available downstream, a designer is better supported to make more informative design decisions, hence optimum solutions.

ICED 01-C5 86/664

219

From the viewpoint of knowledge intensive CAD system development, the successful further development of such systems has often been hindered by the following factors: 1) the knowledge representation method adopted for a particular domain knowledge might not be suitable for scaling-up the system into other domain knowledge representations; 2) increasing number of rules and new types of knowledge represented introduce new difficulties in integrating them with the existing rules and knowledge represented. These factors need to be analysed carefully to extend the scope of functionality of a knowledge intensive CAD (KICAD) system from one design domain to others. The overall project aim of this research is to develop a systematic and rigorous knowledgeintensive CAD approach to proactively supporting designers in generating "life-oriented" solutions through the exploration of design alternatives using life-cycle knowledge derived from concurrent modelling of the product being designed and life-cycle systems. To achieve this aim, a formalism of knowledge representation has been developed, and subsequently this has been applied and tested in a chosen application domain- thermoplastic. Scaling up the knowledge representation into other application domains is then required to evaluate the suitability of the formalism. Through such an extensive research and evaluation, the proactive design support approach based on KICAD can be further developed to incorporate wider application knowledge and to extend its scope of functionality. This paper discusses part of this much large project by focussing on the aspect of scaling up knowledge representation into sheet metal component design. Specifically the paper focuses on the concurrent modelling of sheet metal component design and its realisation systems and lessons learned through the project about scaling-up of KICAD system FORESEE [2],

Formalism and knowledge representation

To provide this research with a rigorous foundation, a semi-formal formalism has been established to ensure that the knowledge representation method derived initially for the research can also be extended easily to other application domains. The successful development and evaluation of the FORESEE system for thermoplastic component design has concluded that the proactive design synthesis approach implemented within the FORESEE prototype made designers aware of life-cycle consequences caused by an early design decision. These consequences could be intended or unintended, good or bad. This proactive design support encouraged designers to explore alternatives to maximise preferred consequences and minimise unintended consequences, resulting in desirable life-cycle design solutions. The first version of FORESEE system was developed based on the semi-formalism. Before extending the formalism to a new application domain, it is useful to summarise the formalism briefly in table 1. Examples of applications of the formalism both in thermoplastic domain as well as in sheet metal component design are given in the table to illustrate that how these notation symbols have been used in this on-going research project. The set of notation in table 1 has been initially defined to be generic for component design and they have been successfully used to model primarily thermoplastic component design. This was used to model life-cycle consequence knowledge found mainly for thermoplastic component design and the set of notation has prove to be effective in the development of first version of FORESEE system [1], This study extends these representation to sheet metal components and has also successfully scaled-up these notation symbols to a new domain. The

220

ICED01-C586/664

Table 1. Notation of formalism for knowledge representation

Symbol {}

aeb aA b a vb aeb a=>b

a-b a -* b

_,
a >b LaJ M F
Fa P

D{0} d H {0}
S <phase>i

Theoretic Modelling Meaning a set of design options available 'a' has properties 'b' 'a' and 'b' 'a' or 'b' 'a? is a subset of 'b' 'a' results in 'b', consequence 'b1 is caused by 'a', 'a' kind of 'b' 'a' part of 'b' 'not', negation of a statement 'a' is suitable for 'b' a class or a group of materials a material selected a form feature an assembly feature a technical process feature Decision proposal concerning a set of options {O} an explicit synthesis decision commitment a space of decision proposals life-phase 'i1

Example {[Aluminium] v [Copper] v [Stainless_steel]} [ABS] ^{ LNon-ConductiveJ ALNon-MagneticJ} LFerrousJ A l_2*thicknessj LNon-FerrousJ v LNon-MagneticJ Cutting-Operations c. Sheet-Metal-Operation (df:{P} = Injection Moulding) => (Manufacture Consequence,,, = 'Mould is required'). Punching - Sheet-Metal-Cutting-Operation ([P] = [Assembly]) ^<Phase>reaiiSation Material is not conductive, -, LConductiveJ [Cutting-Operation] > LFerrousJ A |_2*thicknessJ Material family is [Ferrous Materials] Material is Aluminium, M = Aluminium Design feature selected is a slot, F= Slot Assembly feature is snap-fit, [FJ= Snap-fit A process is milling, [P] = Milling Diameter value can be 1,2,3,4,5, D{ 1,2,3 ,4,5} Selected option, (de{ Snap-fit .. v .. v Screw} = snap-fit) => (MAC n i = 'Weak bond' S={what diameter? A what depth? } Life-cycle phase under consideration is manufacture, <phase>manufacture Referring to a process [P] = Turning

designate a chosen option of [] materials .nrnr,p<5 ptr* notation symbols associaTea'wim their relationships nave been lound to be consistent with thermoplastic components and can be scaled-up to model sheet metal components. However the elements for each manipulatablc design feature have to be re-generalised from the sheet metal components. This generalisation has proven to be easier with the defined notation.

Manufacturing and Assembly consequence modelling

3.1 Design decisions and their consequences

The design process is known to be decision intensive and typically there are thousands of design decisions, if not more, that need to be made during a product design. In mechanical aspect of product design, designers make decisions on manipulatable parameters of products from the following five categories: structure, form, material, dimensions, surface quality. In the process of making the above decisions, synthesis, analysis and evaluation always re-occur as key activities. Design decisions are also known to have implications or consequence, on down stream product realization activities, intended or unintended, good or bad [3]. This is known as a propagation effect that could span over multiple life-phases. More specifically these design decisions influence the performance of manufacturing and assembly in terms of measures

ICED 01 -C5 86/664

221

such as cost, quality and time. In this paper, this observation can be formally stated as that those design decisions give rise to Manufacturing and Assembly Consequences (MACs). Based on a study of design decision making models and extensive research case studies, two fundamentally different conditions have been identified that lead to the generation of MACs, namely: non-interacting consequences and interacting consequences [3]. A sheet metal component design solution is normally generated by the reuse of many manipulable primitive elements generalised from past designs. These chosen elements can be structured into a particular configuration suitable for the design requirements. This paper adopts the axiom that there exist many design primitive features (elements), termed in this paper as Product Design Elements (PDEs), that can be generalised and captured in a KICAD system. Examples of sheet metal PDEs include: slot, bend and notch as form features, fasteners, slots and welds as assembly features, aluminium as material features etc. In addition, a component is processed by many systems, termed in this paper Manufacturing/Assembly Tool Elements (MATEs), examples being bending tools, cup drawing machines etc. A taxonomy of both sheet metal component design features (PDEs) and process features (MATEs) have been derived from extensive study of existing sheet metal components and their manufacture/assembly systems.

3.2 Consequence elicitation for sheet metal component design

An extensive research has been conducted to generalise these PDEs and MATEs found in sheet metal component design. All together five punched form features, four bend form features, five blank form features and four cup-drawing form features have been identified. Associated with these PDEs, relating tooling features, machine features, and product property features have also been generalised. Detailed information can be viewed in [4]. Based on the identified PDEs and MATEs, it is possible to elicit decision consequence knowledge both in non-interacting and interacting forms. Collectively these form the basis of an enhanced KICAD system knowledge intensive base. In this research an extensive collection of consequence knowledge represented in the form of rules/methods have been generated. These design rules/guidelines can be used for proactive design synthesis of components. These rules are coupled with the consequences that are likely to occur during manufacture and assembly phases of product development due to violations. The classification of Form, Tooling and Machine features resulted into a Knowledge Model showing relationships between these features and consequences generated due to the

Figure 1 Consequence generation due to selection of attributes of features

222

ICED01-C586/664

specification of values of their attributes. A typical example of consequence generation due to the designer's decision of adding & form feature onto a sheet metal component is shown in figure 1.

3.3 Consequence generation during concurrent modelling

In order to help designers to foresee design decision consequences through the understanding of interactions of several life-cycle phases during design stage, this research argues that a multi-life-cycle phase modelling approach is desirable. Specifically this paper focuses on an important life-cycle phase - manufacturing/assembly and discusses the concurrent creation of product models and manufacturing and assembly models. This approach will not only support the study of design decision consequences during design decision makings, the approach also provides a framework to encourage designers to explore different design alternatives. Based on the understanding of Manufacturing/Assembly consequences (MACs), it is possible to elicit them extensively and convert MACs explicitly into a form which can be codified in a computer system for design re-use. By providing relevant MACs at an appropriate time during the design synthesis of the component model, it is feasible to build component manufacturing/assembly models at the same time that a component model is being built. This observation can lead to an important change of the design process model from traditional sequential design process followed by manufacture process design, to concurrent component and manufacturing design and modelling. This is the key to this new product development paradigm that this paper describes.

System architecture and implementation

Based on the above understanding, a 'Knowledge of Life-Cycle Consequences' (KICC) system architecture to sheet metal component 'Design Synthesis for Manufacture/Assembly' has been developed (Fig. 2). The extended KICAD system FORESEE comprises a knowledge base, working memory and inference engine. Knowledge base contains detailed representation of reusable synthesis PDEs and MATES features in its knowledge base. Working memory stores the information about the concurrent synthesis of component model during execution of software Figure 2 System architecture of extended FORESEE for sheet Inference engine is the metal component design

ICED 01 -C5 86/664

223

domain knowledge independent reasoning mechanism, containing rules/knowledge to reason with the information stored in the knowledge base. Knowledge base further consists of Inference knowledge, containing design consequence knowledge, and Reusable Elements Library. A set of tools has also been designed to facilitate the communication between a user and the Knowledge Base. These include: a Component Model Viewer to visualise the co-evolving model of component, a Form Feature Editor to add or modify form features, a Consequence Browser to see the consequence that would occur during product development caused by design decisions, an Alternative Design Solution Viewer in order to avoid bad consequence and a Tooling/Machine Parameter Viewer to see the design parameters required to manufacture a form feature. The architecture has been implemented using MS Visual C++ version 5 on Windows NT and a new prototype system has been coded to demonstrate the scaling-up of the FORESEE system. Section 5 provides some description of the use of the system through screen dumps.

Case Study of Sheet Metal Design

A case study is presented here to demonstrate the capabilities of the improved version of FORESEE, i.e. designing of sheet metal component through knowledge of life cycle consequences. The case study involves adding a form (bend) feature to a sheet metal component. The process of adding bend feature and getting corresponding consequences knowledge generated by FORESEE software is given below.

5.1 Defining component properties and adding bend feature

Consider, a designer wishes to add an Unequal Length Bend to a flat sheet metal as shown in Figure 3. The component properties as well as form feature properties are defined through the Form Feature Editor as shown in Figure 4.

5.2 Generation of Violations/Consequences and Alternative Design Solutions

Suppose that the minimum leg length (Unbent Length A) for the bend defined by the designer is 10mm. This information together with bending operation and thickness of sheet metal

Figure 3 Desired unequal length bend on a flat sheet metal component

Figure 4 Screen Capture of Foresee Dialog boxes to define Unequal Length Bend

224

ICED01-C586/664

Figure 5 Screen Capture of Violation(a), corresponding Consequence(b) and Alternative Design Solution/Suggestion by FORESEE (c ) triggers a piece of design decision consequence knowledge embedded in the knowledge base of the system. As this knowledge states that the minimum leg length must be greater than 2.5x thickness + Bending_Radius, i.e. 11.25 mm in this case, the desired leg length (10mm) specified by the designer violates this knowledge. Therefore a violation message "INSUFFICIENT MINIMUM LEG LENGTH" has been detected and displayed through Violation/Consequence Browser as shown in figure 5(a), which can be further expanded to the view details and explanations of violation as shown in figure 5(b). The inference engine then uses the consequence knowledge to reason the corresponding manufacturing consequence "DIFFICULT TO BEND" associated to this violation as shown in figure 5(b). This type of consequence awareness at early stage of design can help the designer to foresee the problems that are likely to occur at the later stages of product development. This has been shown in the above case that manufacturability of the component is not guaranteed using current bending machine to produce the bend feature specified by the designer. The extended FORESEE system not only detects inappropriate design decisions using the consequence knowledge, but also suggest possible remedies to avoid undesired consequence by generating automatically alternative design solutions/decisions. This has taken a step further to proactively support a designer to explore design alternatives for an optimum solution. This has also been demonstrated for the above design scenario. The extended version of FORESEE can exhibit this proactive support feature of suggesting alternative solutions in order to avoid "Difficult to Bend" situation during manufacturing of component. The suggested solutions for designer to explore are shown in figure 5( c ). This case study illustrates that the proactive design synthesis approach implemented in FORESEE helps designer in anticipating manufacture/assembly consequences of their design solutions. In addition, this research also revealed that this consequence knowledge could be further used to support manufacturing/assembly process design. Whilst a component model is being constructed during design synthesis, it is also possible and desirable to construct manufacturing process model and tooling model. Through the interplay of a sheet metal component model and its manufacture process and tooling models, a designer can gain better insight into the life-cycle design issues, be made aware of decision consequences to downstream activities, and more importantly be encouraged to explore design alternatives to produce optimum design solutions [4].

Discussion and conclusion

This research has investigate the feasibility of extending an approach using knowledge of consequence phenomenon modelling into another different engineering design domain - sheet metal component design. It intends to answer the following questions for scaling-up and

ICED 01 -C5 86/664

225

system extension. These include: "Is the original phenomenon model still valid for sheet metal component design?" "Is the knowledge classification still suitable for the new domain knowledge?" "How can a domain specific knowledge intensive CAD system become even more knowledge intensive in a wider scope?" "How can such a system be extended to become a true knowledge intensive engineering system?"[5] Many successful prototype systems derived from research projects often have a relatively narrow scope and shallow depth in terms of the contents of domain knowledge represented. The successful evaluation of the first version of FORESEE encouraged the authors to extend the approach and its associated modelling methods to a wider engineering application area. The key findings from the research include that: the original proposed life-cycle consequence phenomenon model is still valid and effective for the new domain -sheet metal component design and it proves that a well established model is very important for knowledge intensive CAD to be extended towards knowledge intensive engineering; the life-cycle consequence knowledge representation, based on the semi-formal formalism, employed in the research of the initial FORESEE system proved effective, though there is a need to adopt, restructure and regenerate the form features of sheet metal components, making it more rigorous and applicable for the new domains; the scaling-up of a knowledge intensive system proved to be more difficult than it was initially thought. There is still a need to elicit domain knowledge and life-cycle consequence knowledge in a new domain though this has proven to be easier than the original knowledge acquisition for the first domain - plastic component design, due to the formalism adopted.

References [1] Borg, J, Yan, X. T. and Juster, N. P. "Exploring decisions' influence on life-cycle performance to aid 'design for Multi-X'", Artificial Intelligence for Engineering Design, Analysis and Manufacturing: 1999, 13, 91-113. Brown, D. Which way to KIC? IF IP TC5 WG5.2, In International Conference on Knowledge Intensive CAD, Vol. 2, Carnegie Mellon University, Pittsburgh, PA, USA, Chapman & Hall, 1996, .pp. 291-295. Borg, J. and Yan X. T. "Design Decision Consequences: Key to 'Design For Multi-X ' Support". In Proceedings of 2nd International Symposium 'Tools and Methods For Concurrent Engineering', Manchester, UK, 1998, pp. 169-184. Rehman, F. "An investigation into the use of metal component manufacturing knowledge to support product and process design synthesis ", MSc Dissertation, CAD Centre, The University of Strathclyde, Glasgow, UK, September 2000. Tomiyama, Tetsuo, "A manufacturing Paradigm toward the 21st Century", Integrated Computer Aided Engineering, Vol. 4, pp. 54-61, 1997 John Wiley &Sons, Inc.

[2]

[3]

[4]

[5]

Dr. Xiu-Tian Yan, CAD Centre, Department of Design, Manufacture and Engineering Management, James Weir Building, University of Strathclyde, 75 Montrose Street, Glasgow Gl 1XJ, UK. Tel: +44141 548 2852, Fax: +441415527986 Email: x.t.yan@dmem.strath.ac.uk With Author 2001

226

ICED01-C586/664

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

RE-USING KNOWLEDGE - WHY, WHAT, AND WHERE J S Smith and A H B Duffy

Introduction

Characteristically designers do not 're-invent the wheel' every time a new design instance calls for one, their natural response is to glean from past experience and 're-use' previously acquired knowledge. Gao et al, [1] estimate that '90% of industrial design activity is based on variant design' and in such a redesign case '70% of the information is re-used from previous solutions' [2]. We see the concept of 're-using' as inherent within the natural process of design. The origins of formal design re-use are found in the realms of software engineering where re-use became a realistic solution to problems caused by 'increasing complexity and time-to-market pressures' [3]. Similarly, such pressure's on engineering companies has resulted in an increased focus on support for 'formalised re-use'. Previously the 're-use' focus has centred on specific and/or standard parts, more recently however, '[standard components] are being developed...to enable both the re-use of the part and the experience associated with that part' [4]. This notion is further extended by Finger [5] who states that 'designers may re-use a prior design in it's entirety, ...may re-use an existing shape for a different function, or may re-use a feature from another design'. Reinforcing this notion we currently consider 're-use' to reflect the utilisation of any knowledge gained from a design activity and not just past designs of artefacts. Our research concerns the improvement of formal 're-use' support and as such we have identified a need to gain a better understanding of how design knowledge can be utilised to support 're-use'. Thus, we discuss the requirements of successful 're-use' and attempt to ascertain within this skeleton: what knowledge can be re-used; how to maximise its' applicability; and where and when it can be utilised in new design?

Why formalise design re-use

To stimulate both research and investment towards increased support for the 'formal re-use' concept it is essential to gain some appreciation of the potential advantages. The following provides evidence to verify the potential of improved 're-use' mechanisms.

2.1 The benefits

It is interesting, initially, to consider the current re-use benefits achieved in the field of software design, where formalised 're-use' originated, as a relatively more mature 're-use' research area. For instance, a recent cost model developed for the software industry for Synopsis Inc. (Figure 1) highlights the increasing costs of chip design and the widening gap

ICED01-C586/048

227

between design costs utilising 'formal' re-use and current practice. The chart shows that chip designers who fail to take advantage of 'formal design re-use' practices face 'unsustainable cost increases, of up to 64 times higher' [6].

Figure 1 Who Can Afford a $193 Million Chip? [6]

Time, cost, quality and performance were amongst the main benefits analysed in a study in the engineering design sector [7]. The study concluded that the potential benefits to an industrial company, of applying an overall re-use approach, far exceeded the benefits they currently received from relying on designers' natural inclination to re-use. Figure 2 summarises the benefits analysis finding.

Figure 2 Current and Foreseen Overall Metric Benefits [7]

We can see that the first column in each category (time, cost, quality and performance), shows the benefits received from current 'ad-hoc' re-use practices. These provide greatest benefit to time and performance whilst the costs benefits are almost half at only 6%. The second column in each category indicates the foreseen benefits of a formal approach to 'design re-use' which can be expected to provide overall benefits to time, cost, quality and performance in the region of 20% to 28%. For instance, this can be translated into an improvement in terms of cost benefits, over current practice, of around 360%. Thus, it can be argued that there is significant value in re-using knowledge and experience related to existing designs to support future design. The study substantiates the need for formalised approaches, methodologies and systems, in order to achieve the considerable potential benefits shown to be available from a formalised approach to re-use.

2.2 A formal model

Like others, Altmeyer and Schurmann [8] query as to whether 'generic reuse techniques' are possible and additionally how we can 'identify [re-use] mechanisms which are typical for design but independent of a specific design system?'. Similarly, in addressing this issue, there seems to be only one such generalised 're-use' model, namely, the 'design re-use process model' [9]. Other reviewed models were, as suspected by [8], either highly dependant on the individual system/approach or alternatively were paradigms of Case Based Reasoning (CBR). CBR [10] is a research interest in the field of 'design re-use', however, the assumption of the

228

ICED01-C586/048

existence of a large base of past design cases; the applicability of cases in their entirety, and its limited focus on mainly representation and recall issues, negate this as comprehensive model of 're-use'.

2.3 Knowledge issues in providing 'formal support'

Weighted against the potential benefits is the principle that a stored design '99% right for a given task, often takes much more than 1% of the effort needed to create the design in the first place to patch it to fit, cancelling so much of the advantage of reusing it that it may be easier to design from scratch' [11]. Thus, we identify fundamental issues in providing support for a 're-use' approach: (i) modelling and managing, even for a relatively simple artefact, the complex and rich design related knowledge, and (ii) providing solutions to the problems of partially re-using previous design solutions and their associated knowledge to effectively satisfy new design requirements. Accordingly, to obtain the maximum benefits of formal 'reuse' requires that we optimise support for this rich and complex knowledge resource, appreciate the source, nature, and growth of design knowledge, and successfully manage knowledge acquisition, maintenance and utilisation for 're-use'. Thus, supporting re-use requires that we can ascertain: what knowledge can be re-used; how it can be maintained to maximise its applicability; and where and when it can be utilised in new design.

What can we re-use?

Previously design knowledge has been referred to as complex [ 1 ] but what do we understand by the term complex, and what are the implications of this for the re-use of design knowledge? Firstly, we must consider the factors contributing to design knowledge complexity and secondly how these effect it's ability to be re-used. The notion of complexity is one topic that has received great attention, from mathematicians, scientists, and engineers alike, due to a lack of common definition and concrete theories. Duffy defines the factors influencing complexity, and their associated issues, through the 'design complexity map" [12].

Figure 3 - Design Complexity Map [12]

Thus we can view complexity in design in such diverse factors as the artefact being designed, the design activity itself, the actors involved, the decision making process, the aspects impinging on the design, and knowledge and sources used and generated. Moreover, the issues affecting each of these factors further compound complexity. We can now appreciate that even the simplest artefact is associated with a complex array of factors, which shape the activity of design and consequently the final artefact definition, and result in a vast

ICED01-C586/048

229

accumulation of related design knowledge. The final artefact definition is dependent on: amongst others, the company organisation; the type of design; the chosen design process, designers, and tools; and external factors out-with the designers control [12]. Thus, this presents a complex problem in terms of modelling knowledge for 're-use'. A problem further amplified by the differences in terms of characteristics, types, sources, forms and origins of design related knowledge. If we now consider that formal support for 'design for re-use' relies on an ability to identify, extract and explicitly represent re-usable fragments of knowledge during design itself we gain an perception of the difficulties of supporting such complex design knowledge for 'exploration', and subsequent utilisation in 'design by re-use'. To further complicate matters, design related knowledge can be considered from many viewpoints such as; functional, structural, and behavioural [12], While Brice and Johns [13], Finger [5], and Mostow [11], also emphasise the importance of knowledge related to the 'why' and 'when' of decision making, known as the Rationale and History. Brice and Johns [13] conclude that 'constructive use of design rationale will become an integral part of the design process'. 'Design by re-use' relies on the availability of appropriate knowledge sources. Thus, to achieve this we require a suitable knowledge modelling mechanism to support 'design for reuse' which would require to capture knowledge from differing 'sources' and 'viewpoints' and represent their evolution through the design activity. Thus, formal knowledge modelling mechanisms which adequately support 'design for re-use' must be capable of defining 'knowledge elements' while capturing the 'relationships' between these both within and across different 'sources' and 'viewpoints,' and the 'behaviour' of these relations as the artefact definition evolves. This would facilitate a deep 'understanding' as to how and why design knowledge had developed into the final artefact definition and provide the designer with a greater knowledge resource to utilise in 'domain exploration' and support further 'design by re-use'. Despite our increasing understanding of the utility of consistent capture of 'design knowledge' throughout the design activity, 'typically the only formal documentation is the final set of drawings' [5]. Additionally, current design tools have the effect, on the practice of engineering design, of emphasising 'those parts of the process that were well understood and/or easily systematised (e.g detailed design, analysis, machine path planning), while minimising those parts that were less well understood (e.g, problem definition, synthesis and conceptual design)'[5]. Thus, without a shift in working practice/culture it remains difficult to facilitate consistent knowledge capture as the earlier design phases, where more general, abstract knowledge is generated, are not adequately supported. The importance of supporting earlier phases is illustrated when we consider that at the end of the conceptual phase approximately 80% of the lifecycle costs are already committed. Thus, non-capture would negate many of the cost benefits of re-use. Furthermore, documentation generated in current practice are generally based on a low level of abstraction e.g. geometry, tolerance, surface finish, manufacturing requirements. Such formal documentation leaves little or no scope for representing knowledge related to the rationale, history, or product knowledge relating to concept principles and dynamic process knowledge learnt through experience. This contributes to the difficulty of managing the complexity of product knowledge in that a vast proportion of the quantity of generated knowledge related to other complexity factors are not captured explicitly and thus cannot be re-used. Hence, there is a limited range of available knowledge related to relationships and their behaviours at a more abstract level of design. Consequently our understanding of how knowledge elements relating to function, behaviour and solution concepts, decision making, the design activity, actors and aspects and design alternatives have contributed to the overall design is restricted. The result of this in a 're-use'

230

ICED01-C586/048

scenario is to force designers to think in terms of design specifics, with limited applicability to the earlier synthesis stages of design, and restricts 're-use' principally to support detailed design (standardised parts, manufacturing methods, etc.). In addition, it presents problems when attempting to partially re-use a design solution, or its associated knowledge. The designer has no understanding of the 'evolution' of the designed artefact, no knowledge of the function, solution, and mechanism concepts realised by the artefacts components and/or possible alternatives to these, on which to base a decision as to potential value of 're-using' individual concepts/parts/subsystems/ in new scenarios. Thus, the potential benefits of re-use (see Figure 1 and 2) cannot be fully realised due to the incomplete knowledge content of the available sources, which in turn, restricts its 're-use' capabilities. It can be argued, therefore, that knowledge from the earlier, more abstract, stages of design (function, behaviour, solution concepts) and the 'how' and 'why' (rationale) of a designed artefact are key elements to the 're-use' approach. Capturing such high level knowledge can facilitate a 're-use' approach applicable far earlier in the design process.

Utilising knowledge in design re-use

Having established a case for the 're-use of design knowledge and identified the need to support and manage re-usable knowledge sources from the inception of a design activity we must now consider its applicability to new situations. Mostow, et al [11] debate whether re-using a previous design can be justified in terms of the additional effort required to make it 'fit'. Unlike the direct re-use of code, adders, modules and microprocessors in the field of software engineering, as engineering design deals 'with more abstract concepts' [14]. However, Mostow, et al [11] further maintain that despite the difficulties of partial re-use, human designers do 'modify the structure of a design to fit a new application' but concede that 'this process tends to require considerable expertise'. Evidently, it is not always possible to re-use a previous design in it's entirety and modifying a design to fit can involve expertise beyond the scope of explicitly available design knowledge. However, as the utilisation of previously acquired design knowledge in new design is central to the success of a re-use approach there is a need to overcome such problems by supporting and maintaining knowledge acquired through design experience (explicit and implicit) to support its application to, as opposed to its regurgitation in design. As the designer is seen to adapt previous solutions to solve a new problem by learning from experience, an effective 're-use' approach must encompass elements of this 'learning' process to extend the approach's ability to utilise design knowledge and support re-use of partial solutions [11]. Here, (as shown in Figure 5) we consider learning to be a process of acquiring new knowledge, the modification of existing knowledge and the generation of new knowledge. Duffy [15] states that 'learning helps to maintain experiential knowledge', which represents one of the most powerful resources a designer possesses. Such maintenance of experiential design knowledge, through abstraction from the specific to general, supports the dynamic nature of knowledge and prevents knowledge related to design experiences from becoming static and obsolete. Such activities as 'abstraction and generalisation' extend the utilisation capabilities of knowledge in a 'design by re-use' process as they 'promote the flexibility of experiences by removing highly specific details and generating more generally applicable knowledge'. Thus, the process of learning: the acquisition, generation and modification of

ICED01-C586/048

231

knowledge, alleviates some of the difficulties associated with the application of knowledge from 'a design that is not 100% 'right' to a new situation'.

Figure 4 -The Learning Activities [15]

Where - the applicability of knowledge re-use

Having established 'design re-use' as an approach concerned with the provision of support for the capture, management and subsequent utilisation of design knowledge, gained from previous experience, to further new design. Now we consider the applicability of such an approach within the field of design itself.

5.1 In the design process

Many re-use models or paradigms [1,16,17,18,19] consider 're-use' as an approach solely concerned with aiding new design by re-using past design solutions. However, the concept can be further extended to include not only this phenomena of 'designing by re-use' but also that of 'designing for re-use', whereby the design process and potential solutions are specifically managed and created to promote their future re-use. Indeed an industry based brainstorming program, [20] highlighted the need for capturing design information into the design re-use system whilst a design is being carried out. Addressing this 'design re-use process model' considers re-use as a total process which, with the support of well developed tools and methods, can encompass all phases of the design life cycle. Thus, a comprehensive approach to 'design re-use' should emphasise support, management and utilisation of design knowledge prior, during and after the completion of a design activity.

5.2 For different design types

Research into why designers re-use experiential knowledge has highlighted the main issues as: an avoidance of previous design faults and unnecessary re-invention; duplication of design success; and the use of known and proven characteristics [9]. This may suggest that re-use is relevant only to variant (repeat order) or adaptive (evolutionary) design as these issues are readily equated to the repetition, improvement and enhancement of an already existing design. At first glance, the application of re-use to variant and evolutionary design is far more apparent than to that of original (innovative) design. However, as 'competitive advantage is now obtained by innovation and creation of knowledge rather than access to financial or material capital' [21] it is important to determine the capabilities of the 're-use' in the 'original' design environment in a bid to optimise the impact of 're-use' benefits in design. Innovation is deemed to have occurred when either tacit (the collection of data, rules, which lie beyond the realms of explicit knowledge) or explicit knowledge (that which is readily

232

ICED01-C586/048

accessible, written down, in computers, etc.) is converted to gain additional explicit knowledge, not previously available [21]. Thus, innovation in the design process can be considered as instances where 'new variables are introduced into the design process' and 'the state space is expanded' [22]. Thus, the conflict between re-use and innovation arises from the perception of re-use as merely an approach to support and maintain already existing knowledge where innovation requires that new knowledge be created and/or added to the design process. For example, the perception of re-use as a facilitator of negative design fixation (a phenomena whereby designers re-use features to which they are regularly exposed) i.e. complacency, re-use of 'bad' design solutions, lack of technology transfer. The applicability of re-use to original (innovative) design is better appreciated when, as here, re-use is considered as a process capable of supporting existing knowledge while permitting abstraction and generalisation of this knowledge to generate or modify knowledge. Thus, the processes is synonymous with knowledge maintenance can not only prevent its stagnation or obsolescence, increase it's applicability to new design, but also support the 'utilisation' of reusable knowledge in original design environments. Further effective generalisation of design knowledge can increase applicability for design not only within a single domain but due to the removal of 'case and domain specific' knowledge it can also be utilised to effectively support the re-use of knowledge across distinct domains.

Conclusion

In answer to the question: 'design knowledge re-use' -why what and where? We have shown that there is significant value in capturing and re-using the knowledge and experience of current and past designs. In addition, we acknowledge that a greater understanding of the role of knowledge in 're-use' is required. We establish within the spectrum of a comprehensive reuse model, that the knowledge generated throughout the evolution of a design requires a consistent approach to its capture, modelling and structuring. However, it has also been shown that for effective 'exploration' and 're-use', such knowledge must be maintained to prevent its stagnation and improve its applicability. Further, learning from design knowledge by generalising, removing the specifics of a design case and/or aspects of the domain, is shown to generate a source of knowledge with greater applicability within and across domains. In addition, this generalisation supports partial re-use of past cases (and their associated knowledge), and can facilitate positive 'design fixation'. Such 'formally' supported design knowledge' extends the 're-use' approach to both earlier stages in the design process and to design environments with more original content than re-design cases, to which current 're-use' practice is predominantly limited. References [1] Gao, Y., Zeid, I. and Bardasz T., "Characteristics of an Effective Design Plan to Support Re-use in Case-based Mechanical Design", Knowledge Based Systems, Vol.10, 1998, p337-350. Khadilkar, D.V. and Stauffer, L.A., "An Experimental Evaluation of Design Information Reuse During Conceptual Design", Journal of Engineering Design, Vol.7, No.4, 1996, p. 331-339. Jones, M.E., "Reusing Integrated Circuit Designs", Computer Design, July, 1995 Culley, S.J., "Design Re-use of Standard Parts", Keynote Paper, in Proceedings of Design Reuse - Engineering Design Conference, Brunei University, UK, 1998

[2]

[3] [4]

ICED 01 -C586/048

233

[5] [6] [7] [8] [9] [10] [11] [12]

Finger, S., "Design Reuse and Design Research", Keynote Paper, in Proceedings of Design Reuse - Engineering Design Conference, Brunei University, London, 1998. Synopsys Inc., "Who can Afford a $193 Million Chip?", Synopsys Design Reuse Cost Model" 1999. Duffy, A.H.B., and Ferns, A.F., "An Analysis of Design Reuse Benefits," in Proceedings of the International Conference on Engineering Design, Munich, 1999. Altmeyer, J., and Schurmann, B., "On Design Formalisation and Retrieval of Reuse Candidates", Artificial Intelligence in Design, Kluwer Academic Publishers, 1996. Duffy, S.M., Duffy A.H.B., and MacCallum, K.J., "A Design Reuse Model", in Proceedings of the International Conference On Engineering Design, Praha, 1995. Maher, M.L., Garza, A.G., "Case-Based Reasoning in Design", IEEE Expert, March/April, Vol.12, No.2, p34-41, 1997. Mostow, J., Barley, M., and Weinrich, T., "Automated Reuse of Design Plans", in Artificial Intelligence in Engineering Design, p. 2-15, 1993. Duffy, S.M., "The Design Coordination Framework and the Design Complexity Map", Integrated Production Systems Research Seminar, Fugsl0centret, Fugsl0, 3-5th April, 1995. Brice, A., and Johns, B., "Improving Process Design by Improving the Design Process, A DRAMA white paper, QuantiSci, 1998. MacCallum, K.J., Duffy, A.H.B., Donaldson, I.A., Duffy, S.M., and O'Donnell F.J., "Design Reuse - Design Concepts in New Engineering Concepts", CAD centre, Strathclyde University, UK, 1995. Duffy, A.H.B., "The "What" and "How" of Learning in Design", IEEE Expert, May/June, p. 71-76, 1997. Deneux, D., and Wang, X.H., "A Knowledge Model for Functional Re-design", Engineering Applications of Artificial Intelligence, Vol. 13, p. 85-98, 2000. Altmeyer, J., and Noll B., "RODEO - Reuse of Design Objects", p. 1-2, 1998. Henninger, S., "Accelerating the Successful Reuse of Problem Solving Knowledge Through the Domain Lifecycle", in 4th International Conference on Software Reuse, IEEE, 1996: Fothergill, P., Lacunza, J.A., and Arana, I., "DEKLARE: A Methodological Approach to RE-DESIGN", Aberdeen University, Copreci S. Coop. Ltd: Dept of Computing Science, Aberdeen University 1994. Shanin, T.M.M., Andrews, P.T.J., and Sivaloganathan S., "A Design Reuse System, in Proceedings of Design Reuse - Engineering Design Conference, Brunei University, UK, 1998 Preiss, K., "Modelling of Knowledge Flows and their Impact" Journal of Knowledge Management, Vol.3, No.l, p. 36-46. 1999. Gero, J.S., and Maher M.L., "Theoretical Requirements for Creative Design by Analogy", Colorado State University Fort Collins, 1990.

[13] [14]

[15] [16] [17] [18]

[19]

[20]

[21] [22]

Joanne S Smith CAD Centre, DMEM Department, University of Strathclyde, M209, James Weir Building, 75 Montrose Street, Glasgow, Gl 1XJ Scotland, UK Tel: +44 (0)141 548 3020 , Fax: +44 (0) 552 0557, E-mail:jo@cad.strath.ac.uk , URL - www.cad.strath.ac.uk Joanne S Smith 2001

234

ICED01-C586/048

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DOCUMENTATION AND EVALUATION IN EARLY STAGES OF THE PRODUCT DEVELOPMENT PROCESS

L Schwankl Keywords: Design information management, information representation, systematic product development.

Introduction

For developing innovative products for new markets in the context of high demanding technology development projects, often different creative methods are used by development teams. In this way, the teams are able to create a high number of concept ideas within a short period of time. Due to the exchange of team members, often practiced in development projects, it is very difficult to keep an overview of which ideas are already known and which are perfectly new. In the context of different development projects [3,4] at the Institute of Product Development at the Technische Universitat Miinchen these problems were detected and important factors for innovative product development processes were identified.

Figure 1: Important factors for innovative product development processes

For supporting the documentation during the development processes, a form for the improved, more comprehensible documentation of results from creative sessions has been developed. In a second step, the essential structure of this form has been modelled in a data base, which permits archiving concepts and a computer aided evaluation. The main problem is, if the ideas are not documented in a practical manner, that they are lost. For supporting the information generating process, there are several methods and different tools, to analyse product properties in the early stages of the development process. Relevant parameters, which were identified during evaluation, are used as the input values for the

ICED 01 -C586/331

235

selection of suitable analysis methods. For this, we have developed a computer based Method Selection System. By the application of different analysis methods in the early stages [1] of the product development process, relevant information will be compiled, which is the crucial importance for further development. Many of the concept ideas sketched in creative meetings are usually no longer comprehensible after a short period of time. Neither the relevant components were indicated nor the function was described clearly. Often an exact description of the function takes place only in verbal form, as started in the later discussion. It is very difficult for most of the team members to interpret sketches correctly a few days after, and it is virtually impossible for persons to understand, who have not participate in the creative meeting. In such creative sessions, ideas are often born, which are not directly relevant to the questions discussed. Nevertheless, these ideas could sometimes be valuable for following steps in the project, other projects, or other project teams, who may be interested in them. This was noticed several times in the context of different development projects.

Documentation in early stages

In the early stages of product development processes, important decisions [2] are made and a quantity of information is collected, which is useful, and often urgently necessary for the whole development process. For this reason different tools supporting the documentation during the whole process have been developed at the Institute of Product Development. To find new solutions, we use several innovation stimulating methods [5], e.g. brainstorming, the method 6-3-5, and parts of the TRIZ (Theory of Inventive Problem Solving) method. Also we use catalogues with physical effects and different check lists. With such methods you can produce a great number of new ideas with a high quality in a short time. In this chapter, the form for supporting creative meetings (e.g. brainstorming meeting) is discussed.

2.1 Form
The form for supporting the documentation has a great number of different areas (figure 1), in which you can fill in either text or sketches; the most important of them will be described next: Sketching area: Here, the concepts can be sketched in the usual way. Relevant components should be marked and named. The size of this area is equivalent to the format DIN A4. Advantages/disadvantages area: These two areas allow users to document pros and cons, which are already noticeable to them during the creation of the sketches. Using this forms, disadvantages were often realized, such as complexity, a great number of components or the difficulty of assembly. Problems ("to be clarified") area: If the user notices some problems while sketching his concept ideas, he can enter this into this area. In the later discussion, the critical questions can be clarified together or the necessary analyses can be initiated (see also selection process of suitable methods for early evaluation).

236

1CED01-C586/331

Description area: This field is provided for description of important parts and the background information according to the ideas. Having common ground with the sketches, understanding of the idea should be no problem. We recognised that you can find out many interesting aspects belonging to the idea during the description (writing down) of its main functions. Text field: The text field, as known from manufacturing drawings, is used for organisational information only, e.g. name of project and name of creator, and includes the summarised results of the evaluation process. You should enter the important things, you have found out during the discussion after the brainstorming, on the form. So it is assured that you have documented all the information which could be important at any time.

Figure 2: From for design concepts Evaluation form (on reverse side):

On the reverse side of the form, an additional evaluation array is set out. Using this, the evaluation and first pre-selection can be executed. Apart from given evaluation criteria [3], there are also fields for project-specific criteria intended. The evaluation result is transferred afterwards to the front of the form, so it becomes apparent at first sight. The form is designed as a DIN A3 page, the sketching area as a DIN A4 page. The users are also encouraged by the design of the form to use all the individual areas. Thus, on the one hand the clarity increases enormously, on the other hand, the quantity of documented

ICED 01-C586/331

237

information increases, too. Necessarily modifications can be done in an easy way. For example, you can add additional fields (e.g. estimation of costs, duration).

2.2 Database
The form has already been transferred into a computer based tool, based on Microsoft ACCESS (figure 3). All areas of the form were implemented as input fields or logical elements (for yes/no distinction). Within the sketching area, it is possible to merge scans or sketches from different drawing software. Supported by a query-reply system, the data base can be searched for different criteria, e.g. solutions belonging to a certain category. Beside this, other different output formats were implemented. Apart from a total summary, which contains all available data, still further output formats with less information can be selected. So the user can get all the information, which is important for him at the moment. Information, which is created later in the development process, e.g. during analysing the concepts, should also be entered into the database for further handling. So you can fastly generate an extensive information storage, which is very helpful as well for single developers as for the whole company.

Figure 3: Database for concept ideas

Early analysis of product properties

The next step after generating ideas is to analyse and evaluate them in the early stages of the process. There you have much more possibilities to change different parameters as later in the

238

ICED 01 -C586/331

process. Even in complex development projects, it is very important to support this early stages. In order to reduce the high risk, on the one hand it is necessary to collect as many information as possible in the early stages of the product development process. On the other hand, you must analyse the important product properties with suitable methods, that will need time and money. So you can get a complete understanding of the task and make the right decisions very early and safe time in the following steps.

Figure 4: Effort and success in context of new technology

Figure 4 shows clearly the significance of complex technology development. The probability of success relying on products which are developed for new markets and simultaneously base on new technologies is only 5 %. So these products are a high risk for the company, because the effort for their development is normally 15 times higher than developing standard products (see figure 4). Using suitable tools and methods you can reduce this risk and increase the probability of success.

3.1 Selection process of suitable methods for early evaluation

In order to prove the suitability of the different concepts in the early phases of the development process, different methods and tools are used. For example testing components to examine relevant product properties. For this we use the development lab of the institute, which contains different measuring and testing facilities. So we will get a few verified concepts at the end of a design project which will fulfill customer's requirements. The application of the form and data base has shown that most of the questions (i.e. the need for information), which have to be clarified before the evaluation process can start, are repetitive standard questions (e.g. relating to assembly, fabrication). A second criterion is whether the response should be qualitative or quantitative. These standard questions and criteria are used as input values for the Method Selection System.

1CED01-C586/331

239

Based on the combination of the relevant questions (e.g. according to function, to reliability) and criteria values, methods are suggested which appear suitable for clarifying [1] the task in early stages of product development process. The user receives a short description and important hints using the methods, notes on training and application [2], and an estimation of the expenditure of time.

3.2 Visualization of evaluation results

In order to find out better concepts for the further handling, the next step is an evaluation and a pre-selection on the basis of different criteria. For this, as an example portfolio diagrams (shown in figure 5) can be used. Concepts with similar attributes (for example: the relevance to the customer, cost, time to market) are in the same area of the diagram. Then you can combine them to groups for common handling in the following steps of the process. In addition to that, the portfolio helps you to identify a proper ranking for analysing the ideas. At the beginning, you look intensely to solutions, which fulfil all the requirements in the best way and which can be realised in a short period of time.

Figure 5: different solutions with similar properties

Implementation and verification

The form for documenting concept ideas during creative sessions has already been used in several projects, such as the development of electromagnetic brake-systems, an testing engine and seat-systems for cars and buses. In this projects we could increase the quality of the sketches and the quantity of information by using the form.

240

ICED 01 -C586/331

After discussion and the first evaluation, the concept ideas were transferred into the data base. An extensive query-reply system enables the handling and filtering of the data according to various criteria, which is very useful for further handling. The biggest advantage of this data base is its simple structure, which allows user defined modifications if required in a short time. So you have a tool, you can adjust to your project and to the general conditions. You can for example add additional fields or define new request very quickly. The Method Selection System also got the acceptance of the users, because this tool makes the information available, the user is looking for in this stage of the process. In a project with a major manufacturer of magnetic brake systems we used some of this tools. After a few creativity meetings, we had generated about 300 different ideas using the form for documentation and stored them in our data base. The implemented output formats supported the further handling of the ideas, like the pre-evaluation process and the early analysis of important product properties. With the help of the Method Selection System we have chosen qualified methods in a short period of time. At the end, we had numerous solutions for new, innovative and patentable brake systems.

Future work

In the next step, the application of electronic sketch boards will be examined. The team members will sketch their concept ideas directly on small sketch boards [figure 6], which are connected to the computer. Thus, the data are available in the computer which avoids transferring the sketches with a scanner or drafting them again with drafting software. The users can enter available information directly into specific arrays of the data base with a keyboard. In further case studies the acceptance of this procedure and the impact on quality of the generated ideas must be examined.

Figure 6: Sketch board

Beside this small boards, you can use bigger one for visualisation in front of the whole group. Therefore, all team members can see the same concept and discuss it. Information, which is generated during this discussion (often modifications are done or other versions of this concepts are created) can be promptly entered into the database using the board.

1CED01-C586/331

241

The tools which are discussed here can be used within globally distributed development processes for example during video conferences. All members have access to the sketched ideas, they can have a look on them on their own display and modify them. So it is guaranteed that all members have the same information at the same time.

Conclusion

The form and the data base have already been used successfully in several development projects. Using the form with given areas, more information is demanded from the person who is sketching the concept than by the use of simple sketching paper. A further advantage is that the team members are motivated to document any further ideas raised in the discussion. So the ensuing evaluation and selection processes should be simplified. By formulating critical questions, identifying relevant parameters and selecting an analysis procedure in common, the methodical evaluation process becomes easier. Apart from archiving the ideas, there are also different visualization possibilities and a simple data exchange between various software programmes. By consistent documentation with the tools presented here an extensive knowledge and information base can be established in a short period. Employees, in particular the new employees, can get an overview of all projects done at the company and also use this data base to suggest new creative concepts. References:
[1] [2] [3] Bernard, R., "Early Evaluation of Product Properties within the Integrated Product Development". Shaker Verlag: Aachen 1999. Ehrlenspiel, K., "Integrierte Produktentwicklung". Miinchen, Wien: Carl Hanser Verlag 1995. Gierhardt, H. et al., "24h-Entwicklung - Bin Grundlagenprojekt in der Antriebsentwicklung". Entwicklung im Karosseriebau.l 1./12. Mai Hamburg, vdi Bericht 1543 Schwankl, L.; Pache, M., "Collaboration between University and Industry in Engineering Design". Co-Designing 2000 Malorny, Ch.; Schwarz, W.; Backerra, H., ..Die sieben Kreativitatswerkzeuge K7. Kreative Prozesse anstoSen. Innovationen fordern". Miinchen: Hanser Verlag 1997.

[4] [5]

Ludwig Schwankl Technische Universitat Miinchen, Institute of Product Development, D-85747 Garching, Germany, Phone: 449 89 289-15147, Fax: +49 89 289-15144, E-mail: schwankl@pe.mw.tum.de, http://www.pe.mw.tum.de IMechE2001

242

ICED01-C586/331

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

MAPPING EXPERIENCE - LEARNING FROM EXPERIENCE OF PEERS THROUGH SOCIO-TECHNICAL INTERACTIONS

T Liang, D G Bell, and L J Leifer Keywords: knowledge and information management, design reuse, lessons learned systems

Introduction

In project-oriented product development communities, the ability for designers to learn from the experience of others across projects enables them to build upon and subsequently advance the performance-baseline previously established by their peers [1]. This not only applies to experience associated with particular products, but also with particular processes. In fact, learning from other's experience associated with processes has been identified as a critical factor for product development firms to maintain a competitive advantage [2]. To better support this practice, many firms have implemented technical systems such as "best practice" and "lessons learned" databases in order to support the capture and re-use of experience across project teams. While such systems have shown demonstrable success in contexts such as field service [3], they have not shown comparable success in product development. Studies of such systems in product development indicate that purely technical approaches have inherent limitations, and that social issues are an important contributor to effective learning [4, 5]. This study presents empirical findings on learning from the experiences of peers in product development, with particular focus on learning about product development processes through social interactions. This study identifies features of peer-to-peer interactions that are significant for effective learning, and outlines implications for the design of related social-technical systems.

Research settings and methods

The setting of this study was the product development organization of a large multi-national firm, which develops office machines and uses an enterprise-wide product development process. The organization has many product programs working in various phases of the firm's product development process, and one of the prescribed elements of the formal process that teams struggle with is program planning for technology readiness. At the beginning of each phase, each product program must have a detailed program plan that estimates the time and resources necessary to complete the upcoming phase, and includes a detailed schedule for tasks and deliverables. At the end of each phase, the program's progress is judged against the details of their program plan. Teams struggle with making plans that are simultaneously compelling and achievable. This study involved an intervention, where peers from three relatively similar product programs interacted with the goal of helping one of the programs learn from the experience of the other two with regard to program planning for technology readiness. The intervention lasted for three and a half hours, and involved a total of nine participants. Two of the three participants from the peer programs were the technical leaders of their respective product programs. The learning team consisted of the program leader and people from various

ICED01-C586/478

243

functions such as product architecture and product quality. The learning program team decided the topic of the event and selected the peer programs from which to invite the peers. This intervention was videotaped and later analyzed. As a result of the analysis, several significant social features of interaction were observed, and a descriptive model of the interactions was constructed. These observations, in turn, helped produce several key requirements for the design of future systems intended to support learning from the experience of peers in product development. This study was guided by the following two questions: 1. What are the significant social features of interaction that facilitate learning from the experience of peers in product development? 2. What are the sotio-technical design implications of such features for learning from the experience of peers in product development?

2.1 Interaction analysis methodology

An interaction analysis methodology was used to analyze the video and audio record of the interactions that occurred among participants. This method was adapted from that outlined by Jordan and Henderson [6], which includes group analysis of video records in conjunction with ethnographic fieldwork. This method relies on a combination of participant observation, in-situ interviewing, historical reconstruction, and analysis of artifacts, documents, and networks for providing the framing context. In this study, multiple cycles of interaction analysis were performed. In each cycle the observations from the previous cycle was further tested, evaluated, and refined. Specifically, the analysis cycle employed in this study consisted of the following four steps: 1) identifying conversational threads, 2) interpreting interactions, 3) characterizing features of interactions, and 4) testing generality of characterization. These four steps are outlined below. Identifying conversational threads A transcript of the event was first analyzed for conversational threads. The purpose was to obtain an overall understanding of the topics being discussed in the event, and to aid further analysis by dividing the transcript into manageable segments. An expected side benefit was that the process of identifying threads would also help to identify the most significant segments of the event. As in our everyday conversations, the threads of conversation intertwine with each other. Identification of the threads was done with great reliance on a thorough knowledge of the product programs, of the participants, and of the event itself. The threads were organized into two levels, with the first level being a broad topic and the second being the specific issue under that topic. Interpreting interactions A large amount of analysis work in the early cycles was spent on semantically interpreting the interactions. Interpreting and understanding these interactions were greatly aided by 1) the researchers' formal training in product development; 2) the deep understanding of the context that was acquired through ethnographic studies; and 3) the fact that the researchers participated in the event. To capture the interpretations, a two-column format was adopted, with the transcript in the first column and the interpretation in the second.

244

ICED01-C586/478

Characterizing features of interactions After interpreting the interactions, analysis was conducted to find a meaningful and reliable set of features of interactions. The semantic interpretation in the previous step provided the in-depth understanding of the interaction that was necessary to perform this analysis. In this step, each exchange of interaction in the event was characterized in terms of interactional moves. These characterizations of interaction gradually evolved with each cycle of analysis. The characterization informed better semantic interpretation of the data, which in turn helped to build better characterization of the features of interaction. In the end, a relatively stable set of interpretations and features emerged through this self-reinforcing feedback cycle. Testing generality of features The final step of the analysis cycle was to test the generality of the features. Features were tested generally true in the event were added to a list of significant features. example, it was observed that learning members verified lessons that they heard from peer with another peer. Once this feature was identified, the rest of the transcript searched to see if this occurred repeatedly throughout the event. that For one was

Observed features of interaction and a descriptive model

As the event data is rich and is much more than we can show in this paper, we will describe three most significant features of interaction that were observed, and offer brief examples to substantiate these observations. Context comparison is a key to making sense of the conversation Context comparison activities such as comparing progress between the learning program and the peer programs were observed throughout the event. Context comparison allows the experienced peers to better understand the context of the learning team, and thus allow them to prioritize what experience to share and how to share it. More importantly, context comparison also enabled the learning members to judge the applicability of others' experience to their own program. Through the act of context comparison, the participants converged onto a set of terms and metrics, which are typically found in documents used for managing the product development process. These terms and metrics became the common references from which experience of one is related to another. These are the contextual characteristics that the participants were observed to have compared: 1. product characteristics (e.g. "Is your product as complex as ours?") 2. program progress (e.g. "In which phase of the process were you in?") 3. organizational roles and accountabilities (e.g. "Does your business group have that too?") 4. management tools and techniques (e.g. "Which tool did you use to ...?") For example, one of the documents being frequently referred to during the event was a document typically used by the management to benchmark program duration. In this document, all product programs in the company are grouped into nine categories according to product newness and complexity. For each of the categories, a set of benchmark data is offered so new programs can have a sense of the amount of time that it takes to develop a product of similar newness and complexity. Instead of using these benchmark data, participant in the event used this document to make sure that the learning program is of similar newness and complexity to the peer programs, such that their experiences were directly relevant and applicable to the learning program.

ICED01-C586/478

245

Needs specification brings out learning elements by inducing localized reflection It was observed in the data that an explicit problem statement or a need statement often brings long and detailed reflections from the experienced peers. The detailed nature of the reflections allows the learning members to project the reflected experience onto their own program and draw actionable implications for the near future. Furthermore, the details allow the learning members to ask concrete follow-up questions for meaning clarification. Different forms of needs specification observed in the event include: 1. problem statements or need statements (e.g., "How do we deal with this change?") 2. scenario playback requests (e.g., "Going back to Fall of 1997, did you ...?") 3. if-then interrogations (e.g., "What could you have done differently?") 4. requests for additional details (e.g., "Is there a rationale for ...?") For example, one of the problems that the learning program leader was struggling with was to deal with shifting phase-gate review criteria, on which the program team was periodically assessed according to the firm's product development process. Because of a recent change on the formal process, some of the deliverables from the next product development phase were shifted upwards into the phase for which the learning program was planning. The program leader was frustrated about this change because the shift made all benchmark data in the newness-complexity document invalid. Without the benchmark data on the amount of time it took similar programs to complete the phase, the program leader was left with a much more difficult job of planning for the next phase. After clearly stating the problem, the program leader voiced her frustration and asked, "So, tell me how those benchmarks change when you've now moved the phase-one exit line?" Her problem statement set off one of the most detailed reflections from the peers during the event. It was evident from the program leader's later summary that she had learned valuable lessons from that conversation. Verification of implications validates learning elements and produces actionable outcomes Verification of implications is another significant feature of interaction that was observed from the event data. It was observed that learning members tended to verify the significance of a lesson they heard from one peer with the second peer, as well as to verify the accuracy of the lesson by repeating them back to their peers. Afforded by the interactive settings, the learning members not only formulated in their own terms the experience as described by their peers, but also stated them in front of their peers and gave them a chance to correct or supplement if necessary. For example, after hearing from the first peer the fact that they underestimated the time to develop the full hardware for the test system, the program leader turned to the second peer and asked, "Was that true with your program too?" The program leader sensed that the lesson might have some significance even before she asked the question, and with confirmation from the second peer, she verified the significance of the lesson. When verifying the accuracy of the lesson, learning members restated the lesson as well as its implications in their own terms, and restated them in the form of a summary or sometimes as a "think-out-loud" projection. For example, shortly after the second peer confirmed the significance of the lesson, the program leader said, "So, I heard you say, don't underestimate what it takes to build full-system hardware..." Similar to this, after hearing from the peers the importance of involving the program reviewers in the planning process, the program leader stated, "So, we need to get our reviewers' buy-in at the planning stage."

246

ICED01-C586/478

3.1 Experience Mapping - A descriptive model

The five significant interactional moves that emerged from the analysis were: context comparison, problem statement, localized reflection, meaning clarification, and implication verification. To describe these interactional moves and the sequential relationship among them, a descriptive model was constructed. Given that this model came from data gathered from one event, it is not meant to be a comprehensive model that would fit all interactive learning situations, although it is believed that it is general enough so it is applicable to many situations of learning from experience of peers in organizations. The purpose here is to help to locate opportunities for supporting these learning activities by having such a model.

Figure 1. Experience Mapping: a descriptive model of interaction-based experiential knowledge sharing in the product development context.

This model lies at the heart of this mode of learning here being characterized as Experience Mapping. Through activities in this model, experience from one context is mapped onto another. Here, mapping implies not only surveying the past experience, but also navigating through it, finding the most relevant "elements", and relating that to the current situation. The interactional moves were jointly enacted by the learning members and experienced peers. Nevertheless, needs specification, meaning clarification, and implication verification were mostly initiated by the learning members. Context comparison was initiated by both parties and occurred in various points throughout the event. Localized reflection was mostly initiated by the experienced peers, but was usually prompted by the program team's problem statements. The arrows in the diagram indicate the usual sequence of action, which is by no means the only sequence possible. In fact, the interaction sequences were routinely broken by context comparison activities throughout the event. An interaction sequence usually starts with problem statement where a learning member stated a need or a problem, or voiced his or her frustration over a matter. That would usually set off a round of localized reflection from the experienced peers, which is sometimes followed by questions from the learning members asking for quick and straightforward clarifications. Finally, with the reflections from their peers, the learning members would reconfirm with the peers by summarizing those lessons in their own terms. Then they would also express their project actions and obtain validation on the appropriateness of those actions from their peers. Learning interaction is influenced by social and political situations Learning, like all activities in the workplace, is embedded in the larger social and political context. Thus, the interaction between peers is inevitably influenced by the intricate socialpolitical environment. Unlike classroom learning, the learning team and peers do not have

ICED 01 -C586/478

247

learning relationship of student and teacher. Rather, they are in multiple relationships that are organizationally consequential. While the experienced peers are teachers in this event, they can also be peer reviewers who will assess the performance of the program at a future phasegate review. In any case, they are peers of the reviewers and their opinions of the program can be extremely influential to the reviewers. Although the program members felt the need to talk about the problems that they were facing in order to obtain concrete lessons from their peers, they had to be careful about what was disclosed because their words would partially make up the reputation of their program. This tension between disclosing enough information to learning and portraying a competent image was apparent in multiple occasions in the event. For example, at one point during the event the learning program leader felt that she needed to explain her technology before she could obtain valuable advice from her peers. She then selected a few slides and presented an overview of the technology. One of the peers was nervous about the fact that some of the technologies are so new that they might still be unproven, the peer voiced that concern and said, "so, I'd start asking, has anybody ever done anything like this? Inside or outside the company?" The program leader started defending her program and then decided to just say, "and I am not giving you a full picture here. So, please don't walk out of this with any kind of message." Not only did the learning members have to manage the tension of learning and disclosure, at times the experienced peers also had to do the same. For example, after some conversations it became clear to the learning program leader that the peer program was able to pass a phase review without having fully completed their prescribed deliverables. Paraphrased here, the program leader essentially asked, "How did you get away with that? Is there a fudge factor with the process?"

Socio-technical design implications

The interaction-based framework used in this study provided face-to-face interaction between learning members and their peers. The interaction enabled negotiation of meaning between the learning members and the experienced peers that is observed to be necessary for effective inter-team learning in product development contexts. Taking a socio-technical approach, we believe that some of the interactions observed in this event can be supported by sociotechnical systems. Here, we offer implications of the observations as design requirements. These socio-technical requirements become useful when trying to scale an interaction-based system to a larger community. Although we also provide brief discussions of possible solutions with current technologies, we believe that a whole new level of social awareness is required to design tools to support inter-team knowledge sharing and learning in product development. Three key requirements are: 1. the need for a semi-private interactional space, 2. the need to facilitate demand-driven localization, and 3. the need for shared objects of comparison. Semi-private interactional space It was observed that problem statements tend to draw locally actionable lessons from the peers through their reflection. It was also observed that there is tension between disclosing one's problems and protecting one's reputation. In order for the learning members to talk somewhat freely about their problems and frustrations, and for the appropriate peers to provide sincere responses, a semi-private interactional space is needed. In this study, the

248

ICED01-C586/478

meeting room provided a semi-private interactional space where the interactions were limited to the people in the room. Participants appeared moderate what they disclosed based on their existing relationships and knowledge of each other. Furthermore, the dynamics of conversation interplayed with interaction in such a way that the topic of discussion was interactively negotiated between the participants. With the distribution of product development communities around the world, the ability to interact in the same physical space can be limited, and information technology such as online forums can support distributed interactions that transcend physical proximity. Implications for designing semi-private interactional spaces in such distributed contexts include providing technologies that not only support dynamic interaction (synchronous and asynchronous), but also enable participants to control who has access to their verbatim disclosures of information that could have negative effects on their reputation. Demand-driven and localized reflection It was observed that reflections from peers produced locally actionable lessons when it was induced by a demand from the learning members. Therefore, a system needs to provide learning members an avenue to express their immediate problems and needs, and allow the experienced peers to understand the necessary background context to provide a useful reflection of their relevant experience. The system can provide some basic contextual information about the learning member's background and a description of the product program in which the learning member is engaged. Furthermore, the system should provide enough information for the experienced peer to contact the learning member, perhaps even anonymously if they choose to do so. Again, information technology can support this kind of interactions in distributed contexts. With communication technologies that have formalized structures such as online forums, it's important that the structures support problem- or need-centered interactions, as well as multiple interpretations and perspectives. This will help learning members and experienced peers from different functional backgrounds and organizational roles to see problems from their own perspective. While structures for demand-driven and localized reflections can be made explicit in the technologies, the structures can also be left to the domain of social practice. In this case, the technology should support flexible interactions where participants can structure their conversations according to their own demand-driven and localized needs. Shared objects of comparison Shared objects of comparison were observed to be crucial for relating the contexts of the learning team and their peers. As observed from the analysis, many of these objects were process-oriented documents that were used in day-to-day operations. In this study, objects of comparison like the product complexity matrix were used strategically for comparing contexts. These shared objects were used both to identify the most appropriate peers prior to the interaction, and were used during the interaction to facilitation communication and address relevance through context comparison. Information technology can support both uses of shared objects of comparison, however technology should not prescribe the objects since they can change over time and are often socially constructed. The technology should support objects that are locally meaningful, and in the context of product development processes an implication is that they account for locally meaningful characteristics of product complexity and processes. Technology should allow users to define locally meaningful metrics of comparison, and to assign values to those metrics for context comparison.

ICED 01 -C586/478

249

Discussion and conclusion

Recent advent of computer and internet technologies brought forth many affordances that have the promise of breaking the physical barriers of space and time. Undoubtedly, some of these technologies have already drastically changed the way we work and live. In the context of learning from the experience of peers in product development communities, many tools were designed to take advantage of these affordances. While most of these tools focused on distribution of documents across space and time, they lack the support for negotiation of meaning through interaction that is necessary for effective learning of peer experience in product development contexts. With the deeper understanding of how negotiation of meaning takes place through interaction, we can embark to design a new generation of socio-technical solutions that can support it. Furthermore, since learning is such a situated and social phenomena, we strongly advocate that the implications from these new-found insights be addressed during the design of the solution, not outside the design or after implementation.

Acknowledgement
The research was supported (in part) by the MIT Center for Innovation in Product Development under the NSF Cooperative Agreement Number EEC-9529140. References [1] Leifer, L.J., et al. Experience Capture and Reuse for Complex System Design Deployment: position paper based on our experience using the internet. In The International Conference on Problems of Control and Modeling in Complex Systems (CPCMCS). 1999. Samara, Russia. Wheelwright, S.C. and K.B. Clark, Revolutionizing product development: quantum leaps in speed, efficiency, and quality. 1992, New York, Toronto: Free Press; Maxwell Macmillan Canada; Maxwell Macmillan International, xiv, 364. Bell, D.G., et al., Dynamic documents and situated processes: building on local knowledge in field service, in Information and Process Integration in Enterprises: Rethinking Documents, T. Wakayama, et al., Editors. 1997, Kluwer Academic Publishers: Norwell, MA. Liang, T., Mapping Experience: Understanding Socio-Technical Inter-Team Knowledge Sharing in Product Development Communities, in Department of Mechanical Engineering. 2000, Stanford University: Stanford, CA. p. 140. Liang, T., Bell, D.G., and Leifer, L.J. "Re-use or re-invent?: Understanding and Supporting Learning from Experience of Peers in a Product Development Community," Forthcoming in Journal of Engineering Education, 2001. Jordan, B. and A. Henderson, Interaction Analysis: Foundations and Practice. 1994, Institute for Research in Learning: Menlo Park, CA. p. 71.

[2]

[3]

[4]

[5]

[6]

First author: Tao Liang Xerox Palo Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA, 94304, USA, Tel: 650.813.7302, Fax: 650.812.4334, E-mail: taoliang@cdr.stanford.edu. IMechE2001

250

ICED01-C586/478

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

TRANSFER OF EXPERIENCE IN CRITICAL DESIGN SITUATIONS

P Badke-Schaub, J Stempfle, and S Wallmeier Keywords: Experience, human resources, information transfer, design teams.

Introduction

It may be unnecessary to repeat the consistently named customer demands for industrial companies: they have to reduce cycle times, they should decrease costs, they should ensure and improve the quality of their products and they should offer new solutions - to name only the most frequently claimed demands for product development. But regarding the different requirements and the complex process of designing, the necessity to produce useable and novel solutions seems to be the most comprehensive and challenging requirement in order to face world-wide competition. Thus, creativity and innovation seem to be the key characteristics of successful design practise. Although a lot of authors discuss several different origins of creativity such as divine gift, persistence, perceptual knowledge, and some other, in empirical investigations knowledge and experience prevail as the main ingredients for the development of new products and solutions [1]. Moreover the significance of information transfer of experience during the design process must be addressed. With increasing complexity of technology individuals have to work together in order to raise individual solutions, which are part of a major common product, to a shared level. Furthermore, experience is an individual characteristic that can be exchanged through communication, however. Thus, the question arises how the transfer of experience can be assessed and supported and which factors are facilitating and inhibiting this process. This paper relates to the question of how designers transfer experience in different types of critical situations in an efficient way. This means that on the one hand experience is considered as an individual cognitive prerequisite in the individual designer and on the other hand, experience is seen as an important part of the information transfer process, in the context of collaboration and communication.

Characteristics of experience

Experience is acquired mostly through extended deliberate practice, thus expertise is formed in a multitude of different situations and their constituents in the specific working environment, in which more or less appropriate actions are taken [2]. But what are the specific characteristics of an experienced person?

2.1 Characteristics distinguishing experts and non-experts

The most empirical studies about expertise are investigations about the differences of expert and novice performances in different problem spaces [3]. These data reveal some important

ICED01-C586/531

251

differences between experienced and less-experienced people, especially due to their different cognitive models. Nevertheless it should be mentioned that expertise should be seen as a continuum, with the outstanding expert on the one edge and the novice with rather modest experience on the other. In addition expertise comprises different components such as general and specific knowledge, methodological knowledge, skills and self-management strategies. According to the results of empirical studies differences between experts and non-experts can be attached to three different levels [4]: General process: There are differences between experts and non-experts in regard to the rapidity and accuracy of the general information process. Knowledge-organisation: There are differences in regard to the organisation of knowledge. Experts are able to build cohesive chunks in the specific problem space. Thus, the decisive characteristics of an expert is not the quantity of knowledge but quality, that is the organisation of knowledge. Cognitive-complexity: Experts build more complex representations of information, and it is supposed that experts do have a higher capacity of the working memory. The reason may lay in the building of chunks, which are able to represent more elements with less 'memory cell'.

2.2 Characteristics distinguishing experienced from non-experienced designers

As there are very few empirical investigations about the differences of experienced and less experienced designers, it seems worthwhile to mention some important results in short. Gilnther [5] aimed to compare the strategies of experienced designers without education in design methodology (p-designers) and designers with education in design methodology (mdesigners) in a laboratory experiment. He found that the p-designers needed 30% less time in the average than the m-designers in completing a good or satisfactory solution. The reason was that experienced designers spent less time on conceptual design, elaborated fewer variants, did less documentation of the process and partly skipped phases of the design process. These results illustrate that the experienced designer seems to be a victim of the time constraints of the daily work. The one satisfactory solution produced in a short time is more appealing than the search for an optimal (creative) solution selected out of a few variants. Gunther contrasts the characteristics of the "time-oriented-process" with the "quality-oriented process" and states that the time-oriented process provides solutions 'state-of-the-art', mostly only very few concepts, whereas the quality-oriented process produces innovative solutions. Eckert, Stacey and Wiley [6] report about the burnout syndrome of experienced designers as an escalation of the effects of pressure on expert designers with the consequence of a decrease of creativity. Whereas time-pressure is only one limiting factor equally true for experienced and less experienced designers, Purcell and Gero [7] illustrate the aspect of mental fixation which is mainly a problem of experienced designers. This problem arises because designers with expert knowledge have very strong associations between elements of their knowledge. This high amount of factual knowledge leads to a pre-selection of solutions according to the elements from previous similar problem situations, which may not be relevant in the actual situation and thus may lead to incorrect or at the best to conservative solutions. These results highlight the danger of experience. Experience is mainly used to design quick routine solutions whereas the ability to produce innovative ideas decreases.

252

ICED01-C586/531

Reflecting these results encourages a differentiation of the requirements of design. Designers are confronted with ill-structured problems as well as with well-structured problems, so that it seems worthwhile to follow the differentiation of Hatano & Inagaki [8] between routineexpertise and adaptive expertise. Routine expertise is mainly developed in the field of work, which is characterised by constant and repeating requirements whereas adaptive expertise develops especially in the context of changing requirements and problems. In the process of the repeated performance parts of the involved knowledge may become unconscious and may mutate from explicit to implicit knowledge which is often difficult to verbalise. Based on these assumptions it is not surprising that experts often have difficulties to transfer their knowledge and their applied rules to other people [9]. So, if we focus on the transfer of experience we should concentrate on problems with less routine and more adaptive expertise.

Investigation

3.1 Research Methods

In a joint research project engineers and psychologists have investigated ten design processes in four companies by compiling detailed records of the design process as well as collecting data on the individuals, the group and external conditions [10]. In a thorough analysis, the observed design process has being differentiated into routine situations on the one hand and critical situations on the other in order to concentrate on situations that have an important influence on the further direction of the design process and the product. These 'critical' situations are then described by influencing factors and their interrelations [11]. Furthermore, the communication between members of the observed design team in critical situations was assessed and categorised [12].

3.2 Main findings

In the following we want to elaborate the significance of experience in the context of collaboration during the design process. Frequency of occurrence of communication in critical situations First of all we analysed the frequency of occurrence of communication in critical situations and during the whole working time. Although in our investigations designers were working individually about 70% of the whole working time, communication between colleagues occurred in 90% of all critical situations. This result illustrates the importance of information for the exchange of decisive design information (cf. Figure 1). In an additional study [12] interviews in 10 R&D departments of major German companies the importance of colleagues as the most frequently mentioned source of information transfer in everyday design work were underlined: Verbal communication was described as the most important mode of the information seeking process.

ICED01-C586/531

253

Figure I. Communication in critical situations and during the whole working time. Importance of experience in critical situations The next question was to analyse how often experience was rated as an important individual prerequisite during the handling of each critical situation. Experience was rated high, if the experience of the designer with the specific problem area was longer than mostly five to seven years - in case that the observer couldn't decide about this fact the designer was asked about his experience in the particular field. The data revealed that in 49% (n = 336) of all critical situations (n= 682) experience of the designer was rated as an important influencing factor (cf. Figure 2).

Figure 2. Experience rated in critical situations according to biographical data or according to the selfassessment of the designers.

254

ICED01-C586/531

Experience and performance in critical situations Appreciating that experience plays an important role in critical situations yet we do not know, if high experience is correlated with successful performance in the particular critical situation. This study refers to the question to which extent the experience of the designer is transferred into a successful result. Thus, the next step was to analyse how often high experience and information availability was combined with a successful result. The data illustrates that whenever an experienced designer was involved in the critical situation the transferred knowledge was mostly useful (cf. Figure 3): More than 80% (n= 219) of all critical situations with the participation of a highly experienced designer (n= 271) were performed successfully. But it is also remarkable that in almost 20% of all critical situations the highly experienced designer was not able to turn the situation to a good account. Nevertheless it is necessary to point out that experience was only one influencing factor contributing to a network of interrelated factors from the field of the individual designer, the group, the external and organisational aspects and the characteristics of the problem itself.

Figure 3. Experience and performance in critical situations. Experience in different types of critical situations

As we have mentioned earlier, the whole observed design process was recorded and divided into routine situations and so-called critical situations. Why? The analysis of design work reveals that not every moment is of the same importance for subsequent design activities and for results obtained later. For example, at certain moments we may observe designers sitting at their CAD station adding holes and screws during the embodiment design phase of a component; at other moments they are engaged in deciding on concepts or solution principles. Obviously, we can distinguish between 'routine work' and 'critical situations', that determine 'choice points' in the process, and thus in the whole project. These critical situations influence the remaining design process in a positive or negative way. Derived from the steps of general problem solving, we can contrast different types of critical situations regarding their aim in the problem solving process, such as 'goal-analysis and goal-decision', 'solution-search',

ICED01-C586/531

255

'solution-analysis and solution-decision'. Moreover, we can observe situations that are important in their social context such as 'conflicts' and 'disturbances' (cf. Figure 4).

Figure 4: Critical situations in the process of design work.

According to the definition of experience as knowledge about facts and strategies in combination with skills in a specific work domain we would not expect that experience in the design context facilitates the management of critical social situations such as disturbances and conflicts. Thus, we analysed the impact of high experience in critical situations of the type goal elaboration (=goal analysis and goal decisions) and solution search.

Figure 5: High experience in relation to successful and unsuccessful results in two types of critical situations.

256

ICED01-C586/531

It turned out that the designers were able to transfer experience in an efficient way in regard to the development of solutions. But experienced designers in our investigations had more problems transferring helpful information in situations of goal elaboration (cf. Figure 5). The data reveal that in 36% of all critical situations of the type goal elaboration the result of the situation turned out as unsuccessful. In contrast, in more than 73% of solution search the situations were crowned with success. Searching for reasons we should ask what are the specific requirements of situations with goal elaboration in contrast to situations with solution search?
Table 1. Typical requirements in situations of goal elaboration in contrast to solution search.

Goal elaboration Transfer of information is requested to fixed requirements Precise knowledge about the factual requirements Recognition of the context and relevance of the particular goal

Solution search Amplifying and limiting the search area of ideas and solutions Generation of ideas: intuitive, not necessarily systematic analysis There is no 'one and only' solution

As we point out in Table 1 the two types of situations are very different in regard to the requirements. In the context of goal elaboration the experienced designer is asked to contribute precise information concerning existing requirements. However, the knowledge of the experienced designer is not necessarily concerned with the actual requirements; he often transfers information from similar problems he knows from the past in a routine manner. Additionally, the designer who is asked for information is not involved in the complete network of the problem space; therefore he or she may put the focus on a completely different (maybe wrong) part of the problem and may not be aware of side and long-term effects of the given answer. If such information meets an inexperienced colleague the experienced designer may create severe problems in the future. Whereas goal elaboration is very much restricted to the 'correct information', which is related to the prescribed requirements, the solution search is especially concerned with idea generation and idea evaluation. In situations of solution search we observed many situations of informal discussion, where the experienced designer was asked to generate an idea and to discuss hindering or facilitating aspects of the developed solution. Thus, in this context experience is of high value because unclear ideas can be substantiated or brought into another view. The discussions move between limiting and amplifying the scope of the problem but the experienced designer is not asked for the generation of the one right solution. In this context experience frequently initiates a thorough analysis and a deeper thinking, a process which leads to successful solution search more often.

Conclusions

In the paper we pointed out that the transfer of experience does take place in the design office very common and that the transfer of experience is of relatively great effectiveness in critical situations. However, experience is of different value in different types of critical situations. With regard to situations in which solutions are generated we can state that experience - in relation to Hatano, G. & Inagaki [8] 'adaptive experience' - can be transmitted successfully for the most part. This is more doubtful in situations of goal elaboration. One major problem

ICED01-C586/531

257

lies in the context of informal discussion in design offices. Whereas this strategy of informal information seeking is very recommendable in obtaining a good group climate and creative discussions [12], it also enhances ad-hoc and non-reflected answers. Usually designers prefer to search for information by asking their colleagues, because in doing so they receive a lot of additional information including a rough idea of the quality of their own idea, solution or decision. According to the results of the study we would suggest to reinforce informal group discussions in the context of solution search, but the process of information transfer during situations of goal elaboration should be supported by an information tool - not necessarily computer-based tools - which provide quick and current information about requirements. References [I] Cross, N. and Clayburn Cross, A., "Expert Designers", in E. Frankenberger, P. BadkeSchaub and H. Birkhofer (eds)., Designers. The Key to Successful Product Development, pp. 71-84, London, Springer, 1998. Hacker. W., "Expertenkonnen. Erkennen und vermitteln ". Gottingen, Hogrefe, 1992. Glaser, R., "On the nature of expertise", in F. Klix and H. Hagendorf (eds.), Human Memory and Cognitive Capabilities. Amsterdam, Elsevier, 1986. Steinberg, R.J., "Expertise in complex problem solving: A comparison of alternative conceptions", in P. Frensch and J. Funke (eds.), Complex problem solving: The European perspective. Hillsdale, LEA, pp.295-321, 1995. Gunther, J., "Individual influences on the design process - time-oriented vs. qualityoriented design", Proc. ICED '99. Munchen. Vol. 1, pp.201-204, 1999. Eckert, C., Stacey, M. and Wiley, J., "Expertise and designer burnout", Proc. ICED '99. Munchen. Vol. 1, pp. 195-200, 1999. Purcell, A.T. and Gero, J.S., "Design and other types of fixation", Design Studies, 17, 1996,pp.363-383. Hatano, G. & Inagaki, K., "Two courses of expertise", in H. Stevenson, H. Azuma and K. Hakuta (eds.), Child development and education in Japan. San Francisco, Freeman, pp.262-272, 1986. Dreyfus, H.L. and Dreyfus, S.E., "Mind over Machine: The Power of Human Intuition and Expertise in the Era of Computer", New York, Free Press, 1986.

[2] [3] [4]

[5] [6J [7] [8]

[9]

[10] Wallmeier, S., Badke-Schaub, P. and Stempfle, J., "Empirical diagnoses and training in design departments", Proc. of the TMCE. Delft, April, 1999. [II] Badke-Schaub, P. and Frankenberger, E., "Analysis of design projects", Design Studies. 20, 1999, pp.465-480. [12] Badke-Schaub, P. and Frankenberger, E. (1999),. "Design Representations in Critical Situations of Product Development". Proceedings of the 4th Design Thinking Research Symposium. MIT, Boston, 1999. Dr. Petra Badke-Schaub (Mrs) University Bamberg, Institute of Theoretical Psychology, Markusplatz 3, D- 96045 Bamberg, Germany, Tel.:++49 (0)951 8631863, Fax: ++49 (0)951 601511, e-mail: petra.badkeschaub@ppp. uni-bamberg. de Petra Badke-Schaub 2001

258

ICED01-C586/531

Organization and Management of Design

Including sub-sections:
Project Management Product Strategy and Management Planning and Workflow Management Concurrent Engineering and Integrated Product Development Distributed Design/Supply Chain Integration Design Teams Management of the Clarification Phase Performance Evaluation Risk and Uncertainty Management

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

PRODUCT DEVELOPMENT MODELS FOR SHORTER LEAD TIMES AND MORE RATIONAL PROCESSES - ITS EFFECTS ON THE WORK SITUATION FOR PROJECT MANAGERS AND PROJECT GROUP
A Zika-Viktorsson and J Pilemalm

Keywords: Project management, project work, human resources.

Introduction

Time as a scarce resource Time to market is since the past ten years a factor highly stressed in product developing companies. This factor is added to the requirements cost, performance and quality and has caused rethinking and changes in companies and projects. The strive towards a faster product development can be considered a consequence of growing international competition, the accelerating technical development, more products and shorter life cycles, and the diversification of customer needs. Higher effectiveness through lean product development and standard models Lean product development is a concept heading towards higher effectiveness. It is a broad concept, encompassing a number of techniques as concurrent engineering, cross-functional teams, and integrated rather than coordinated cooperation. One of these techniques is organizing work in projects with heavy weight or autonomous team structures. Project organisations by itself implies a clear time limit, a date when the task should be accomplished. Project management literature describes projects as a rational method to organise development work optimised to the objectives for time, function and costs. Projects are seen as functional in order to handle undertakings of more unique nature with development as the central feature. In industrial product development the basic reason for organizing work as projects is to implement a planning strategy. One way of making the product development process more efficient in a company is to implement structured models for standardising product development activities. In general, the reason for a company to implement such models is to obtain a more effective use of resources and time. Other reasons are to create consensus for the project process and the project management, a necessity caused by increased complexity in both technique and organisations [1]. Beside the more efficient use of resources such models are supposed to facilitate control over projects from an internal as well as external point of view. A standard model for projects may also make it easier for the team members to know what expectations are placed on them.

ICED 01 -C586/461

261

Focus on time - implications on team Elevated time goals and organising for shorter lead-times impact co-workers as well as coworkers impact the ability to shorten lead times. Group effectiveness as performance addressed to the goals for the project is an essential factor. The project team must exert sufficient effort to accomplish the task at an acceptable level of performance. An effective team is a prerequisite for accomplishing a project within narrow time frames. Beside the obvious needs for effort the members in an effective team also have to bring adequate knowledge and skills. The members must be able to employ task performance strategies that are appropriate to the work and coordinate their work at the same time as motivation and commitment are created and maintained. Further, an effective team must have a potential to avoid inappropriate ideas and contributions as well as they must possess learning and sharing skills. They need capabilities to avoid flawed implementation of plans and develop ways to proceed with the work [2]. Not only the capabilities of the available team are crucial. Team effectiveness is interdependent with organisational context, boundaries between tasks and groups, and team development [3]. One disadvantage with working in time-focused projects can be a too heavy workload, which can give drawbacks on individuals as well as objectives for the project. Product development projects high in complexity together with work in multi-functional teams and elevated time goals can cause too much strain on the members in the projects. There is a risk that intensive project work brings a much too high work strain as a consequence of high demands on effectiveness and efficiency together with parallel activities [4]. To tight time schedules give less time for reflection and decision-making, which lower the quality of the product, and can be negative for the members and cause negative work strain [5].

1.1 The aim of the paper

The paper will present results from a qualitative interview study made to explore the positive and negative consequences for project managers and members in project teams highly focused on the time objectives. The study looked at the work situation on the project level in two companies that implemented standard models for how to handle product development. The models were implemented as means to shorten the lead times for the projects.

Data and methodology

Data for the study was collected from 16 co-workers in product development projects (of which 8 were project leaders), equally dispersed at two companies. The two involved companies were Swedish manufacturing companies in the mechanical industry. The companies had implemented new models for the product development process with the aim to run the projects faster and with better structure. For both companies, the development of new products was important for the long-run success. Further, the type of product development work in these companies was technologically sophisticated and the development undertakings included new products and variants of existing products. The planned length of the various projects, the interviewees were working in, varied between two and seven years. The sizes of the core project teams varied between seven and 20 members.

262

ICED 01 -C5 86/461

The interviews involved questions addressing co-operation, co-ordination, workload, time pressure and decisions. The interviews were semi structured and with the length of one to one and a half hour. The interviews were tape-recorded and analysed according to principles for grounded theory [6]. The study had an explorative approach with qualitative methods. The qualitative approach is justified by the complexity of the studied situation. To grasp both qualities in the models and experiences of working with focus on shortening lead-times a qualitative approach was needed. An explorative approach was needed because of the lack of research concerning timefocused project work and psychosocial work-environment. This paper shows results, which is a part of a more comprehensive study involving a broader scope and a third company [7].

Findings

With an aim to make the product development projects faster the two companies had introduced new models for the whole product development process and the projects within. The aim was to improve the procedures for managing, monitoring and planning the product development in general, as well as the separate projects. The new models were supposed to be a way to improve the quality in the work process by making the activities more concurrent and support the multi-functional co-operation, and at the same time make the projects accomplished on a short time. The new models should support and prescribe the work by giving a holistic and comprehensive view of the product development process. They should also introduce better routines and structures as well as elevate the time objectives. Former models imaged the product development process (and project process) as sequenced activities emphasizing construction, and functional goals. They mirrored work methods and strategies where functional objectives and technical performance was superior to objectives for time.

3.1 Experiences of working with the models for product development projects
The models as a support. At the project level the new models were generally seen as a good support in the overall work with planning. The models and the routines had given the project managers new tools for executing the projects. They were also functional as a common platform for all the projects within the companies. The models were considered as contributions to better understanding of the product development process and the project management at all levels in the companies. The models as a burden. Even if the new models were created with the aim to suit the specific business in the particular company, shortcomings were reported. According to the interviews the models were fitting product development projects at a low level of complexity. Thereby the models couldn't be a functional support or guide for projects characterized by great dynamics, parallel and concurrent activities, high complexity and high speed. The models couldn't support these kinds of projects well enough. The routines prescribed by the models tended to become a burden for the project managers, making it difficult to accomplish the project as effectively as they wished. According to the interviews the models were considered as stiff and inflexible.

ICED 01 -C586/461

263

Needs for neglecting the model. Because of the elevated importance of time objectives it was sometimes a need to neglect the prescriptions connected with the model. In the interviews it is described how the complex nature of the project together with the demands for speed made the project manager searching for short cuts. Thereby there was a need to neglect some of the routines. Because of the nature of the product development project, it wasn't possible to keep up with the prescribed process nor the work methods or administrational routines.

3.2 Experiences of working towards shortened lead times

High commitment and pride. Even if the interviewees reported some negative aspects on working with a sharp focus on time there were also some positive impact on individuals and teams. The work under high pressure was a challenge, which resulted in feelings of pride when the goals were reached. Another positive aspect was that a ground for high commitment between team members was created. More work with plans during accomplishing a project. Emphasis on reducing time gave implications for compressed time schedules for the operative work in the projects. However, the speed, dynamics and complexity put special demands on planning procedures and scheduling methods. The work with plans and with communicating them to team and stakeholders is always an important part of the work for a project manager. However, the elevated focus on time objectives resulted in more work with planning. The compressed time schedule made the smallest deviation affect the plan. According to the interviewees this made it necessary to put a great deal of work updating the plans and schedules continuously. Less time for thinking. The increased tempo and the tightened time schedules made the periods, during work hours, for thinking, reflecting and catching up fewer, or even nonexisting for the project managers. Even though the daily work - off course - calls for a lot of reflective thinking there was a lack of time for thoroughly go trough problems and tactics. There was a need to clean up the desk and get undone administration done, as well as reflect about the structure and the process from a distance, and thereby get possibilities to grasp the picture of the whole situation. According to the interviews there was a need to reflect over the project situation and thereby gain better control over the situation and deviations. Hasty decisions and uncertainty. There was also an experienced lack of time to take into account (in a satisfying extent) important aspects of a problem before a decision. The need for quick decisions created feelings as constantly coping with risks and, in turn demanded selfconfidence and fearlessness together with carefulness and sound judgement. According to the interviews the work with shortening lead times was sometimes synonymous with constantly handling hasty decisions and uncertainty. Greater need for support. An assistant or a 'right-hand man' (or woman) can be of great support for a project manager - especially in projects characterized by uncertainty and high speed. In the interviews there was an example of a partnership that had been of great help. Both by practically relieving some of the workload but also by being a trusted person that supported the project manager in more strategic and sometimes controversial questions. In the high-speed project there was a constant need for quick and effective discussions about several aspects of formal management as well as leadership. This partnership was facilitated by a concordant view upon project management and compliance at the personal level. Needs for empowerment in project teams. It is necessary for a project manager to delegate tasks as well as responsibilities in a complex and fast project. According to the interviews the

264

ICED 01 -C5 86/461

project managers had to decrease the direct and personal way of controlling product related details. They had to trust the project members, their competence and ambitions. It was also considered important to encourage empowerment in the teams. Needs for committed team placed together. A highly committed team was considered as the obvious ground for effective project work within narrow and rigid timeframes. According to some interviewees organizing the project as a heavy weight team and not within a matrix structure enhanced commitment. This made a good ground for commitment partly by avoiding conflicting supervision of more then one supervisor. It was also of great importance to place of the team members together. This localization made it possible to resolve problems in an effective manner where the team could use their capacity to continuously and thoroughly work out the problems coming up. The whole team could work integrated and discuss until all questions were went through. To place a team together gives good opportunities for the members to thoroughly work with problems. Even if there were limits they wasn't settled by a meeting agenda, formal communication channels or distance. Attention on signs for overwork. According to the interviews there was a need for the project manager in the high-speed project to be attentive to signs for team members not feeling well under the high pressure. Beside the demands for monitoring and controlling, to keep the project on track, it was important to focus on how the coworkers cope with the pressure. There was a need not only for the project manager to be attentive to signs for overwork; everybody had to pay attention to this kind of problems. According to one of the statements in the interviews, projects with only male members tend to neglect these kinds of issues and focus too much on practical and technical issues. The risk for lowering the quality in technical solutions. According to the interviews there was a worry among the product developers for a lowered product quality caused by the focus on time objectives. In the interviews there was examples of dissatisfaction concerned jeopardizing the quality. Another aspect on working with high time focus was the impact of the time pressure on creativity and problem solving. According to the interviews there were situations when team members ran out of ideas because of the high pressure. But there were also examples on increased creativity caused by the situation where the team, forced by the time pressure, had to lift themselves up to higher levels to grasp the whole situation and then find out new ways to solve problems. To work very intensive and focused had also created a lot of knowledge. The intensive work together in the team, with the common task, was a ground for high level of knowledge about every aspect of the object for the project. This knowledge together with a rich flow of ideas and an open climate were considered as one of the basic factors for accomplishing a highspeed product development project. Insufficient time for personal development and participating in company activities. In the interviews there was an example of neglecting the more formal development of the team, individuals and the work methods. There was also a lack of time to participate in different company events, which made the project rather isolated.

ICED 01 -C586/461

265

Discussion

The aim of the study was to investigate how standardised ways for managing projects together with the claims for shorter time-to-market can affect the work situation on operative project level. The interviews give a broad picture of the experienced work situation in these projects with new standards for routines and elevated time objectives. This picture includes both advantages and disadvantages. Below, the three main parts of this picture are discussed. First. For the manager of a dynamic, complex and high-speed project, a standard model created to suite every project within a company can be difficult to apply. It can even be considered as an obstacle for effective accomplishment. Beside the direct implication of a stiff model on effectiveness at the project level, it can also lower the work satisfaction. Individualism, meaning to retain the own identity and do things the personal way, is opposed to conform to an imposed standard. The standard way of managing a project has to be balanced with possibilities for commitment, flexibility and control. In what extent this is a general problem within companies, can be discussed. However, the uniqueness of a project form and standardization of the bureaucratic form can stand as each other's empirical opposites as ways of organizing [1]. The project management literature states that projects should be handled on a situational basis. But also, the features of scientific management can make a natural ground for primarily aim towards uniformity and standards when creating and implementing new work methods. Second. Endeavours, at the project level, for speeding up the product development call for intensive teamwork. This kind of teamwork evolves naturally around the constantly arising problems. It involves effective communication; rich flow of ideas and possibilities to work thoroughly with arising issues. Provided by prerequisites for effective communication the intensive teamwork can give a genuine and comprehensive knowledge concerning the object for the project. Problem-solving orientation influences how quickly a product is developed [8]. The intensive and successful work together in a team can lay ground for high commitment and pride. Factors as goals, empowerment, climate and human resources plays an important role in cross-functional work in product development. These factors are affecting each other and set the stage for subsequent development [9]. Work group effectiveness can be defined in terms of both productivity and employee satisfaction [10]. Another important factor is self-management, which is the group level analogy to autonomy at the individual job level. It is central to many definitions of effective work groups [11] and part of most interventions. Related factors are participation and selfmanagement that are presumed to enhance group effectiveness by increasing members' sense of responsibility and ownership of the work. Work group effectiveness also demands task significance, in terms of members thinking of their task as having significant consequences [2], An effective team also needs collective belief in their capability to perform their job - i.e. the team's efficacy [12]. Third. Work with elevated time objectives exposes project members and team members to strain. Besides a more direct pressure from the explicit objectives, there is a pressure from decreased control and lack in overview if the project also is highly complex. The experience of control is an important factor for reducing high negative stress levels [13]. Usually project work demands balancing between objectives within time limits. The task for a project

266

ICED 01 -C5 86/461

manager implies trade-offs within a frame settled by the objectives for function, cost and time. But the tighter the scheduled time limits are, the shorter the time for reflecting and evaluating decisions and effects. There is less time for thinking and gaining control and the difficulties concerning to these matters aggravates with the complexity of the project. The need for support in a work team become more obvious as the time pressure escalates. At the operative project level both team members and managers must be supported both socially and instrumentally. Besides the obvious advantages of instrumental support and relief, social support has shown to be an important moderator on strain [13]. Among the need of other important supporters the project manager can need a 'right-hand'. This partner can provide aid during the execution of the project, both in evaluations but also by generating ideas concerning work methods. This partnership can reduce strain and improve the quality in decisions. An increased risk for overstrain within a project can make obligations for the operative project manager to focus more on psychosocial issues such as workload. The pressure in a high-speed and complex project emanates directly from compressed time schedules, but also indirect by jeopardizing quality and hasty decisions. The primary part of leadership in operative project management is goal-focused. Even if a project manager always, at some degree, has to consider relational and psychosocial aspects, there can be more of a necessity to focus on workload and well-being in high-speed projects. The findings in the study indicate problems at the operative level connected with faster projects. Changes made to rationalise the product development and to shorten the project life cycle put demands on the co-workers in the product development. Besides the advantages connected with economy and competitiveness there are also some risks with short lead-times leading to time-pressure that is too heavy. Too high a speed in the processes are not only a risk for overstraining the personnel, it is also a risk for the creativity, the quality in the decisions (and of it lower quality in the products) and the possibilities to develop the people, the methods and the groups. Furthermore, there is a risk for lowering the work satisfaction and thereby receiving a high personnel turnover. The study gives implications for further investigations on how demands for shorter lead times effects humans, the outcome of the projects and the design of project standard models. Important question to be investigated concern the contradiction between the greater importance for controlling and planning in projects characterised by high-speed an complexity, and the deteriorated possibilities to actually do this in such projects. It would be appropriate to use a qualitative research approach to obtain detailed an in-depth understanding in these matters. It is also of importance to investigate how single elements in a standard project model, as well as more general functions for steering, management and execution, are related to each other and to the work done by operative project manager and project team. Further, effects on the output of the project must be concerned. Not only outputs with obvious relation to the formal project goal, but also in terms of development of teams and individuals, knowledge and creativity. Off course, there is also a need for studies looking at workload (and moderating factors) generated within frames settled by objectives for time, resources and function.

ICED 01-C5 86/461

267

References [I] [2] [3] [4] [5] Eskerod, P. and Ostergren, K., "Why Do Companies Standardize Project Work?", International Project Management Journal, 6, 2000, p34-39. Hackman, J.R., Groups that work (and those that don't), Jossey-Bass, San Fransisco, 1990. Sundstrom, E., De Meuse, K. and Futrell, D., "Work Teams. Applications and Effectiveness", American Psychologist, 45, 2, 1990, p120-133. Hovmark, S. and Nordqvist, S., "Project organization: Change in the work atmosphere for engineers", International Journal of Industrial Ergonomics, 17, 1996, p389-398. Rissler, A., "Extended periods of challenging demands in high tech work. Consequences for efficiency, quality of life and health", In Bradely and Hendrick (Ed.) Human Factors in Organizational Design and Management IV, Elsevier, Amsterdam, 1994. Glaser, E.G. and Strauss, A.L., The discovery of grounded theory: Strategies for qualitative research, deGruyter, New York, 1968. Zika-Viktorsson, A., Pilemalm, J. and Hjelm, J., New Way of Working in Product Development: Case Study in Three Manufacturing Companies (In Swedish), Royal Institute of Technology, Department of Machine Design, Stockholm, 2000. McDonough, E.F. and Barczak, G., "Speeding up new product development: The effects of leadership style and source of technology", Journal of Product Innovation Management, 8, 1991, p203-211. McDonough, E.F., "Investigation of Factors Contributing to the Success of CrossFunctional Teams", Journal of Product Innovation Management, 17, 2000, p221-235.

[6] [7]

[8]

[9]

[10] May, R.M. and Schworer, C.E., "Developing Effective Work Teams: Guidelines for Fostering Work Team Efficacy", Organization Development Journal. 12, 3, 1994, p2939. [11] Pearce, J.A. and Ravlin, E.G., "The design and activation of self-regulating work groups", Human Relations, 40, 1987, 751-782. [12] Campion, M.A. and Higgs, A.C., "Relations between work group characteristics and effectiveness: Implications for designing effective work groups", Personnel Psychology, 46,4, 1993, p823-850. [13] Karasek, R. and Theorell, T., Healthy Work, Basic Books, New York, 1990. Annika Zika-Viktorsson Integrated Product Development, Institution for Machine Design. Royal Institute of Technology, S-100 44 Stockholm, Sweden, Tel: + 46 8 790 63 03, Fax: +46 8 20 22 87, Email: annika@md.kth.se, www.md.kth.se IMechE2001

268

ICED 01-C5 86/461

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A MULTI-PROJECT MANAGEMENT APPROACH FOR INCREASED PLANNING PROCESS

F Marie and J-C Bocquet

Keywords: project management, multi-project, planning, decomposition, and assignment

Introduction

Scope of the research: After a short introduction about PMI concepts for project management, we will focus on three major topics of the project planning process, which are decomposition, assignment, and advancement state management. The scheme of the paper is in four steps: synthesis, problematic, proposals and impacts. The scope will widen in part 5 with a research proposal about generalised multi-project management. The topics, which are in our research activities, but not developed in this paper, will be specified.

Formal project management by PMI

The PMI Standards Committee has developed a document that describes the sum of knowledge within project management: The Project Management Body of Knowledge (PMBOK, [ 1 ]). It defines a project as a "temporary endeavour undertaken to create a unique product / service", and project management as "the application of knowledge, skills, tools and techniques to project activities in order to meet stakeholder needs and expectation". The PMBOK describes project management using three models: the project life-cycle: a project is subdivided into phases, organised by logical and chronological flow, the project processes: series of actions bringing about a result (they map knowledge into deliverables). They are organised into process groups: initiating (recognising that a project or phase should begin and committing to do so), planning (devising and maintaining a workable scheme), executing (co-ordinating resources to carry out the plan), controlling (ensuring that project objectives are met) and closing (formalising acceptance and bringing it to an orderly end). the knowledge areas: logical grouping of competence and the corresponding processes. They split up between two categories: the core knowledge areas: they generate the mandatory project deliverables: project integration, scope, time and cost management, the facilitating knowledge areas: they allow carrying out the core processes effectively: project quality, human resource, communications, risk and procurement management,

ICED01-C586/563

269

The project manager's role is to integrate team actions to deliver project results within the triangle scope / time / cost constraints. As specified in [2], planning and controlling processes are the major studied processes. We will focus on the planning process onto the next parts.

The planning process: synthesis and problematic

3.1 Description (figure 1) and synthesis

PMI's planning process consists of ten core processes, supported by nine facilitating processes. Our scope is about the answer to questions what, who, how, when and how much:

Figure 1: PMI's planning core processes and major planning delivcrables

All these processes apply to the Project plan development: putting the results into a consistent document. This process is facilitated by the Organisational Planning and the Staff Acquisition, which consist of identifying, documenting and assigning project roles, responsibilities and reporting relationships, and then getting the needed human resources assigned to and working on the project. Synthesis: PMI describes a structured planning process, with identified steps. But many companies do not use such a structured process. For those companies, we propose some simple methods to do the main actions of the planning process. For companies that use part or all of PMI's planning process, we propose some improvements or tools that are not specified in the PMBOK. So, there is a reason for everybody to use what follows, but let us see first the problematic of the planning process. 3.2 Problematic

a- How to decompose project deliverables into smaller, more manageable deliverables? Decomposition of the WHAT (project objectives). The deliverable / objective has to be small enough, so that it becomes possible to define and sequence the activities that will realise it. b- How to decompose low-level deliverables (or work packages, as called in the lowest level of the WBS) into activities? Transcription of the WHAT into the HOW (how the objectives and deliverables are achieved by carrying-out of activities).

270

ICED01-C586/563

c- How to decompose activities into smaller, more manageable activities? Decomposition of the HOW. The activity has to be small enough, so that there are resources, which will be able to carry it out. d- How to assign people accountable for work packages, or bigger deliverables? Assignment of a WHO to a WHAT. Finding the person or subcontractor with commitment, ownership and responsibility for delivering the objective within time, scope and budget. e- How to assign resources (people, machines, equipment) to carryout activities? Assignment of some WHOs (who can be material stuff) to a HOW. Finding the persons, machines, equipment or combinations (like partners, subcontractors, internal services) with the skills, technologies and capacities to achieve activity within time, scope and budget. f- How to plan correctly at the beginning of the project? Is it possible/realistic? Is it worthy to try to do so? Putting in a consistent document the WHAT (for scope management), achieved by the HOW, carried-out by the WHO, with WHEN and HOW MUCH parameters (for time and cost). Part 4.1 (Decomposition) brings lighting to problematic a-, b- and c-. Part 4.2 (Assignment) brings lighting to d- and e-. Part 4.3 (Independent sub-projects planning) brings some lighting to problematic e-. Part 5 widens to generalised multi-project management. In summary: Decomposition is a cognitive problem solving process, which depends on many uncontrolled factors, as experience, available information, teamwork and team performance, team members' personalities and intelligence, and complexity management skills. Assignment is a multi-criteria choice process, which depends on human factors, as historical experience and relationships between people, powers and politics, complexity of multiple criteria, information about skills and interests, personal and even private data. Independent planning is a risk management process, which depends on personality of people, experience and historical information about similar situations / teams, and reporting accuracy needed by management.

Proposals and impacts

Figure 2 defines our research topic: from a situation analysis, each project manager at each level of the project, is able to generate the process that will satisfy the stakeholders, and the organisation that will carryout the process. We identify three kinds of risks: Functional risk: linked with the project objectives. The more ambitious, complex and resource-limited it is, the higher is this risk. Unrealistic expectations represent 9% of failure in IT projects. Uncertainty and waiting risk: as we do not still have any idea of the solution, there is a risk that this solution does not exist, or that we will find it too late. It is the balance between deciding too early (with the risk of error because of lack of reliable parameters) and deciding too late (with the risk of having no more enough time).

ICED01-C586/563

271

Organic risk: linked with the solution decided to realise the need. The more the solution is tested, validated by experience and robust, the smaller the organic risk is. Maybe we could ask too much (functional risk), maybe we could have chosen a bad solution (organic risk), or maybe we have waited too much before deciding for a solution (waiting risk).

Figure 2: basic scheme for project manager's actions and decisions

4.1 Decomposition
Decomposition is a cognitive process. A non-human tool is not able to decompose work package or activity. Decomposition builds the project process (figure 2). Proposal 1: As the three problematic talk about different natures of inputs and outputs, there are three different methods for decomposition. Research outputs: standard procedure for each decomposition process: the DDD (Decomposition of project Deliverables into smaller Deliverable*) method, the DDA (Decomposition of project Deliverable into Activities) method and the DAA (Decomposition of Activity into smaller Activities) method. Link with PMBOK: DDD is in Scope Definition, DDA and DAA arc in Activity Definition. The three methods and their differences and similarities will be developed in oral presentation. Proposal 2: Historical information and standard documents and templates are needed to help this human cognitive process. Best arc computer-based templates and historic. Research outputs: Storage of Work Breakdown Structures (to help the DDD function), of activities lists (to help the DDA and DAA functions), computer-based tool to execute one of the three decomposition functions and to integrate results in the project plan and the project database. Proposal 3: Each actor assigned to a part of a project is himself (or herself) a project manager of a smaller project. A recommendation is to decompose one level at the time. Each subelement (deliverable or activity) is assigned, and the person responsible for the sub-element will execute the same decomposition process, with one of the same three decomposition functions. Research outputs: a WBS that is built progressively, and not in a one shot process. Activity lists are progressively built, in the same time as the WBS building. Proposals 1 to 3 are independent. Impact 1: with Proposal 1 & 2, a good method and historical information will increase reliability of decomposition results. The decomposition will be complete, the alternatives will

272

ICED01-C586/563

have been specified, sorted and maybe eliminated (or may still serve as "B plans"). The subelements will be coherent and consistent, and the interface problem will have been studied (it is a very tough problem to manage interface between deliverables, or between teams). The organic risk and waiting risk (see beginning of part 4.) will be reduced. As we know that the amount at stake growths through the phases, the organic risk reduction is a major gain in the planning process, especially to avoid planning mistakes, and rework or delay penalties. Impact 2: with Proposal 3, each actor has a one-level vision in all directions: one fatherelement, some brothers, and some sons. This reduced vision allows a more accurate management, because of the reduction of complexity of environment. Each manager can for example make a stakeholder analysis (as father manager becomes the customer, and as sonmanagers become suppliers), and a make-or-buy analysis, in his (or hers) competence domain.

4.2. Assignment
Assignment is a cognitive process. A non-human tool is not able to assign somebody or something. Assignment builds the project organisation (figure 2). Proposal 1: There are only two kinds of assignment: people responsible (accountable) for a deliverable (output of the Initiation process, seeing deliverable as project), and resources (people, machines, equipment) carrying out an activity (output of the Resource planning process). Research output: the required skills and level (able to do or to delegate) of each role. Proposal 2: There are only two kinds of competence: management skills and technical skills. Research output: a classification of some skills in this two-column table. Proposal 3: A competence database is a useful tool to help for choice. It is possible to implement such a database in companies when it evaluates what can do the person, and not the level of competence she has in different skills. It reduces many problems of rewards, database maintenance and evaluation system. Research output: a data structure for competence database. It includes level 1 to 4 evaluation of skill and levels 1 to 4 evaluation of interest about working in this skill (developed in oral presentation). Proposal 4: the project manager may be guided with a standard assignment procedure, just as for procurement. Assignment of people has many similarities with choice of a subcontractor. Research output: a 7-sleps assignment process. Below is the process for human assignment (the process for machine and equipment, or subcontractor assignment, is not developed here): 1. Identify the required skills: For a deliverable, manager looks for an accountable, responsible person, so a person having management skills (level 4, proposal 3), and having enough technical skills to be able to manage the deliverable-related sub-project (level 3). For an activity, manager looks for person(s) having enough technical skills (level 4) to be able to carryout the activity (actions or tasks). 2. Select and sort the corresponding persons, with knowledge about their skill levels and interests, [f there is no result, manager knows the person will be external or to be trained. 3. Contact the selected persons. 4. Receive the assignment proposal. As for procurement, it describes the statement of work, the project, the context, the environment, and the actors already involved. 5. Answer the motivation: as for solicitation process, the contacted persons give an answer about their motivation and their vision of the work to be done and the fixed objectives.

ICED01-C586/563

273

6. New selection and sorting including motivation for the project. 7. Direct Communication / Objective Negotiation / Source Selection / Assignment Contract. Proposal 5: a computer-based tool may help project manager, but the final decision keeps human. The step 7 can not be computerised. Research output: a multi-criteria selection and sorting tool, including skill level, skill interest (step 2), and project interest (step 6). Proposals 3, 4 & 5 are linked, but proposal 3 may be applied independently. Impact 1: an assignment decision reduces uncertainty and waiting risk, but increases the organic risk. A process supported by a standard method and a computer-based tool that is linked with a competence database reduces this risk of error. As the choice of the members of the team may dramatically influence the project results, this is a major gain in the planning process. Impact 2: as the process is standard and the search is automatic, the time will be reduced. Impact 3: as required skills and people competencies are known, process objectivity growths. Impact 4: as each WBS element has an accountable, responsibilities are clearly defined and shared, especially if the decomposition has well managed the interface problem. Impact 5: It is possible to include training plan in the assignment process: people not competent (level 1 or 2 for skill level) but very interested (level 4 for skill interest) can be used after a training period. Impact 6: the process can be used for e-assignment, in the case of distributed, or networked or extended project, with actors not in the same place at all.

4.3. Independent sub-projects planning / budgeting / assignment

As sub-projects contribute to a project, they may have different advancement states. One may already be under development (with actual costs), while another one is just planned (with budgeted costs), another one is just estimated (with estimated costs) or even not (with no idea). Their advancement state can be independently managed. Independent sub-projects advancement state management is part a cognitive process, part a feeling process and part a reporting process. Advancement state management gives stakeholders satisfaction (figure 2). Proposal 1: the management of sub-projects of a project, the management of projects of a programme [3] or portfolio, the management of sub-phases of a phase, and the management of sub-deliverables of a deliverable are similar. Research output: everybody in a project is project manager of something (of the entire project, of a part of the project, of a phase of the project, a deliverable, an activity...), except resources who carryout an activity. Proposal 2: as every project actor is a project manager (except for activities), he (she) should have the required skills (managerial and technical), like leading, communicating, negotiating, problem solving and organisation influencing [4], [5].

274

ICED01-C586/563

Proposal 3: as every project actor is a project manager (except for activities), he (she) should use the same decomposition and assignment processes. Proposal 4: as every project actor is a project manager, he (she) manages its advancement state as an independent parameter. It means that he (she) has an objective, a deliverable, a budget, a deadline, a team, and that the advancement state (estimated, planned, under development, to be corrected, validated) is negotiated with the environment. Research output: a waiting risk estimation is under development to help the manager to report to his (her) environment about the risk of deciding too early and the risk of deciding too late. Impact 1: proposal 1 involves that a project manager of middle-level is the seller for someone, and the buyer for someone else. One time you are in project management (you are the seller), the other time you are in procurement management (you are the customer). Impact 2: as nearly everybody must have some managerial skills, there is a training effort to undertake. The consequence will be more efficient relationships, because of knowledge about the terms, the language, and the basic and common principles or tools. It will be easier to understand each other and to work together effectively. Impact 3: the waiting risk is increased by the choice work / plan / wait for parallel subelements. Indeed, we may wait too much, and be late, or overrun costs by crashing (adding more resources to respect deadlines). In the other side, we may decide too quickly, and be wrong, and must have some rework, or changes in scope, time, cost or quality. Impact 4: as every risk, waiting risk is also an opportunity. So, this independent advancement state management may procure some benefits in terms of time, cost (especially cost of quality) and number of overall changes [6]. As we know that the quality cost may represent 12 to 20% of the total project cost, and that rework and errors due to bad requirements are strong parts of this cost, we can say it is a major gain in the overall planning management. Impact 5: as the risk increases and as the reporting accuracy is not so easy, there is an important place for trust between actors, or between actor and contractors [7].

Generalised multi-project management

The project managers, or sub-project managers, decompose their stuff into smaller and more manageable project (or deliverable). They assign a person accountable for each sub-element. The cycle is the same until they decompose a small deliverable (work package) into activities. Then, one of the Work Breakdown Structure branches is ended, but another branch may still be at a low decomposition level. We may have unbalanced WBS, or plans with some empty parts [8]. At the same time, we may have some sub-projects planned, other ones under development, and other ones validated. The planning is managed with only three functions.

Applications & perspectives

A perspective is the development by student projects of a shareware of some functionality listed above (the proposals' research output deliverables), like decomposition process assistant, assignment process assistant, historical information storage & search, graphical innovations for project vision and online links between project reviews decisions and project

ICED01-C586/563

275

plan. The purpose is that some industrials give money to finance the development of complete software, or of a module for existing software.

Key conclusions

We have introduced some improvements in project planning. They are based on PMI's standards, but many companies, which do not use such standards and so structured processes, may still use our proposals without the PMI's basis. They are independent (even some are linked) and can be applied separately. In summary, we give the project manager help to : decompose the scope of what he is accountable into smaller parts (deliverables or activities), assign accountable person to these smaller parts (if it is deliverable), or carrying-out resources (if it is an activity), manage and report the advancement state of the part he (she) is responsible of, and the risk that is linked with this state.

References [1] [2] PMI Standards Comittee "A Project Management Body Of Knowledge (PMBOK)" 2000 ed., fSBN: 1-880410-23-0, Project Management Institute (2000). Kloppenborg T. & Opfer W. "40 years of PM research: trends, interpretations and predictions". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium, 41-60, Paris, France, June 2000. Eidsmoe "The strategic program management office". Project Management Network, Vol. 14, number 12, 39-45, December 2000. Crawford L. "Profiling the competent project manager". Proceedings of PMf Research Conference 2000: PM Research at the turn of the millennium. 3-16, Paris, France, June 2000. Burnette D. "The new face of the project team member". Project Management Network. Vol. 14, number 11, 61-63, November 2000. Chapman "Project risk management: the required transformations to become project uncertainty management". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium. 241-246, Paris, France, June 2000 Hartman F. "The role of TRUST in project management". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium. 23-28. Paris, France, June 2000. Abramovici "Long duration projects: the fixed rolling schedule". Project Management Network, Vol. 14, number 12, 47-48, December 2000.

[3] [4]

[5] [6]

[7]

[8]

Franck Marie Ecole Centrale Paris, Laboraloire Productique - Logistique, Grande Voie des Vignes, 92295 Chatenay-Malabry Cedex, France, (33)1-41-13-16-06, (33)1-41-13-12-72, marle@pl.ecp.fr IMechE2001

276

ICED01-C586/563

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

APPLYING CONCEPTUAL DESIGN METHODS TO ENGINEERING MANAGEMENT

P Hughes, C Burvill, and R Hughes Keywords: mechanical product design, business process re-engineering, competitiveness, design for manufacture.

Background

A review of the available literature discussing the management of product based innovation led to the identification of the following major objectives, meet market demands; compatibility of proposals to the company's long term strategy; continual generation of innovative proposals; appropriate technology support; a continuing mechanism for validation of decisions; and, maintenance of relationships with external organisations [1,4,8,10,15]. Also identified were the special needs associated with the management of innovation [3,7,13], The use of systematic design methods that provide a formal structure for the definition of problems and evaluation of design concepts [6,10,11] was considered a suitable basis for the development of management tools by a small Melbourne based engineering firm that specialises in mechanical product design (Integra Systems Pty Ltd). Design methods were successfully used to assist the firm in corporate decision making and the logical storage and analysis of information. Further, the tools created within the firm allowed the inclusion of new information over time and assisted in decision making that led to a series of changes to corporate strategy. This paper will provide a brief overview of the experiences of the firm. It is expected that the management techniques described will be applicable to other firms developing innovative products and services.

Introduction

A case study is presented that demonstrates the benefits available from the use of conceptual design methods in strategic decision making, in particular, those associated with evaluation of corporate strategic plans through the use of conceptual decomposition and evaluation matrices [13], The design tools facilitated flexible decision making with regard to the strategic planning, business development and management processes within the firm. The use of formal design methods for product and process development within the firm facilitated their use in the decision making process. This approach has assisted the following decision making processes: select the industry sector or sectors best suited to the firm's overall capabilities (table 1); identify opportunities for activities within the chosen industry sector (table 2); and, derive and continuously refine its company strategies to best exploit the opportunities within the chosen sector (table 4). The case study shows that formal design methods provided the necessary evidence to allow the firm

ICED 01 -C586/594

277

to redirect its business processes when necessary to ensure ongoing survival, either through the preferred approach within the industry sector, or through the choice of sector.

Selecting an industry sector

A new organisation must choose the industry sector into which it intends to make an impact [1]. This can be a simple decision based on experience and capacity. When attempting to introduce innovation to a manufacturing sector, the uncertainties associated with comparing available markets and the attributes of the organisation can be alleviated with an evaluation matrix [11]. Table 1 shows the evaluation matrix used to select the most appropriate industry sector for the firm under review - substituting industry sectors for design concepts, and necessary corporate attributes for design criteria. The overall expertise of the firm dictated that selection would fall within the manufacturing sector. The selection criteria chosen is broadly applicable although the concept ratings are specific to the firm under review. As there is typically no median or datum for comparison when attempting to enter an industry as an innovator, ratings were based on a quantitative scale rather than the alternate '+' or '-' approach, where '0' is the median. In table 1, '!' indicates low certainty or poor opportunity and '5' indicates high certainty or good opportunity. Within the case study, table 1 demonstrated that the firm's mechanical design expertise is high in all aspects of manufacturing engineering and that by reviewing the industry sector averages, the firm's principal areas of expertise were in the sheetmetal and toolmaking sectors. Table 1 also showed that punching and forming from sheet metal coil provided development opportunities.

The design of a business strategy

Morphology is a common tool for the development of alternative design variants [2,10], where a morphological chart will typically consist of rows divided according to the concepts (functions and sub-functions) of a design proposal, with columns identifying alternative solutions for each concept (variable). This approach has been applied to the identification of alternative approaches to business operation (table 2), where rows are divided according to business functions and columns identify attributes associated with the business functions. For the firm under review, this allowed a range of business operation variants to be defined with reference to the necessary concepts required for the business variant to be considered for implementation. The creation of the concepts and solution variables in figure 2 is an ongoing process that effects the attractiveness of alternative business variants. The creation of the business operation morphological chart in table 2 involved an extensive review of the chosen industry sector. Potential Failure Modes and Effects Analysis (FMEA) assists the engineering designer in exploring, to the extent possible, potential failure modes and allowing their associated causes/mechanisms to be addressed and evaluated [13]. This design tool has been applied to the assessment of business operation proposals (table 4) to assess issues associated with possible failure of a proposal, and facilitate quantification of the risks associated with the mode of failure. The modified FMEA in table 4 lists limitations associated with a business operation

278

ICED 01 -C586/594

proposal, describes the possible consequences and the likely causes. Remedial strategies are offered that may be able to correct the cause of the limitation. As for the business operation morphology approach, the use of FMEA to review corporate decision making accommodates ongoing changes to the business organisation and to the available market.

Application to an engineering firm - a case study

The firm under review used the tools described in section 4 to continually adjust its overall business strategy. The firm has attempted the following operational strategies and has been able to identify the strengths and weaknesses of each strategy: a combination of consultancy services and a range of relatively low cost, medium volume products; downgrade consultancy services and introduce a distribution service of internationally sourced high technology components; design and manufacture low to medium volume machines as products for sale that incorporate the sourced high technology components (providing a means by which technologies could be introduced to the chosen market); and, withdraw machines as saleable items and use them within a customised production cell where the technology advantage can be exploited when competing for manufacturing services (allows testing and refinement of the technologies in-house). These operational strategies evolved within the firm and as new proposals were defined, they were introduced to the review process and analysed against the existing strategies. The firm does not align itself to any one strategy to the exclusion of the others but applies the most appropriate strategy to each situation. Table 3 highlights the attributes associated with the product based approach (variant) to business operation identified by the firm from the overall chart (table 2). Opportunities that are outside the scope of the firm are quickly identified using this approach. Uncertain or critical variables are highlighted to assist the decision making process as these are associated with issues most relevant to the business strategy FMEA (table 4). Issues associated with the existing and proposed correctional measures were quantified using risk numbers. Benefits resulting from the introduction of the FMEA approach include: rapid identification of likely critical failure modes and the prediction of associated consequences; quantifying of the impact of the identified modes of failure relative to other modes of failure and to the associated mode following correctional action; and, provide a measure with which to assess proposals for operational changes within the firm.

Conclusions

Formal design methods have been successfully applied to the management processes of a small firm whose principal focus is product and process innovation for the manufacturing sector. Opportunities associated with this approach include: define the strengths and weaknesses of an organisation; formal selection of industry sectors that reflect internal organisational strengths; assess whether a proposed approach to business operation can be accommodated by the available resources; and, predicts whether limitations within the chosen industry sector (e.g. uncertainties and inconsistencies) are likely to be significant impediments to success. The case study demonstrated the successful use of these modified design methods. Applying formal design methods to management processes provided a framework for managing the firm in a creative manner, encouraging human decision making attributes such as intuition and experience. The framework also provides a means of recording and reviewing the opportunities

ICED 01 -C586/594

279

and ongoing changes within the chosen industry sector. As an example, a synthesis of attributes from the alternative approaches to business operation led to the design and manufacture of a sheet metal punching manufacturing cell (figure 1), combining coil based sheet metal expertise, advanced metal punching systems developments, and a well understood and documented overview of the sheetmetal punching industry sector. Using this approach, the company has been able to double its product based turnover each year over the last four years whilst rationalising resource levels through automation and reducing manufacturing costs. References fl] [2] [3] [4] Boag, D.A. and Rinholm, B.L., "New Product Management Practices of Small High Technology Firms", Journal of Product Innovation Management. V6, pp. 109-122, 1989 Blake, R. R. and Mouton, J. S., The Versatile Manager. Scientific Methods, Texas, 1986 Collins, J.C. and Porras, J.I., "Built to last, successful habits of visionary companies". 3rd Edition, Random House, London, 2000 Cooper, R.G. and Kleinschmidt, E.J., "Benchmarking the Firm's Critical Success Factors in New Product Development", Journal of Product Innovation Management. V12, pp. 374-391, 1995 Dieter, G.E, Engineering Design. 3rd edition, McGraw-Hill, Singapore, 2000 French, M.J., Conceptual Design for Engineers. Springer-Verlag, New York, 1985 Hershock, R.J., Cowman, C.D. and Peters, D., "From experience: action teams that work", Journal of Product Innovation and Management. Vol. 11, pp. 95-104, 1995 Lewis, W.P. and Wu, H., "Factors affecting the successful development of new products", Engineering Design Conference. London, 1998 Muncaster, J.W., "Picking new product opportunities", Research Management. Vol. 24, pp. 26-29, July, 1981

[5] [6] [7] [8] [9]

[10] Pahl, G and Beitz, W., Engineering design, a systematic approach. 2nd Edition, Springer, London, 1996 [11] Pugh, S., "Total Design". Addison-Wesley, Reading, MA, 1990 [12] Robson, E., "Organisations of the future", Conference on technology transfer and innovation tti '99. Melbourne, Sep. 1999 [13] Samuel, A.E. and Weir, J.G., Introduction to engineering design. ButterworthHeinemann, Oxford, 1999 [14] Scherer, A. and McDonald, D.W., "A Model for the Development of Small HighTechnology Businesses Based on Case Studies from an Incubator", Journal of Product Innovation Management. V 5, pp. 282-295, 1998 Corresponding author Dr Colin R. Burvill Lecturer, Department of mechanical and Manufacturing Engineering, The University of Melbourne, Victoria, Australia, 3010. Tel +61 3 8344 4545, Fax +61 3 9347 8784, E-mail: colb@mame.mu.oz.au

280

ICED 01 -C586/594

Table 1. Industry sector selection (evaluation matrix) [8]

Industry Sector

MANUFACTURING ENGINEERING
Sheetmetal Working Punch Profile Form Mill Toolmaking Turn General Engineering Structural Eng.

EDM

CNC Profile

Industry 5 5 Experience Educational 4 4 Background Colleagues in 4 4 industry Computer 2 A Tools Plant & 1 0 Equipment Unexploited 3 5 Market Low Tech. 2 4 Sector High Labour 3 2 Content Breadth of 3 5 opportunities No technology 5 5 advancements 32 :;3:8; Totals

1 1 1 1 0 5 4 2 5 5

4 3 4 4 1 1 2 5 1 3

4 3 1 2 0 5 5 2 5 5

4 2 4 5 5 4 5 5 4 5

5 2 2 0 0 1 4 4 1 5

3 4 4 2 0 1 1 2 3 2

5 2 2 0 0 1 4 4 1 5

3 4 4 2 0 2 1 2 3 2

4 1 5 5 0 4 4 1 1 4

2 1 2 0 0 2 2 1 1 4

2 4 2 0 4 1 4 4 4 4

4 2 5 5 5 3 2 4 4 4

3 2 3 1 0 1 3 2 1 4

3 2 3 1 0 1 3 2 1 4

3 1 1 4 0 1 3 2 3 2

3 1 1 4 0 3 3 2 4 2

2 3 1 0 4 1 3 4 1 4

4 2 3 3 5 1 4 4 3 3

2 2 2 0 2 1 3 4 3 3

2 2 2 0 4 1 3 5 3 3

4 2 1 3 5 1 4 3 3 3

1
4 4 0 2 2 1 1 5

23 25 28 32 43 3J 24 21 24 22 29 15 29 38 25 20 20 20 23 23 32 23 22 25 29 25

Table 2. Business operation morphological chart [7] Solution Variables Concepts

a h

f
High Process Labor Content

d
No recent major advancements in technology Synthesis of technologies

!
Low synthesis of 1 technologies , | Offer High i technology Design . and analysis services [ to industry '

Industry Sector Opportunities Company Focus Production Functions Products and Services Business Development Funding Avenue for Market Penetration Barriers / Constraints Personnel and Resources Evaluative Measures / Process Refinement

Identify unexploited markets

Low technology compared to related sectors

Locally produced innovative products

Import replacement

Value-adding imports

Materials Handling

Decoiling and Straightening High cost - Low volume products

Material Feeding

Plate Punching

Plate Forming

I x)w cost - Medium volume products

A combination of 4a and4b

High Technology Products

Value added imported! product ' Joint ventures with ( other companies ! Create productsfrom! synthesis of in-house ' technology Delays in market , acceptance | Industry based research 1 , |

Collaborations with Collaborations with Self funding through Self funding through other high technology R&D institutions consulting services product sales organizations Market through distributors Market need for product / service Product and technology licensing Levels of in-house experience An upgrade path approach to product introduction Available budget and cash flow Use personnel from other companies and research organizations

Market directly

Meet industry sector or market demands

Low technology with High technology with high lahor low labor

Multi-skilled team

Profitability

Market acceptance

_ . Serviceability

! In-house efficiency - Selling horizon (I>ong! | _ vs. short selling cycle)' Cost vs. return

Evidence of Choice of Downsizing of Industry trends companies wanting to undeveloped Manufacturing Sector towards outsourcing specialize production techniques

Market subject to uncertainty

Industry sector inability to embrace change

Stacking and Collating Low volume machines External funding investors and financial institutions

Set-up and Changeover Systems Technology cells and workcenters Technology grants and Government assistance

Manufacturing cells

Virtual 3D Design

Computer Based Failure Analysis

Predictive machine function simulations

Offline CNC programming

Manufacturability

Available company resources

Available technology

Clients downsizing in- Customers' perceived value of product / house production service facilities

Use of contractors Reputation for product and service quality

Access to required tools Repeat orders / ongoing business

Colleagues and associated companies with shared values Customer referrals Customer willing to follow upgrade path Delay in bringing product to market Time for market to accept product

282

ICED01-C586/594

Table 3. Business concepts and solution variables - strategy overlay for "product based" approach. Critical opportunities: low technology market (Ib) with high process labour content (Ic), no recent major advancements in technology (Id) and low synthesis of technology (le). Critical barriers: meeting industry sector or market demands (7a), market need for the product (7b), available budget/ cash flow (7d), delays in market acceptance (7e) and downsizing of in-house production facilities (7i).

1
2 3 4 5 6 7 8 9

Figure 1. Sheet metal punching system - applying the accumulated knowledge of the firm under review within its chosen industry sector.

ICED01-C586/594

283

Table 4. FMEA [10] of business operation ("product based" approach). Risk number (RN) is the product of the likelihood of the business decision failing (O), the significance of the effect that failure on the firm (S), and the liklihood of detecting failure before it adversely effects the ongoing survival of the firm or the chosen business approach (D).

Business Strategy Analysis

Limitation Limited market need for product Product innovation radical and advanced Product range not broad enough to satisfy market High technology products expensive in low technology market Product delivery delays Consequence Slow market penetration Limited market acceptance of product Inability to introduce products without comprehensive range Unable to sell product with adequate profitability Reduced customer satisfaction Delays bringing product to market Limited market acceptance of product

Cause Downsizing of manuf7 7 9 441 acturing industry sector Conservative market buying 8 7 9 504 patterns Range too complex or large 8 7 9 504 to manage with existing corporate structure Manufacturing costs too high Development times exceed market expectations Insufficient funds and resources Incompatibility with existing infrastructure

Existing Situation O S D RN

Suggested correctional measures

Improved Situation

O S D RN

Prototyping and conduct 3 3 3 27 small scale market research 3D virtual prototyping and 2 2 4 16 computer based selling Liaise with other companies with complimentary 3 3 6 54 products Modify products to reduce labor or material expense

8 9 7 504 9 6 8 432 9 8 9 648 8 9 9 648

5 6 8 240

High cost of product R&D Product incompatible with existing plant O = Occurrence Probability of occurrence Very low Medium low Medium Medium high High

Communicate realistic time 2 2 2 8 frame for product delivery at the outset Collaboration with research 5 6 7 210 institutions to broaden available resources Create in-house solutions to 5 7 7 245 compete with users of existing plant

S = Significance Effect on Business Development Barely noticable Not detrimental to business Reasonably serious Detrimental effect on business development 9-10 High negative effects on business development

1 2-3 4-6 7-8

Likelyhood of detection before business is Risk Number adversely effected 1000 I High 1 High 2-3 Medium high 2-5 Medium 125 6-8 Low risk 1 4-6 Medium 9 7-S Medium low 10 9-10 Low

0 = Detection

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

FINDING AND IMPLEMENTING BEST PRACTICES FOR DESIGN RESEARCH ACTIVITIES

M Gardoni and C Frank

Keywords: best practice, Knowledge Management, lessons learned systems, information analysis, classification and retrieval, design reuse

Introduction

The fast changing competitive environment in which most companies operate are forcing them to change their strategies in order to remain competitive. It is within the design activities that most impact on strategic objectives of quality, cost, delivery and flexibility can be made [1]. The challenge of design research is to develop and transfer new design concepts and technologies in order to prepare industrial design units to realise innovations in design methods and technologies. Some main design research activities are : strategic and technology surveillance, to analyse industrial design requirements, to put into context new design concepts, and to transfer new knowledge and technical solutions into industrial design units. Design research activities nowadays are confronted with a rapidly technology and industrial requirement change and therefore might need a support that helps to ensure the performance and capacity for research activities. Indeed, researchers have to spend time to organise and optimise their research processes in order to generate good results with the available resources. This could be a key argument for the use and the identification of "Best Practices". There could be a need to separate out the key and often-used practices and relate these practices to performance in order to present useful guidelines for action [2]. The aim of this paper is to propose a systematic way to optimise daily design research activities by finding and implementing Best Practices. We will describe where and how it could be possible to introduce Best Practices and illustrate our method. Furthermore we will discuss the probably existing relationship between Best Practices and knowledge management systems. We will illustrate that our method could lead to the introduction of a Best Practices Database which could be related with knowledge management activities. Finally, cultural, organisational and technical problems and constraints which are related with the introduction of Best Practices will be discussed.

Definition of Best Practices

According to Carla O'Dell and C. Jackson Grayson JR. "Those practices that have produced outstanding results in another situation and that could be adapted four our situation."

Among various available definitions of Best Practices, we retain two of them [3]:

ICED01-C586/488

285

For Chevron, a large company in the United States, "Any practice, knowledge, know-how, or experience that has proven to be valuable or effective within one organisation that may have applicability to other organisations." Moreover, they distinguish different levels of Best Practices: Good Idea, Good Practice, Local Best Practice and Industry Best Practice.

We consider that the use of the term "BEST" Practice is not suitable because a practice can hardly be the best for all criteria: quality, cost, delay, etc.. Moreover a practice can fulfil the needs within a context but not within another one. We prefer then to deal with "Operational Advices". However, we will retain the term "Best Practices" because it is widely used. To harness Best Practices, we try to characterise their context and criteria in order to take into account most of their influential parameters [4]. To this aim, a special interest is given to use the Pattern approach. The purpose of this approach is to constitute a "Know-how base to solve a problem frequently occurring in a particular field" [5], Moreover, enterprise modelling methods such as CIMOSA [6], with the concept of modelling views and the generation principle, describe the behaviour and the functionality of a system from various modelling viewpoints [7]. These modelling views can be represented by a meta-model. The objective of this meta-model is to be at the same time generic, exhaustive and representative in a certain context. All these views can be related to the description of a design "context". Within this framework, various views of the characteristic elements of this context can be extracted from the meta-models. Moreover, we intend to use a skills model [8] to be able to compare the skills required to use the Best Practice and the skills owned by the users. The difficulty is to estimate the distance between these two instances of the skills model.

Figure 1. An example of skills model

Best Practices Management

Identifying and classifying fields for Best Practices applications for research activities is difficult. Voss et al. [9] argued through their research for the Made in Britain and Made in Europe studies, that companies which have achieved world class status have adopted Best Practices and achieved high performance in operational areas. Therefore, there is an argument to suggest that, by implementing Best Practices at the operational level, operational performance can be improved, and consequently the performance of the overall organization can be improved. Nevertheless, there seems tendency to use this expression for static processes rather than for dynamic ones which both could be placed in the operational level of an organization. Static processes are repetitive whereas the dynamic ones contain innovative

286

ICED01-C586/488

activities, making processes looking different. In an organisation, static processes could be optimised by a mechanism of comparison. So best solutions for common processes and problems can be generated. Design research activities are more or less structured in research processes and oriented by industrial requirements. Several activities in these research processes could be structured and optimised by Best Practices in order to make design research activities more efficient. We propose a formalisation of a method based on knowledge capitalisation cycle [10] to find improvements.

3.1 The knowledge capitalisation cycle

The knowledge capitalisation cycle is characterised by four main steps in order to support the development and reuse of knowledge: locate, memorize, re-use and up-date. These steps can be described by several activities as seen in the figure below.

Figure 2. Knowledge capitalisation cycle [10]

Our method to generate Best Practices is based on these steps and activities. The knowledge capitalization cycle describes the activities how to capture and distribute knowledge. We consider Best Practices as being knowledge elements. This means, every Best Practice can be considered as a knowledge unit or as a defined set of knowledge units what could justify our approach which is based on the knowledge capitalization cycle.

3.2 One method to generate and transfer Best Practices

Our proposition uses criteria on existing processes or parts of processes in order to create a better support for repeated tasks and implement Best Practices. Indeed, there is a need to define the relationship between Best Practices and performance in order to understand which practices should be implemented to improve particular aspects of performance. Performance indicators can and should be used as criteria in order to choose Best Practices and support processes. Our proposition (see also figure 3) begins with the identification and formulation of the need and the objective to improve the operational performance of a process or parts of a process. A specification of the problem and the requirements shows the tasks which could be improved. The need, or objective, should be reflected in the specification of a measure of performance which reflects the area to be improved, and helps monitor change and to identify a new Best

ICED01-C586/488

287

Practice. This phase and the identification of measurers might be difficult because of the lack motivations of the involved person. A common definition, with the help of meetings and interviews, might be helpful in order to identify the measurers. Before one can transfer Best Practices, it is necessary to define and find them: a phase of searching and evaluating of possible solutions. This research can be made inside and outside an organization. Approaches for identifying Best Practices could be: benchmarking teams, best practices teams, knowledge networks, and internal audits [3]. The framework of defined measures of performance specifies then a potential list of Best Practices influencing each measure. This list of Best Practices needs then to be evaluated and prioritised in terms of the strongest positive relationship with the measure, taking into account any negative side effects which could exist [11]. These activities of identification and specification are related to the activities "identify, locate, hierarchize" of the step "locate" of the knowledge capitalization cycle (figure 2). After the identification of the potential Best Practice follows the phase of transfer and adaptation: Transferring means to choose the Best Practices from the list of Best Practices which might be the best solution to improve the process. If necessary, this Best Practice has to be adapted to the new process and its environment. These phases of transferring and adaptation are related to the steps "memorize" and "re-use" of the knowledge capitalization cycle. The transfer and especially the adaptation of new Best Practices are probably the most difficult activities hi order to improve the operational performance. A new practice has to be adapted and accepted by an already existing system, environment, and by people. This system or environment is characterized by its organisation form and habits, by its using technologies and by the people managing this organisation, technology and process. Not only the Best Practice needs to be adapted to the new environment but also the system and the people need to be adapted to the new Best Practice. Therefore this adaptation process needs the competence of the people involved in this process. Methods for identifying the necessary competence [8] have to be applied before and during the adaptation process in order to ensure the necessary competence and resources which help and to transfer and adapt the new Best Practice. The skills model (figure 1) could assist to identify the existing and necessary competence in order to overcome people's problems related to the change of their module of thinking and working. With the help of learning and assisting processes required skills to use the Best Practice should be transformed into owned skills. In order to avoid problems with transfer and acceptance caused by people, the future users of the new Best Practice should be involved in the definition and selection process of this Best Practice from the beginning on. After transferring and adaptation, the Best Practice can be used for the new process. While using the Best Practice it is necessary to measure and evaluate the improvements with the defined criteria and measures described in the phase where the Best Practice was identified. If the expected results are not yet achieved, a re-adaptation of the Best Practice might be necessary. After evaluation of the results and after the complete adaptation of the Best Practice and the system or environment where the Best Practice is implemented, the Best Practice could be added to a "Best Practice Database" in order to make it accessible for other users and for other problems and processes which need to be improves.

288

ICED 01 -C586/488

Figure 3. Generating and transferring Best Practices

As mentioned in figure 3, the activities in order to identify, transfer, adaptation, use, evaluation and storage are representing a cycle of activities. This cycle structure supports our approach which is related with the knowledge management cycle.

Best Practices and knowledge management activities

The formulation and storage of Best Practices allows other actors to have access to different Best Practices. This may help to endure the Best Practices finding and implementing process. Moreover, it is also useful to track existing practices to maintain competitive advantage.

4.1 Knowledge management to support Best Practices transfer and adaptation

The formulation and storage of Best Practices is important. Nevertheless, the simple storage of the Best Practice might be useless if actors do not know the environment and especially the context in which the Best Practice is used. Therefore we propose to formulate and store Best Practices always with their context in which they are used. This helps other actors to identify the useful Best Practices for their problem by comparing the context of the Best Practice with the context and environment of their problem. Knowledge Management activities and methods could help, with appropriate technologies, to give and formulate the context for a Best Practice. An example could be the MICA approach [4]. This specific interactive messaging system has been developed and experimented in order to harness non-formal information and to capitalise relevant information exchanges. Moreover, with other methods and technologies like forums, email, intranet, document management, etc. it could be possible to describe the reasons for the use of a Best Practice, the initial problem, the improvements, the criteria, etc. All these information are helpful for the identification and reuse of Best Practices. Knowledge management methods and technologies could allow to show and to formulate the connection between different use cases of the same Best Practice. One Best Practice might be used for different environments and for different problems and it might be interesting to track and to show the history of development of a Best Practice. The result of the interaction between knowledge management activities and Best Practises transfer and adaptation could be a map which shows the different Best Practices in their different context.

ICED01-C586/488

289

4.2 Best Practices to support knowledge management activities

Knowledge management activities consist of a variety of methods, processes and technologies [12], [13]. Among these processes and technologies it might be possible to identify several repetitive processes or sub-processes. These processes could be supported be implementing Best Practices: Best Practices could help to improve knowledge management activities. There exists differences between knowledge management systems and the method of implementing and transferring Best Practices: A knowledge management system tends to be more complex since it manages evolving knowledge whereas Best Practices only focus on static knowledge. A knowledge management system tries to support dynamic and static processes whereas Best Practices support morels static processes.

Best practices supporting design research activities

Best Practices could help to organise, to improve, and manage design research activities Implementing Best Practices could probably optimise processes and sub-processes used for daily research activities. An example could be the constitution of a research report with Best Practices including propositions like how to structure, format, distribute, etc. a report. Moreover, we think that TRIZ methodology [14] could be useful to standardize design research activities. TRIZ methodology could be described through four main steps: 1. Once you have detected a real existing research problem you try to reformulate this problem in a way that you get a more abstract formulation of this problem. 2. You compare your abstract problem with similar problems. 3. You collect the abstract solutions for the similar problems and try to adapt them to your abstract problem. 4. You try to transform your abstract problem and the abstract solutions in your real problem with a real solution. This methodology shows, by formulating a method how to solve specific problems, that it is possible to introduce Best Practices for research activities and to help to find an efficient way of problem solving. Considering the TRIZ methodology a Best Practice a knowledge management method and technology might help to show, how, why and for which problems TRIZ is used by introducing the relevant context of each problem case where TRIZ is used. This allows actors to generate a map of different use cases of TRIZ with their relevant context, which can help to optimise the use of the TRIZ methodology for different but similar research cases. Another example of a method which could be defined as a Best Practice for design research activities is the functional analyse method. Once industrial requirements for design research activities are defined, it is very often difficult to identify the way of solving the problems and how new concepts and technologies could look like. We propose the functional analyse as a Best Practice in order to find efficiently new solutions, concepts and technologies for given design research problems. The functional analyse could be described through the following main steps: specification of the industrial needs and requirements; description of the context of the following research program (answering the three questions: for who, on what it has effects, what are the objectives); definition of the risks of the research program; description of the context of the system and characterisation of the solution which has to be developed; definition of the different objects, people, environments which could be in relationship with

290

ICED01-C586/488

the system and with the requirements; definition of the functions which need to be integrated in the system or solution in order to connect the different objects and to respond to the requirements; characterisation and description of the different functions. A further example for a Best Practice could be the MICA approach. Design research activities are often project-oriented activities defined through the specific project oriented industrial requirements. The MICA approach could be used by design researchers in order to support the definition and development of new design technologies and concepts in a project-oriented research environment. However, it is essential to keep in mind that Best Practices are based on static and standard rules whereas researchers need a flexible environment. Not every research activity can be optimised by introducing a Best Practice. People and culture are the key to transfer and create knowledge about Best Practices. A company needs a pro-sharing culture in order to be able to motivate the exchange of Best Practices. Elements of a pro-sharing culture are: Personal relationships, common areas of interest and expertise, continuous exchange and creation of new knowledge, learning through teaching and sharing, etc. Organisational and technical support should join the cultural support in order to guarantee an optimal exchange of information. An organisational support could be a monthly meeting of a Best Practices discussion group, a monthly update of company members about new Best Practices, etc. Technical support includes intranet technologies, technologies supporting the exchange of information, etc.

Conclusion

We consider the identification and transfer of Best Practices to be one of the possible tangible manifestations of knowledge management - the process of identifying, capturing, and leveraging knowledge to help organisations to improve their daily work processes and to compete with other organisations. Surrounding the process of identification and transfer, and helping it, are what one could call the enablers: technology, culture, leadership, and measures. These aspects of an organisation's environment and infrastructure must be addressed in order that the transfer process has a chance to work. Nevertheless, every organisation has to find its own enablers. After the identification of a Best Practice could follow the transfer and adaptation of this Best Practice in order to solve the problem related to a process. Moreover, the identification of a Best Practice could lead to process reengineering activities, involving people's competence and organisation form and habits, with the objective to achieve a better performance for this process. Further more, Best Practice development has to keep in mind the human factor. Our approach tends to give "meat - guidelines" in order to realize the transfer of Best Practices and has interfaces with knowledge management methods. However, this approach needs to be experienced in order to detail the different phases and activities. References [1] Kochar, A.K., Davies, A.J. and Kennerley, M.P., Performace indicators and benchmarking in manufacturing planning and control system", in OE/IFIP/IEEE International Conference on Integrated and Sustainable Production Re-engineering for

ICED01-C586/488

291

Sustainable Industrial Production, Proceedings of the conference held at Lisbon, Portugal, pp. 487-94, May 1997 [2] Lynn, B.B., Schroeder, R.G. and Sakakibara, S., The impact of quality management practices on performance and competitive advantage, Decision Sciences, Vol. 26 No. 5, pp. 659-84, September/October 1995 O'Dell, C., Grayson, C.J., If Only We Knew What We Know, New York: The Free Press. 238, 1998 Gardoni, M., Spadoni, M., Vernadat, F., "Information and Knowledge Support in Concurrent Engineering Environments", 3rd International Conference on Engineering Design and Automation, EDA'99, Vancouver, B.C., Canada, August 1-4, 1999 Gzara, L., Rieu, D., Tollenaere, M., "Product Information Systems Engineering: an approach by reuse of patterns", Proceedings of The Product Data Technology conference PDT Europe 2K., Noordwijk, The Netherlands, May 2-5, 2000 Vemadat, F.B., Enterprise Modeling and Integration: Principles and Applications, Chapman & Hall, London, 1996 Gardoni, M., Blanco, E., "Information and Knowledge Support in Concurrent Engineering Environments", 7th ISPE International Conference on Concurrent Engineering, CE'2000, Lyon, France, July 17-20, 2000 Harzallah, M., "Modelisation des aspects organisationnels et des competences pour la reorganisation d'entreprises industrielles , PhD thesis, University of Metz, France, 2000 Voss, C., Blackmon, K., Hanson, P. and Oak, B., "The competitiveness of European manufacturing - a four-country study", Business Strategy Review, Vol. 6 No. 1, pp. 125, Spring, 1995

[3] [4]

[5]

[6] [7]

[8]

[9]

[10] Barthes, J.P., Grundstein, M., "Discussion Summary", 3rd International Symposium on the Management of Information and Corporate Knowledge (ISMICK'95), Institut International pour 1'Intelligence Artificielle, Compiegne, France, October 23-24, 1995 [11] Davies, A.J., Kochar, A.K., "A framework for the selection of best practices", International Journal of Operations & Production Management, Vol. 20, No. 10, 2000, pp.1203-1217 [12] Liebowitz, J., "Knowledge Management Handbook", Boca Raton: CRC Press, 1999 [13] Nonaka,I., Takeuchi, H. "The Knowledge Creating Company. How Japanese Companies Create the Dynamics of Innovation", Oxford University Press, 1995 [14] Cavallucci, D., Beyond the TRIZ limits, The TRIZ Journal, march 1998 Dr Mickael GARDONI GILCO laboratory, ENSGI, 46 avenue Felix Viallet, 38031 Grenoble Cedexl, France, Tel: (33) (0)4 76 57 43 33, Fax : (33) (0)4 76 57 46 95, mail: gardoni@gilco.inpg.fr Christian FRANK EADS CCR, DCR/IT, 12 rue Pasteur BP76, 92152 Suresnes Cedex, France, Tel: (33) (0) 1 46 97 37 02, Fax: (33) (0) 1 46 97 32 59, E-mail: christian.frank@eads.net IMechE2001

292

ICED01-C586/488

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

LATE POINT DIFFERENTIATION ANALYSIS FOR CONFIGURABLE PRODUCTS

T A Lehtonen, A O Riitahuhta, and J M Malvisalo Keywords: Configuration modelling, product methodology, design-for-X. architecture, planning and workflow

Introduction

Late Point Differentiation is an important topic in variant production. This means standardisation early in the manufacturing process and differentiation at the end of the process. It is a cost-effective way of work and it is regarded as universally good principle in designing configurable products. However, reducing the cost of variety is not the only objective driving to use of late point differentiation. In this paper we focus on make-to-order products in a business environment, where delivery time is critical. We present an analysis method, which relates product architecture to the delivery time. Usually the purpose is to minimise the delivery time, by making changes to product architecture. The analysis points out modules, which are critical for the delivery time. This analysis provides information for contemplation, whether product design or production sequence should be altered. In the analysis the relations between sales properties and deliverable features are examined. This is done with a matrix where configuring decisions are related to assembled modules are presented in sequences of sales process and production/assembly process. Critical time line of the delivery is then drawn across the matrix. The relations on the left side of the line indicate acceptable design solution/production sequence, but the relations on the right side are likely to cause problems like re-work in assembly line.

Late Point Differentiation in time critical deliveries

Late point differentiation is often regarded as a tool for manufacturing engineering. However the manufacturing and assembly sequence is only secondary mean to achieve late point differentiation. Product architecture affect as a dispositional mechanism, which allows late point differentiation or ultimately makes is impossible. Applying late point differentiation requires: Product architecture is modular and modular decomposition corresponds to the needed variation. [1] Production sequence is made according to add-on -principle. This means that base units common to all variants could be assembled first and variable parts could be added in later phase of the production. [2]

ICED01-C586/139

293

In this paper we focus on time critical deliveries. In these deliveries there are two more requirements: Production sequences should be optimised for sales-process. In order to be able to optimise the product sequence also the product architecture should be refined (and adapted to requirements of sales sequence).

The late point differentiation analysis is a tool for this. The relations between product architecture and sales-delivery decisions are examined and the result is compared against production sequence. The main idea is shown in figure 1. The relations onwards (descending from top to down) are not a problem, because needed sales decisions are already made when production specification should be frozen. The relations backward (ascending from down to top) are problems, because the production/assembly should start before the specification is ready.

Figure 1. The main idea of Late Point Differentiation Analysis

On the left side of the figure above the decision that are made late in the sales process have relations to modules, which are needed early in the manufacturing process. On the right, there are no such feedback relations and manufacturing can be started simultaneously with sales process. The patterns beside each of the figures show the relational attachment of sales and manufacturing process in function of time.

294

ICED01-C586/139

Starting point of the analysis

The analysis requires a list of modules that are used in a configurable product family. Then modules should be arranged in sequence of production or assembly. The sequence could be also arranged according the lead times, if they are critical. Customer requirements are considered in this analysis as a form of sales (configuration) decisions. These decisions should be arranged in timeline according the sales-process. This is often a difficult task. According our experience, the sales process is seldom defined very accurately. The actual sequence of decisions in sales process is not readily obtainable, while it is critical for the analysis. Therefore, every effort should be given in order to get this information. There should be only one relation between a sales decision and a corresponding module, if the product is engineered according to strict functional module structure. However, this is hardly ever the case. In usual cases there are multiple relations between requirements and modules. The sales decisions are not always selections between pure functional properties and technical solutions often rule out the functional module structure.

Progress of the analysis

The analysis tool is based on asymmetric matrix. The modules of the product are being expressed in rows. The rows are arranged so that they are approximately similar to the production sequence. The first modules are needed in first production sequences. They are represented in first rows of the matrix. Similarly, the last modules, which are assembled last, are in the last rows. This is represented in the figure 2. If the lead times are taken in account, then those modules with longest lead times are in the first rows. The sales decisions are being expressed with columns. The columns are also arranged so that the first decisions made in sales process are in the first columns and the last decisions are in the last columns.

Figure 2. Setting the modules and sales decisions on the matrix.

ICED01-C586/139

295

Every sales decision is being examined and it's effect on modules are pointed out. The strength of the relation is also examined. If a sales decision has an very strong influence on to a module, the value of the relation is set to 9. The value is 3, if the relation is moderate. If there is only minor interaction or correspondence between a sales decision and a module selection, the value is represented with 1. This 9-3-1 division stresses the strong bonding and it is very similar than those used in QFD-method [3]. Analysis can be drawn, when all relations are marked in the matrix. To be able to do this, acceptable time relation between sales and delivery -processes should be drawn across the matrix. Simple diagonal could be used, if delivery and sales-processes would be both linear and synchronous. In that case all relations at the lower left corner of the matrix are forwardtype and will not cause problems. The relations above the diagonal are backward-type and they indicate problems in sales-delivery process. However delivery and sales-processes are seldom, if never, linear and synchronous. Instead there are decisions and tasks that are being made and done simultaneously. The progress is everything but linear. Therefore, instead of simple diagonal a better estimation is needed. In our case, we used workflow diagram as starting point. Suitable workflow diagram is a simple Gantt chart as shown in figure 3.

Figure 3. Gantt chart work-flow diagram.

In figure 3, the tasks are on the rows and the calendar time is running from left to right. The bars show the duration's of individual tasks. Ideally, there would be a one-to-one relation between the tasks and the modules. This means that one task includes manufacturing and assembling one module. In reality this is usually not the case, but tasks are manufacturing stages that are related to many modules. The chart may be converted to show modules by marking the modules to the task where a module is first needed in manufacturing process (or where it's lead time is encountered). The timeline, which would guarantee progress without iteration, is estimated according to this diagram. The example of a result can be seen in figure 4. The fraction line across the matrix shows a similar shape than the workflow diagram. In this case there was one task, which took very much time and is related to many modules. This causes the bulge to the right in the fraction line. In the figure 4 the fraction line shows, which relations between sales decisions and modules are suitable for current sales and manufacturing process. The relations left of line would cause no problem, but relations right from the line would cause iterations in the manufacturing process. The bulge to the right in the fraction line is caused by one task, which takes long time

296

1CED01-C586/139

to perform and requires many modules. The tasks of this kind are problematic for the analysis because it would be critical to know if a module is specified, selected or even needed at the start of the task.

Figure 4. Example of Late Point Differentiation matrix.

Results of the test case

A test case with the proposed tool was conducted in a company delivering heavy mobile machinery. The objective of the company is to deliver configured products instead of earlier project oriented way of work. This will require modular engineering in product development, which should thrive for assemble-to-order approach in production. In this case, only streamlining assembly was examined and lead times were not considered. The product was a revised version of an old product in the test case. As this was a case of revised product, many known problems were already corrected. The result of the analysis showed that product was quite satisfactorily adapted to current production/sales processes. However, many problems were pointed out. It is noteworthy that almost all causes to them were new features in the product. It seems that the aspect of variation is not very much considered, when new features are being designed. In the case of

ICED01-C586/139

297

old features, problems in assembly had been encountered and they were ironed out by gradual product improvements. The need for this kind of analysis at product development stage was acknowledged in the company. The result was verified also by making survey amongst the product experts. The answers had good relevance to results of the analysis. One general notation was that all experts underestimated problems that were in their own responsibility area.

Conclusions

The paper presents a method where late-point-differentiation is analysed using Design Structure Matrix (DSM) type approach [4]. This method does add time element to the relation matrix in the form of critical time line. This is required when analysing Late Point Differentiation and it is a novel approach. Proposed method will also enlarge the focus of late point differentiation thinking. Not only the assembly order is regarded, but also lead times could be taken into account. Late point differentiation analysis is a usable tool for industry with firm methodical background. It provides effective ways for guiding the design and discovering problems in advance. It requires thorough co-operation between sales, design and production people and so encourage applying integrated product development [5]. ACKNOWLEDGEMENTS The authors would like to thank the personnel in the case company for their efforts. We also acknowledge National Technology Development Centre of Finland (TEKES) and the case company for funding the research presented here. References [1] [2] [3] [4] Erixon, G., "Modular Function Deployment - A method for Product modularization", Dissertation, Royal Institute of Technology, Stockholm, 1998 Ishii, K, Eubanks, C.F. "Design for Product Variety. Key to Product Line Structuring", ASMEDesign Technical Conference Vol.2 pp.499-506, Boston 1995 Clausing, D., Pugh, S. "Enhanced Quality Function Deployment", Design and Productivity International Conf., Honolulu, Hawaii, 1991 McCord, K.R., Eppinger, S.D. "Managing the Integration Problem in Concurrent Engineering", Working Paper no.3594, M.I.T. Sloan School of Management, Cambridge, MA, 1993 Andreasen, M.M., Hein, L. "Integrated Product Development", Institute of Product Development, Copenhagen 2000

[5]

Time Lehtonen, Asko Riitahuhta Tampere University of Technology, Machine Design, Box 589, 33101 Tampere, Finland Tel: +358 3 365 2627, Fax: +358 3 365 2307, E-mail tle@me.tut.fi. aor(ajme.tut.fi Jani Malvisalo Fastems Oy, Tuotekatu 4, 33840 Tampere, Finland, E-mail Jani.Malvisalo(5),fastems.com IMechE2001

298

1CED01-C586/139

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

ON THE DESIGN OF SERVICES

R Andrade

Keywords: Service design, design strategy.

1 Introduction
Developed and emerging countries have in the service sector the main contributor to their economic activities. Multitude of services have been and are being created and operated in very diverse environments. Those services are designed somehow. Be it by highly systematic approaches, by pure trial-and-error, or by some combination of these design strategies. Nevertheless, those involved with the creation or operation of services and interested in achieving competitiveness and efficiency may be frustrated with the meagreness of references on services design. Despite the interest raised by the matter in the academy, books dealing with the fundamentals of the subject are few, as may be verified by searching booksellers through the world-wide-web. Two books where the authors apply engineering design methods to the design of services stand alone [1,2]. What is found, on the whole, is the occasional chapter in books on service management and operations [e.g. 3, 4] presenting generic ideas about service design. On the other hand, there is a great deal of information and activity on approaches to engineering design, as epitomised by the ICED series. Remarkably, the word service was nowhere found in the theme, topics, or keyword list sections of the call for papers for the Conference in 2001. Why is there this void? Is it because engineers have nothing to do with services? But they do! Levitt [5 Ch. 3], a keen thinker and renowned author on marketing and management, wrote that in industrialised countries services can be industrialised in three ways: via hard, soft and hybrid technologies and gave a list of examples that would delight any engineer. Hewlett Packard, recognised for its excellence in engineering development, presents in a page related to products & services in its site at the world-wide-web the following topic of its strategic priorities [6], with my highlights: "Create e-services ecosystems that place HP at the center - With its multi-pronged strategy focused both on present needs and on creating a roadmap for the future, HP's printing e-services strategy will drive the development of inventive Internet printing appliances, services and infrastructures that will make printing and imaging as integral to the Internet experience as is e-mail today." Aiming at the creation of ecosystems the company indicates that those appliances, services and infrastructures have to be integrated and interdependent. The development of integrated products and services is the challenge posed to industry these days.

ICED01-C586/480

299

Fundamental approaches to design are reviewed in this paper in order to address services as a solution for satisfying customer needs through a combination of objects, procedures and people. It is proposed that design of services ought to be approached as design of systems where those elements comprising the design solution will come into the system as a result of how design specifications are satisfied rather than induced at the onset of the process. The problem of integrating people as an active thinking part of the solution is discussed.

2 Services versus Products

Designing is basically a process of engendering solutions for satisfying a set of needs. These are organised as design specifications, DS, which is a kind of genetic code of the engendered solution. A complete DS also describe conditions and requirements to be complied by the solution along its stages of development, use and disposal [7]. The most adequate result of this engendering process will be the solution that best satisfies the DS. However, a fascinating characteristic of the process is the possibility of generating several alternative solutions for the same design specifications. Mainly because: i) specifications are not satisfied in exactly the same manner; ii) there are many attributes that are specified in ranges of tolerance; iii) information to elaborate the specifications is imprecise and incomplete. All these allow enough degrees of freedom for the solutions to be varied and yet adhere to the design specifications. A solution may take two fundamental forms. It can be a physical structure, an object such as a cloth pressing iron. It can be a procedure such as a computer programme or a package delivery scheme. Rather than being a natural result of the design process the form of the solution may be induced at the process onset. At this point, asking for the design of a cloth pressing iron will induce rather different results than asking for a mean to keep the cloth without wrinkles. Broader specifications are formulated if hidden assumptions are surfaced and altered when the set of needs is considered. That will facilitate the widening of the field of solutions. Stuart Pugh, always pugnacious about the paramount importance of design specifications as the sole reference for the design activity, proposed the static-dynamic product status as a framework of thought [8, Ch. 19] for broadening up the design specifications when formulated. Broader specifications open up opportunities for innovative solutions that break away from static concepts commonplace. The static-dynamic product status is a necessary consideration in service design. Differentiation between service and product is one of the issues related to service design and management. Package delivery would be immediately recognised as a service and a laptop computer as a product. A major difference between a product and a service, as both are largely perceived, is how people are made part of the design solution. For products, the buyer is solely responsible for its use and operation, like with the laptop computer. The manufacturing company transfers that responsibility to him. Services are processes in which some or all actions required to run them may be done by the service company personnel. The buyer may be passive as when he orders a package to be delivered.

300

ICED 01-C586/480

However, categorising what is a service or what is a product do not help the design process much. Such categorisation is illusive, constrains the conceptual phase of the process and increases complexity. When we look at an automated teller machine, ATM, are we looking at a service or a product? When we use an ATM are we using a product or a service? How relevant is this for the user whose interest is to do her banking transactions? In fact, the ATM is part of a solution system comprising objects, procedures such as software or rules of operations, and people that work together to execute bank transactions satisfying the customer and the service company. What about package delivering? What the customer cares is to have her package safely delivered on time to the right hands at a reasonable cost. What would be the solution to satisfy her needs? Surely it depends on the package itself and how fast and how far the customer wishes it delivered. One person of the package delivery company may easily take an envelope with documents sent to another office a couple of kilometres away on the same road. He may go through very simple procedures for collecting and delivering, may travel on foot, and require no particular object to perform his actions. On the other hand, to take live fish from fish farms to sophisticated restaurants that serve fresh food could require special procedures, specific objects, and involve several service people. When a designer is briefed to provide a solution for the restaurants needs she will be faced with devising objects and procedures to do the job. If these are not fully automatic, the designer will have to employ people to run them. What and how many objects, procedures and people are going to be involved will depend on the conditions constraining the solution and on the adopted design strategy. Instead of being concerned with categorising the solution as a service or as a product, designers ought to be looking for the best solution for the problem posed, obtaining different ones by varying the combination of objects, procedures and people into the solution system. How the elements of the solution system are combined is a design decision based on the business strategies of the service company. The solution system provided by a hammer manufacturer might be restricted to the object hammer. The people to operate it and the operating procedures will be decisions transferred to the customer. A taxi company, in its service, could provide the object car, the personnel to operate it, and leave in the hands of the customer the procedures for going from the origin to the destination. In the service in a surgery ward at a hospital, the objects, the operating personnel, and the procedures are very much within the control of the organisation providing the service. The customer is passive.

3 Designing Services
Most design practitioners will agree that design of services may be approached as design of products as shown in the two books referred at the Introduction. Hollins&Hollins [1] paved the way and brought along some of Stuart Pugh's teachings on total design [9] with whom Bill Hollins had an academic association. Ramaswamy [2] came a few years later under the influence of Clausing's total quality development methodology [10]. These books teach how to structure the service design process and to apply valuable supporting methods and techniques to service development.

ICED01-C586/480

301

Nevertheless, why is it that the word service is not even mentioned in the whole call for papers of an important design conference such as ICED? The hypothesis is that this is due to the presence of people as an integral element of the service process Traditionally, service development and operation rely on human abilities, of both the servicing personnel and the customer, to cope with unpredicted situations and to negotiate ways to have the service process completed. Humans have the marvellous faculty of adjusting to non-conformities or to unforeseen situations in processes. When discussing how services are approached Levitt [5, Ch. 3] wrote that for historical reasons "service took the form of one person's labour for the benefit of another....performing one-on-one highly personalised service....just right to the exact specifications of each familiar customer in the shop....[creating] a presumption that service literally means, and will be best, when one person directly and personally attends another..." Such approach to services may bring flexibility to the service company but may also create undesirable situations. Customers are insatiable. When faced with a serving person that apparently has some power to decide and act upon service processes, a customer may relentlessly pursue the opportunity to have things done his way. In some cases the service company yields to the customers' unexpected demands. A couple of hours at a check-in counter in the airport will reveal several of these. However, fulfilling those demands is not always reasonable, feasible, or desirable to the company. Denying their satisfaction may create insurmountable conflict at the interface between the serving people and the customer to the point of disrupting forever any business with that customer. Person-to-person relationship induced service development and operation to be largely done as an ongoing trial-and-error process of adjustment, thus creating the impression that it is not feasible to project services operating with repeatability, reliability, and robustness by design. Yet, there are several evidences around showing that this is doable. Air travelling is a clear example. Efficient services may be systematically designed and variation in behaviour and mistakes that people are bound to make may be prevented by adequate training, fail-safe procedures, and redundancy of people like a pilot and a co-pilot. The notion that services are basically exchanges between a serving person and the customer shies engineers away from service design since they usually feel ill equipped to deal with human-to-human interactions. On the other hand, non-engineers involved with design of services are also prevented from taking advantage of the immense technological advances available today due to a lack of technology awareness and the perception that only humans can provide what the customer wants. The latter is true for a number of circumstances where human warmth and emotional presence are important. However, in many cases the serving person is only there because long ago the provision for the customer needs was set that way and the reasons for that were never challenged. The banking transaction system supported by ATMs is a case-in-point of successful challenge and change of the traditional clerk-at-thecounter service. Now we may take months without need for seeing or talking to any person in the banking organisation. Concern with human factors in design has increased dramatically in the second half of last century. Largely with greater focus on the customer and lesser on the serving people. The rise of ecological awareness and of enforcement of product liabilities also drew attention to

302

ICED01-C586/480

consequences brought onto the public in general by products or services. Nonetheless, what is understood by design with people in mind, broadly speaking, is the avoidance of circumstances that are uncomfortable, ambiguous, risky, or demand unduly physical or mental effort. On the whole, people are being cared for but they are still passive pieces in the solution system. What is lacking is how, by design, to take advantage to greater extent of human faculties. Designers ought to make an effort to integrate people to the solution system with freedom to apply their intellectual and emotional abilities to run the service process successfully. The intent of this paper was to speculate on the design of services in an attempt to clarify why methods for systematic service design are so rare. I believe that the main reason is the inability to deal with people as an active and thinking element of the solution. Services are processes and service design ought to be approached as a quest for solutions to satisfy customer and company needs through systems that integrates objects, procedures, and people operating in coordination. The problems of designing services are: To devise the service system and define its elements: objects, procedures and people. To engender the objects To develop the procedures To incorporate people regarding their human faculties To integrate the system elements to work in coordination. Designing such systems has to be a multidisciplinary team task involving the fields of engineering and human sciences. A service design team should comprise, or at least involve, engineers, marketers, psychologists, sociologists, anthropologists, and professionals that work as interface between the service company and the public such as sales and help desk people. Such a team, working together from the formulation of the design specifications, will have good conditions to create innovative and efficient services that benefit from technological advances and constructive people behaviour. Some basic steps at the start of the design process are recommended: 1. When gathering information about what is needed and formulating the design specifications, challenge the requirements and constraints in order to surface hidden assumptions that may preclude the generation of innovative solution concepts. The challenge is simply done by asking why or why not are those requirements or constraints there. 2. Look for the solution in terms of an integrated system of objects, procedures and thinking people. Not as product or service. 3. Establish required and desired relationships and interactions between objects, procedures and people in order to integrate the system. 4. Consider the service system as a process in which its parts have to work in coordination in order to satisfy the customer and the company. As for the methods for service design, those that are used in engineering design and are technology independent [8] are just as adequate for structuring and taking the design process to the stage where concepts have to be made real, a transition often called embodiment by engineers. From this point on, specific technical knowledge is required and the methods used in the different fields of study come to play.

ICED 01 -C586/480

303

4 Conclusions
The great difficulty in designing services is how to design people into the solution coping with and using effectively the human behaviour. Such problem remains hidden and unresolved in systematic service design. Yet, design of services might not be as complicated or difficult, as it may seem to engineers. The obstacle posed by the necessity of understanding people behaviour is overcome by multidisciplinary teamwork. However, it is not compulsory to have serving people in services. They should be there as the best alternative to provide customer and company satisfaction. Technology must be applied to provide solutions that prevent people from working in tedious and intellectually undemanding processes. Creative application of technology will generate solutions that will put people in tasks more consonants with their human faculties. Service design is an open and barren area for design engineers. The methods of engineering design coupled with the vast knowledge on human behaviour are powerful tools for the creation of innovative alternatives in services. References [1] Hollins, Gillian and Bill Hollins. Total Design: managing the design process in the service sector. Pitman Publishing, 1991. [2] Ramaswamy, Rohit. Design and Management of Service Processes: keeping customers for life. Addison-Wesley, 1996 [3] Lovelock Christopher H. and Lauren Wright. Principles of Services Marketing and Management. Prentice-Hall, 1999. [4] Hasksever, Cengiz et al. Service Management and Operation. Prentice Hall, 2000. [5] Levitt, Theodore. The Marketing Imagination. The Free Press, 1986. [6] http://e-services.hp.com/infolibrary/white_papers/eserv_print_rev.html accessed in 28/01/2001. [7] Andrade, Ronaldo. "Preliminary Evaluation of Needs in the Design Process", Proceedings of the ICED 91, Zurich, August 1991. [8] Pugh, Stuart. Creating Innovative Products Using Total Design, Addison-Wesley, 1996. [9] Pugh, Stuart. Total Design, Addison-Wesley, 1990. [10] Clausing, Don. Total Quality Development, ASME Press, 1994.

Professor Ronaldo Andrade Departamento de Engenharia Industrial, Universidade Federal do Rio de Janeiro, caixa postal 68507, Rio de Janeiro, RJ 21945-970, Brasil, Tel: + 55 21 562 8562, Fax: + 55 21 290 6626, E-mail: ronaldo.andradetgjufri .br IMechE2001

304

ICED 01 -C5 86/480

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

FUNCTIONAL PRODUCTS CREATE NEW DEMANDS ON PRODUCT DEVELOPMENT ORGANIZATIONS

O Brannstrom, B-O Elstrom, and G Thompson

Keywords: Functional Products, Integrated Product Development, Service Design, Service Management, Competitiveness, Whole Life Cost

Introduction

Traditionally, many companies have developed and sold hardware products, e.g. trucks, engines, telephones, etc. Today these products are likely to contain computer software or control systems, increasing the complexity of product development work. The products themselves also require significant services to support them, many critical for their use and hence their value. Accordingly, Normann & Ramirez [1] argue that it is no longer possible to draw a distinct border between products and services, as all products include services vital for their value. Today, in professional Business-to-Business relations, we believe that the customer is not only judging the value of the hardware, but rather the value of a total offer. This phenomenon is not only a market pressure, but is also a driving force in order to offer the market a unique product through product differentiation. According to Nordstrom & Ridderstrale [2], product differentiation will no longer be about the hardware, but rather through a unique total offer including both tangible and intangible assets, such as knowledge, financial offer, service deals, etc. In our view, this results in a need to further widen the scope of product development work into a "total offer". Although the authors all have their professional backgrounds within the engineering field, we belief that this is a subject that requires an open minded use of knowledge from a number of areas. The objectives of this paper are to describe how a new market situation put new demands on product development organisations. Also, we will propose a structured product (total offer) lifecycle model that integrates all value adding activities within a company. Especially, we aim to determine what demands this new scenario puts on the engineering design activities within a company.

ICED01-C586/606

305

Background

In respect to previous research, the development of a total offer overlaps a number of research areas, including integrated product development (IPD) of goods, service management and development and industrial organisation. In the following sections a brief outline of the salient theory from each area is given.

2.1 Integrated Product Development (IPD)

The areas of IPD and Design Science have produced a lot of research results concerning how to best develop physical products. Results from e.g. the WDK School can be found from the early eighties, and early work done by Hubka [3] is still used as reference for researchers concerned with structured product development models and processes. Other well known example are Pahl & Beitz [4] and Pugh [5] who all present structured frameworks, or models, describing the process of product design. We find the area of design science and IPD being both mature and vital. Still, research in the area have been focusing on physical products, and in line with our objectives we will try to use knowledge from the area as a step stone to a development model in a wider sense. One might argue that the integration in IPD aims to cover development in a wider sense than engineering. This is true to some extent, e.g. Andreasen & Hein [6] include activities apart from engineering in their IPD model, however they do not include services a mainstream item. Although taking into account other aspects apart from engineering, we still find it aimed at marketing, developing and producing a physical product. The generic development process presented by Ulrich & Eppinger [7] includes different types of activities, mainly marketing, design, and manufacturing, but also other activities, such as finance, legal and service. But once again, we find that the development process deals with physical products. There is no process for developing or verifying services. What we like to bring forward with these references is not that they are insufficient to our purpose, but rather that they provide an important framework in the work of developing total offers. Important reasons to adopt a well-defined process in product development are: quality assurance, co-ordination, planning, management and improvement [7]. For a company trying to integrate its value adding activities, these are vital reasons to choose a product development like approach to develop a total offer.

2.2 Changes in the marketplace

Maintaining our view of IPD as a mature and vital area of research, and practice, we still claim that it is no longer holistic enough to cover the needs of every modern company. To understand this we have to understand that the area of IPD has its roots in the paradigm of scientific management, starting with Adam Smith and his pin-fabric that he made famous in late eighteen century England. According to Gronroos [8] most of today's management principles are based on a scientific management perspective, a perspective that focuses economy of scale and mass production [9], Generating customer value within the mass production and mass consumption economy was, and still is, done through selling the customer single products or services. But the means for competition have changed, and the markets are undergoing major structural changes [10]. Gronroos [11] points out maturing markets, an increasing global competition and customers demanding individual offers and treatment as part of the emergence of the post-industrial society. Or in a few words, companies of today are facing increased competition and more demanding customers. In this situation, competition through single products becomes hard, if possible at all, and competitive advantage often has to be found elsewhere. Accordingly, product differentiation

306

ICED01-C586/606

will not only be about the hardware, but rather through a unique total offer including both tangible and intangible assets, such as knowledge, financial offer, service deals, etc. [1]. But as focus is shifted from transactions and products, new demands on how solutions to customer problems are to be developed emerge. Grb'nroos [11] argues that a total service offer must be designed, and that this requires the firm to manage resources such as people, technology, know-how and the customer together with the product.

2.3 Service management and development

According to Gronroos [8] service management is a perspective of a number of disciplines, including operations, total quality management (TQM), organizational theory and human resource management. It includes some general shifts in the focus of management: 1. From the product-based utility to total utility in the customer relationship. 2. From short-term transactions to long-term relationships. 3. From core product (goods or services) quality or the mere technical quality of the outcome to total customer-perceived quality in enduring customer relationsships. 4. From production of the technical quality of products (goods or services) as the key process in the organization to developing and managing total utility as the key process. In a company applying a service management perspective, a traditional product development approach within a specific product development department is not enough as the development of services integrates activities from a number of departments in the company to develop all parts in the service system [12]. According to Edvardsson [10] there are three main components that build up the service offer: The service concept, the service system and the service process. The service system defined by Figure 1 represents the resources required for the service and is important in this context as it implicates vital differences in designing services compared to physical goods. The service system can be divided into two parts, the interactive part (front office) and the support part (back office). It is the interactive part that is visible to the customer.

Figure 1. The Service System (Edvardsson [10])

We will not describe the different parts of the service system in detail, but we would like to emphasise some important points. In the service system the customer has a role as a coproducer and user, while the customer traditionally in the case with physical goods normally have the user role only. When designing a service system we have to keep in mind that although the word "system" is used in this context, it is not a system of natural science, but a

ICED01-C586/606

307

socio-economic system, formed by its cultural and political context. The service system is what Chekland [13] refers to as a "soft system", meaning that it will not have the repeatable and logically predictable behaviour of a technical system. Accordingly, all models of a soft system, e.g. the service system, will not be representations of it, but merely intellectual devices being used to explore them [14]. According to Norling [15], the most significant difference between a manufacturing and a service company is in fact that the service consists of sets of activities that may not be standardised and quality controlled in the same way as with physical products. Also, the interfunctional dependency between e.g. marketing, finance, production and administration are higher in services as they all contribute simultaneously in the service interaction with the customer [16].

Industry survey

An interview study was carried out within Swedish industry to explore industrial perceptions of, and beliefs about, 'total offer' products. As our aim was explorative, a survey approach was selected [17], and interviews were carried out in a semi-structured form with a total of thirteen executives at eight different companies. The interviewees were selected due to their holistic view of the company and typically the persons interviewed where Chief Executive Officer (CEO), marketing directors or, in the larger companies, persons responsible for company strategy or future product concept development. Unfortunately, all companies demanded to be anonymous in all external publications as a condition for their participation due to the sensitive information they shared with us on a strategic level. The companies selected represent different types of companies, ranging from large hardware manufacturers to consultant companies. All of the companies have mainly a business-tobusiness focus although some of their products end up at consumers. Even if all of the companies in the study were Swedish, they all act on an international market, some in Europe and some worldwide. To verify the results of the interviews all interviews where recorded and the participants received a written copy. In some cases the interview results was discussed with the interviewees, but in most cases we just received a positive answer that the result was correct. A text analysis was performed, and being an inductive study we searched the material without prejudiced to find categories to structure the material.

Results

In this section we give a brief presentation of the results from the survey. Two aspects will be addressed, each company's view on how to generate customer value in the future and how that view will affect their development operations. Instead of selling only isolated products or services, the companies want to sell integrated solutions or concepts with responsibility for performance and reliability. This means taking over non-core business from the customer to reach economy of scale and co-ordination spinoffs. Some of the companies emphasised that they wanted to take the knowledge heavy position in the value chain, thus integrating several sub-contractors into a joint offer. Figure 2 below summarizes the answers on how to generate customer value.

308

ICED01-C586/606

Figure 2. Generating customer value categories

The importance of being more closely connected to the customer compared with today was strongly emphasised, and to be integrated in his work processes to understand the true customer needs. Three of the companies expressed that they had to be able to understand the customer situation in order to improve not only their own processes, but also the customer processes. A number of companies brought forward a change in customer and sub-contractor relations. They claim to move away from the traditional buy-sell transactional relationship except for low price large volume goods. Instead they are moving into a more integrated relationship where the boundary between the different companies becomes more diffuse. Company 1 expressed that it was sometimes difficult to even know who to charge or who would get paid, as the integration was so close. All the hardware vendors in this study expressed that they had quite mature hardware processes and only one of them expressed the need for enhancing them further. With that we are not saying that those process are completed or beyond further development work, but it is an indication of where these companies will have to put in their effort in the future. More than anything else it is pointed on the need for service processes. Especially one of the companies (Company 1) is concerned about the performance measurement of services and proposes a hardware-like approach for dealing with services. Also, they claim that only well established work processes could result in services being uniform and scalable. Generally, an important part of future development work will be to develop work processes and procedures for service production. Three of the companies express worries about how to manage the integrated development work of total solutions, especially the integration of hardware with services.

Analysis and discussion

The results from the interview study support our initial assumptions, i.e. the companies in the study want to sell the customers complete solutions with an increased responsibility for function, performance, reliability, etc. But the companies also emphasised a new relation to the customer. A relation where the traditional buy sell relationship was abandoned for collaboration and the achievement of common goals. Generating customer value in the future is to provide the customer with complete solutions to maximise his profit through cooperation. Instead of just selling the customer single products or services, the companies have

ICED01-C586/606

309

to be able to understand and support the customers' value adding activities, or in other words, help the customer in building his value-chain. We propose a model that combines the lifecycle processes of hardware, software and services (Figure 3), which build up the functional product.

Figure 3. Lifecycle model for functional products

Illustrated in this model is the presence of three parallel development processes, each contributing in a combined effort to provide the customer with the desired function. It is important to note that although the processes are pictured as separate, there is obviously a need for a high degree of interaction between the processes. This is especially true in the concept phase where there is a high degree of creativity. The processes steps should not be seen as a strict sequence, rather they tend to overlap each other in practice. It is also important to realise the difference in life-cycle length between the different product components. While the lifecycle for a jet engine hardware, from initial idea to last engine scrapped, is in the order of 30 to 50 years, the embedded software control system might have a life span of ten years and the service might be replaced every year. The concept of functional products that include hardware, software and services has significant implications for engineering designers who have been concerned principally with hardware. It has long been recognised that, under many circumstances, maintenance and failure costs can be as significant as the initial product cost. However, it continues to be a difficult argument to persuade clients to pay high initial costs in the expectation of future savings when selling just hardware. In the case of functional provision, such arguments are redundant. There is no requirement to convince anyone of the need to invest now for future savings when the functional provider decides the optimum balance between initial cost, maintenance and failure costs. The designer then discovers previously unrealised freedoms and has many opportunities for creative thought. A decision may be made to increase initial cost and to spread the cost throughout the expected life of the equipment. Or, initially low cost hardware may be designed that can be supported cost effectively in the field. Alternatively a high value 'core' may be designed for the hardware that forms the basis of periodic remanufacturing. Altogether, there are now opportunities to apply all the life-cycle

310

ICED01-C586/606

cost and design researches that have been carried out under the banner of Terotechnology in recent decades. The difference in nature between the service system and the technical system implies challenges for the development organisation. Being able to handle traditional engineering activities will no longer suffice. In some cases the single employee is to the customer synonymous with the organisation, and it will be his/hers motivation, training and access to resources that will decide the functional products availability. What we must do is to design attractive jobs and a stimulating environment that promotes employees with the right motivation, experience, motivation and enjoyment [10]. It requires integration of all activities in a company, and departments usually without a product development focus, e.g. human resources and after market, will find them selfs being part of a functional product development effort. The time is past when some people in a company developed a product, now everyone in a company will find them self being part-time developers. Managing all these part time developers will certainly require a well-structured development effort. As a service system due to its 'soft' nature is formed and affected by its cultural context, the behaviour of the system will not be obviously transferable between different customers, branches or countries.

Implications

Industries competing in today's changing market will have to carefully consider how to approach the problem of functional product development. Especially, the after-market activities must be considered as an integrated part of the product and accordingly developed. Research in the area of development of functional products overlaps different areas in the research society. Future research must fill out the gap between the long research traditions within service management and integrated product development, the former traditionally a business school subject and the latter traditionally an engineering school subject

Conclusions

The literature survey indicates that there are changes in the marketplace that makes it hard to achieve product differentiation, i.e. a competitive market situation, through hardware products only. Instead, competing effectively in the market place will require a broader perspective on value creation. Companies have to combine all their value adding activities into complete offers, or functional products. The function provider takes an extended responsibility for the product through its lifecycle. Our survey in industry supports these findings and expresses a need for integrating the development of hardware, software and services into complete offers. Although making valuable contributions, we belief that the literature on IPD and design science does not cover these needs. Therefore this paper has propose a model that combines the lifecycle processes of hardware, software and services, which build up the functional product. Further work will have to examine carefully the interactions between the different processes, especially how to handle concept development when the different life cycles of the functional product components differ greatly.

ICED01-C586/606

311

References [I] [2] [3] [4] [5] [6] [7] [8] Normann, R. and Ramirez, R., "Designing Interactive Strategy. From Value Chain to Value Constellation". Wiley, U.K., 1994. Nordstrom, K. A. and Ridderstrale, J., "Funky Business - talent makes capital dance". BookHouse Publishing, Stockholm, Sweden, 1999. Hubka, V., "Principles of Engineering Design". Butterworth Scientific, London, U.K., 1982. Pahl, G. and Beitz, W., "Engineering Design: a systematic approach". Springer, London, U.K. 1988 Pugh, S., "Total Design - Integrated Methods for Successful Product Engineering", Addison-Wesley Publishing Company, Wokingham, UK, 1990. Andreasen M. M. and Hein, L., "Integrated Product Development". IPS (Publications) LtdVSpringer-Verlag, 1987. Ulrich, K. T., Eppinger, S. D., "Product Design and Development". McGraw-Hill, 1987. Gronroos. C., "From Scientific Management to Service Management. A Management Perspective for the Age of Service Competition", International Journal of Service Industry Management. Vol. 5, No. 1, 1994, pp.5-20. Piore, M. J. and Sabel, C. F., "The Second Industrial Divide". Basic Books, U.S.A., 1984.

[9]

[10] Edvardsson, B., Gustavsson, A., Johnson, M. D. and Sanden, B., "New Service Development and Innovation in the New Economy". Studentliteratur, Lund, Sweden, 2000. [II] Gronroos, C., "Relationship Marketing: Challenges for the organisation", Journal of Business Research. No. 46, 1999, pp.327-335. [12] Gronroos, C., "Marketing sevices: the case of a missing product", Journal of Business & Industrial Marketing. Vol. 13, No. 4/5, 1998, pp.322-338. [13] Chekland, P., "Soft Systems: a 30-year retrospective". John Wiley & Sons LTD., U.K., 1999. [14] Kemmis, S. and McTaggart, R., "Participatory Action Research", Handbook of Qualitative Research. Sage Publications Inc., U.S.A., 2000. [15] Norling, P., "Tjanstekonstruktion" (Service Design). PhD dissertation, Stockholm University, Stockholm, Sweden, 1993. [16] Gummesson, E. "Truths and myths in service quality", Journal of Quality & Participation. Vol. 18, No. 6, 1995. [17] Yin, R. K., "Case Study Research. Design and Methods". Sage Publications, U.S.A., 1994. Oskar Brannstrom Lulea University of Technology, Division of Computer Aided Design, Polhem Laboratory, 971 87 Lulea, SWEDEN, Tel: +46 (0)520 93685, Fax: +46 (0)520 98553, E-mail: oskar.brannstrom@cad.luth.se, www.luth.se IMechE2001

312

ICED01-C586/606

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

HOW MISSIONS DETERMINE THE CHARACTERISTICS OF PRODUCT DEVELOPMENT METHODOLOGIES

B Bender, B Bender, and L T M Blessing Keywords: prescriptive models of the design process, process modeling, systematic product development, change processes, mission in product development

Introduction

The aim of this paper is to examine the suitability of design methodology to meet today's challenges of product development by looking at the mission behind the evolution of these methodologies. In change management as well as in work psychology having a mission ('Leitbild' in German) is known to be crucial to any change process or work organisation and structuring process. "Mission" will be understood as the idea of a desired, ideal state and the boundary conditions to be considered. The mission determines not only the desired state, the "To-Be" state, but also the view on the current state, the "As-Is" state, and the selected way to get from "As-Is" to "To-Be". This means that to be able to judge the appropriateness of a design methodology for solving particular problems, it is necessary to know the mission underlying this methodology. Furthermore, a reorientation of design methodology to meet today's challenges requires rethinking of the mission of product development rather than trying to adapt existing strategies to today's specific boundary conditions. This paper is of the 'speculation' category, evolving an idea, not reporting scientific results. It therefore focuses on the introduction of a new approach without strong empirical evidence and shall be seen as a contribution to a hopefully extensive discussion.

Challenges of Product Development and the History of Design Methodology

As early as 1972, Beitz listed the following challenges in product development to point out the need for a design methodology ([1], S. 6): increased complexity of products to meet increasing requirements regarding technical performance and quality; tighter market requirements concerning development time and manufacturing costs; shorter innovation time due to rapidly changing technologies; increased accountability in product development regarding schedule and cost of the product; limited rationalisation in product development compared to other departments;

ICED01-C586/489

313

required integration of development with manufacturing; increased deployment of computers, also in product development; shortage of designers.

At first glance little seems to have changed. Due to globalisation and the increasing integration of the customer's viewpoint, some of the issues have become even more challenging and none of these has yet been solved satisfactory. Reality in engineering design departments has changed, but this had had little impact on the formulation of design methodologies. The following paragraphs apply to a variety of common design methodologies, but refer mainly to the design methodology according to Pahl and Beitz [2], which is very similar to the German guideline VDI 2221 [3]. The haydays of German design methodology can be set around the 1970s. The early approaches mainly aimed at supporting design teaching [4], Designing was regarded as a process of problem solving during which complex and contradictory requirements had to be met. Psychological findings on problem solving were combined with strategies from systems engineering. These were adapted to the (former) conditions of product development and resulted in a guideline consisting of working steps to be carried out sequentially to obtain certain specified results. Design methodology today has not changed much since the 1970s. Numerous research projects (some of them can be found for example in [5]) showed that, in general, guideline VDI 2221 is useful for individual design processes, provided it is applied flexibly. Still, in industry design methodology is not widely considered to be helpful in meeting the requirements of product development and often regarded as too time-consuming. What are the reasons for this obvious lack of practicability of design methodology, even though it is proven to enhance designers' capabilities to find appropriate solutions to design problems?

Importance of the Mission

According to work psychology, a problem, as opposed to a task, is characterised by a barrier (e.g. lack of information) between an identified "As-Is" and a desired state "To-Be". Problem solving involves finding a way to get to the "To-Be" state [6]. Design methodologists applied the concept of problem solving to both the design problem and the design process. The psychological concept of "problem solving" has been transferred directly into a practical guideline for solving design problems. In doing so, the fact that the assessment of the "As-Is" state as well as the estimation of the "To-Be " state are highly subjective, has been neglected. Factors that influence problem understanding are ([7], S. Ill): insight in the problem space and its boundary conditions; familiarity with the solution space and its boundary conditions; mission behind the "As-Is" analysis.

314

ICED01-C586/489

Particularly the latter has not been considered sufficiently and explicitly in product development methodologies. Problem solutions can be of a completely different nature depending on the discrepancy between the ideal state and the anticipated problems or solutions. For example in the 1980s the very same market situation lead to two opposite concepts for industrial work organisation: humanisation of labour through semi-autonomous teams e.g. [8]. Computer Integrated Manufacturing (CIM) and the unmanned factory e.g. [9].

Applied to design methodologies two important statements can be derived: The mission from the 1970s, representing the image of the ideal design process and the problems to be solved, has to be clarified. A mission for today's product development processes has to be formulated. These missions must then be compared to find elements of design methodology that are still relevant and those that might have become redundant. To be of practical use, a design methodology must reveal its underlying mission to enable potential users to judge the suitability of the mission, and thereby the particular methodology, for their specific problem.

3.1 Optimisation of Product Development in the 1970s and Today

The aim of rationalisation in product development in the 1970s was the "taylorisation" of the process through standardisation and optimisation, analogous to the strategies in manufacturing. With this aim in mind the overall task of product development was divided in partial tasks to be executed by single persons or within particular departments within the company. The use of computers aimed mainly at the automation and substitution of human workforce rather then its support. The integration of the results of partial tasks took place higher up the hierarchy, requiring equally specialised knowledge in these positions. Planning and control was based on the elaboration of rather detailed results at long term and also took place in higher levels of hierarchy. Due to the kind of problems to be solved as well as the corporate structures in the 1970s, product development could mainly take place within one single unit of organisation or domain. The number of disciplines and groups involved was low compared to today. The integration of product development activities in the company's organisation structure and workflow usually resulted in clear areas of (managerial) authorities for everybody involved in the product development process. The strategies of design methodology match the boundary conditions from the 1970s named above. To be able to estimate the use of these strategies to meet today's challenges the former boundary conditions have to be examined and compared to today's aims and strategies. Due to the current market situation, globalisation as well as the need for multidisciplinary problem solutions and the parallelisation of product development processes today's aims and strategies are integration, cooperation and coordination of various disciplines and institutions in product development projects. The importance of information exchange as well as effective and efficient communication and cooperation processes within and between (units of) organisations increases strongly. Today, self-organisation, self-management, short feed back circles and flexible target planning replace detailed top-down planning of working steps and the resulting long iteration loops.

ICED01-C586/489

315

What conclusions have so far been drawn from these changes to find approaches to optimise product development processes? Current efforts can be distinguished in two main lines: technology oriented or human oriented strategies. Technology oriented optimisation of product development The availability of information and the consistent and general management of data are considered to be the main problems to be solved throughout the product development process, which leads to the development of specialized hard- and software to support designers in fulfilling their tasks. The aim is to store and process the designers' expert knowledge in information systems and in the long run to increase automation of (partial) product development tasks. Human oriented optimisation of product development Coordination and cooperation processes are considered crucial for the success of product development, which leads to new concepts for management processes that are based on motivation, goal analysis and review. Therefore not only domain-specific competencies but, methodical as well as social competencies of designers play an increasingly important role. The acquisition of these competencies takes place in an organisational and personal learning process which has to be integrated into corporate structures.
Table 1. Technology and human oriented strategies for the optimisation of product development processes

technology oriented goals subdivision of the overall process in partial processes automation of as many partial processes as possible high availability of information through universal data concepts (process chain) management process partially automated by supporting software workflow determined by software determination according to supporting software cross functional parallel-hierarchical approach overlapping authorities in matrix structures clear authorities required for data management in process chains depend on the use of supporting software independent from the individual individual is responsible for collecting relevant information

human oriented optimisation of cooperation and coordination performance motivation and integration of the collaborators high availability of information through organisational integration (shallow organisation) target planning delegation of management functions to lower levels of hierarchy self management in teams determination by all collaborators via targets cross functional integrated approach overlapping authorities in matrix structures

management model and principles organisation structure and workflow managerial authority

feedback, iteration loops information flow

short loops because of regular information exchange in teams related to the individual individual is responsible for providing and requesting information

In table 1, characteristics of technology oriented and human oriented strategies to optimise product development processes are compared. To discover the mission behind each approach

316

ICED01-C586/489

ideal types are described what means that each strategy focuses on the elements listed above but does of course not totally neglect elements of the opposite strategy. In reality elements of both strategies often occur as a mix, but mostly with an emphasize on one of the approaches mentioned above.

3.2 Missions related to these Strategies

The comparison of the technology oriented and human oriented strategy shows that these are based on fundamentally different missions about aims and problems in product development processes.

Figure 1. Different solutions to the same problem depending on the underlying mission of product development

The technology oriented mission says that In theory the process of product development can be fully automated, in practice this is hindered by problems resulting from the transfer from knowledge of designers to computer data and the performance of current hard- and software. Available information will be searched and retrieved by designers and interpreted correctly according to the actual problem to be solved. Therefore large amounts of data have to be made accessible for as many collaborators as possible.

The human oriented mission says that The key factor for the success of product development is the human being. Therefore appropriate strategies have to be found to identify and clarify the aims of product development from the viewpoints of the collaborators. Simultaneously the integration of individual and organisational goals has to be aimed for. Information does not make sense by itself but becomes useful within a particular situation or context of cooperation and communication. Therefore in product development (cooperation) situations have to be created that enhance the effective and efficient exchange of information of the collaborators. Information technology is needed to support - as opposed to replace - human design activity.

When examining current approaches for optimising product development it becomes clear that these are based, to varying degrees, depending on the particular approach, on one of the missions (or parts of these) described above. The missions behind the approaches are rarely made explicit: looking at their specific characteristics facilitates only an implicit conclusion on the underlying mission. Knowing this, it is easy to explain why there is no such thing as the "right" design methodology. Different strategies can be valid in different coordinate systems, analogous to mechanics. But revealing the mission - the coordinate system - enables on

ICED01-C586/489

317

the one hand the transfer of universal elements into other applications. On the other hand this allows a focused discussion on missions in product development, without getting lost in argumentations about details of characteristics of specific approaches.

3.3 A new Design Methodology based on Human Oriented Strategies

In this paragraph a new approach to design methodology will be presented. Starting point is the design methodology according to Pahl and Beitz [2]. This methodology was chosen because numerous research projects over the last decade in Germany dealt with its suitability to enhance effective and efficient product development processes. In addition, the authors of this paper have experience with the application of this design methodology in teaching and practice. The mission of the following strategy is human oriented and says in particular that: Cooperation is a key factor for successful product development. The increasing need for multidisciplinary problem solutions, increasing complexity of products to be developed, and the globalisation of markets, lead to problems that cannot be solved by single designers or within single domains. Therefore engineering design management must match these conditions and is of increasing importance. The quality of cooperation processes depends not only on social skills of the individual but also on other boundary conditions. The individual designer cannot be the only party to be held responsible for successful cooperation. For example corporate culture, organisation structures, workflow, the leadership attitude, or the kind of task to be fulfilled equally influence the quality of cooperation processes. Managing effective and efficient cooperation processes can be learnt and must be learnt. Cooperation and communication can be enhanced by specific boundary conditions and supported by specific methods. Therefore an appropriate training and the reflection of cooperation situations within the design process improve cooperation performance. Finally, the success of this process of 'life-long-learning' very much depends on the formulation of an explicit mission.

The proposed strategy aims at the optimisation of product development through implementing a corporate culture of individual and organisational learning and the optimisation of cooperation and communication processes. A detailed description of the strategy, called Goal Oriented Cooperation Management in Product Development, can be found in [10]. Basic elements of this strategy are (see figure 2): A model of analysis providing parameters that determine cooperation processes. These apply to entire product development projects as well as to single team meetings. The parameters are: personal boundary conditions, institutional boundary conditions, goals/objectives, contents/subject, methods applied, and the media used [11]. A process model for product development focusing on the integration of management functions into the product development process. The model consists of elements of design methodology according to VDI 2221 (workflow and design methods), elements of Project Management (management and phase concept), and the management attitude as well as cooperation methods, e.g. the concept of semi-autonomous teams well known from manufacturing.

318

ICED 01 -C586/489

A strategy for the implementation of Goal Oriented Cooperation Management in Product Development in practice. The implementation strategy consists of a combination of elements from organisational development and experiential learning (the latter according to Kolb [12]). The reasons are that the workflow in product development has to be changed, and the collaborators have to learn how to manage efficient and effective cooperation processes based on the above described model.

Figure 2. Characteristics of Goal Oriented Cooperation Management in Product Development

Conclusion

This paper highlighted the importance of the underlying mission for understanding characteristics of strategies for the optimisation of product development processes in general and design methodologies in particular. Based on theoretical findings on factors influencing the idea of a current state and the desired state, we showed that completely different ways of dealing with the very same problems can be found. To clarify this, two different views about the current problems in product development were presented: the technology oriented and the human oriented approach. It is obvious that the fundamental differences between the underlying missions prevent the development of a universal design methodology. Still, there is a need for new strategies in product development since the boundary conditions and thus the missions fundamentally changed since the 1970s. So far, attempts to adapt the VDI 2221 design methodology only went as far as changing isolated details (for example its flexible application in iteration loops as opposed to sequential workflow, or computer support for particular design tasks). As long as there is no common understanding about missions in product development, a discussion about a universal design methodology is not fruitful. We have tried to start this discussion by introducing our human oriented mission and the core elements of an approach to a new - in the sense of adapted to today's challenges - design methodology that were derived from this mission.

ICED01-C586/489

319

References [I] Beitz, W., Systemtechnik in der Konstruktion, in: Rau, J. (Ed.), Vortrage und Diskussionen in der Sitzung der Arbeitsgruppe Forschung und Technik der Arbeitsgemeinschaft fur Rationalisierung des Landes NRW am 8. Marz 1972. Verkehrs- und Wirtschaftsverlag, Dortmund 1972, p. 6-21 Pahl, G., Beitz, W., Engineering Design: A Systematic Approach. Springer, London 1996 VDI 2221: Verein Deutscher Ingenieure (Ed.), Methodik zum Entwickeln technischer Systeme und Produkte, in: VDI-Richtlinien. VDI-Verlag, Dusseldorf 1993 Miiller, J., Arbeitsmethoden der Technikwissenschaften: Systematik. Heuristik. Kreativitat. Springer, Berlin 1990 Ehrlenspiel, K., Practicians - How they are Designing? ...And Why?, in: Lindemann, U., Birkhofer, H., Meerkamm, H., Vajna, S. (Ed.), Communication and Cooperation of Practice and Science. Proceedings of the 12th International Conference on Engineering Design. Schriftenreihe WDK 26, Technische Universitat Munchen 1999, p. 721-726 Hacker, W., Allgemeine Arbeitspsychologie: psychische Regulation von Arbettstatigkeitea Huber, Bern 1998 Daenzer, W., Huber, F., Systems Engineering. Industrielle Organisation, Zurich 1984 Spur, G., Automatisierung und Wandel der Betrieblichen Arbeitswelt, in: Akademie der Wissenschaften zu Berlin (Ed), Forschungsbericht Bd. 6. de Gruyter, Berlin 1993 Brodner, P., Pekuhl, U., Ruckkehr der Arbeit in die Fabrik. Wertbewerbsfahigkeit durch menschenzentrierte Erneuerung kundenorientierter Produktion. Insitut fur Arbeit und Technik - Wissenschaftszentrum Nordrhein Westfahlen 1991

[2] [3] [4] [5]

[6] [7] [8] [9]

[10] Bender, B., Zielorientiertes Kooperationsmanagement in der Produktentwicklung. Diss. TU Munchen 2001, http://tumbl.biblio.tu-muenchen.de/pubVdiss/mw/2001/bender.html [II] Bender, B., Kiesler, M., Beitz, W., A Model of Analysis to Improve Teamwork Perfomance, in: Lindemann, U., Birkhofer, H., Meerkamm, H., Vajna, S. (Ed.), Communication and Cooperation of Practice and Science. Proceedings of the 12th International Conference on Engineering Design. Schriftenreihe WDK 26, Technische Universitat Munchen 1999, p. 177-183 [12] Kolb, D. A., Experiential Learning - Experience as the Source of Learning and Development. Prentice Hall, New Jersey 1984 Dr.-Ing. Beate Bender Bombardier Transportation, Advance Engineering, Kablower Weg 89, D-12526 Berlin, Germany, Tel.: ++4930 6793-2554, Fax: ++4930 6793-2237, E-Mail: bbender@transport.bombardier.com Dipl.-Ing. Bernd Bender, Prof. Dr. Ir. Lucienne Blessing Technical University of Berlin, Dept. of Mechanical Engineering and Transport Systems, Engineering Design and Methodology, Sekr. H 10, Strasse des 17. Juni 135, D10623 Berlin, Germany, Tel: ++4930 314-24309, Fax: ++4930 314-26481 E-mail: bernd.bender@ktem.tu-berlin.de IMechE2001

320

ICED01-C586/489

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

VISUALIZATION TECHNIQUES TO ASSIST DESIGN PROCESS PLANNING

P J Clarkson, A F Melo, and C M Eckert

Keywords: planning and workflow methodology, risk analysis and management

Introduction

Design process planning is an essential part of new product development. Effective planning, along with the skills of the development team, go a long way to determine the eventual market success (or failure) of a new product [1], Indeed, for every new product there will be a best possible design process that achieves an 'ideal' balance between the technical requirements of the product and the commercial aspirations of the company. A successful planner needs to be aware of constraints imposed on the planning process not only by resources but also by the process itself. However, in design the process is difficult to define before its has began. In addition, requirements change as design processes and the planned activities are not guarantied to be successful. Hence, any support for planning must cope with this dynamic nature of design. The aim of this research is to improve the effectiveness of design process planning by defining novel ways to generate and visualise alternative plans.

Approach

The requirement for improved visualisation of alternative plans emerged from earlier work on the capture and analysis of task-based design processes [2]. In particular, there was a need to investigate a wider range of alternative plans and provide some indication of their relative merits. A review of existing planning models was undertaken with reference to a number of specific case studies. Their relative strengths and weaknesses were assessed and requirements derived for a new approach that would improve visualisation of the underlying process characteristics. A number of alternative models were investigated and adapted to meet these requirements. The preferred approach was then evaluated with further case studies taken from a wide range of design processes.

Design process planning

As in chess, in design planning good moves can lead to early victory, resulting in a cost effective design and a good product. So what defines good design process planning? In order to answer this question it is necessary to know something of the number and characteristics of all possible design routes. Then, when presented with a choice of tasks, the most appropriate task may be chosen in the light of its associated downstream process. Process planning is therefore dependent upon identifying key attributes that characterise the process.

ICED 01 -C5 86/065

321

These attributes include: tasks which may be performed in parallel or must be performed sequentially; task clusters which may be grouped to form larger coordinated activities; potential bottlenecks in the design process; process routes which incur the lowest risk of overrun.

There is increasingly a need for effective planning techniques that address these issues, balancing the process characteristics with the available resources to choose the best design route. The following sections discuss a number of process representations and risk assessment techniques with reference to a simple twelve-task model of mechanical component design.

3.1 Visualising the design process

A number of visualisation methods commonly used in design process planning have been investigated (Figure 1). Gantt and PERT charts are traditionally used to aid visualisation of complex processes and to assist in resource allocation [3]. A combination of these charts, coupled with resource planning and critical path analysis, remains a simple and often effective means of process planning. However, whilst the first and last tasks are clear, the ordering of the intermediate tasks and alternative design routes are not.

Figure 1. Typical design process representations

Alternatively, a design process may be represented by a Design Structure Matrix (DSM) [4, 5] using knowledge of task precedence (Figure 2). The DSM identifies specific tasks (columns) which must be performed before other tasks (rows). A reordering of the DSM can then reveal serial, parallel and interdependent task clusters, where the latter may then be grouped to form larger coordinated activities. Although the DSM reveals task interdependence, it says little about the potential bottlenecks and the risk associated with of the resultant design process. There remains a need for a method to aid visualisation of the individual design routes as part of the process of task evaluation and selection. A task sequence diagram (Figure 3), which makes all routes and decision points explicit, is useful in this respect. This is an expansion of the PERT diagram that allows multiple instances of each task, therefore enabling tasks sequences as well as task precedence to be shown.

322

ICED01-C586/065

Figure 2. The Design Structure Matrix

The links between the tasks in Figure 3 represent explicit design states. An alternative is the design state network (Figure 4), where design states, defining particular states of completion of the design, are linked by the design tasks.

Figure 3. Task sequence diagram

The task sequence diagram uses the tasks as nodes in a network linked by parameter states, defining particular states of the design parameters. The design state network removes some redundancy by using the parameter states as nodes linked by the tasks. As a result it is always simpler in form. It relies on the assumption that a given design state can be reached by a number of different routes and can be derived directly from the task sequence diagram. This is consistent with observations of a number of design processes made by the authors [2], though its general validity requires further investigation.

Figure 4. Design state network

ICED 01 -C5 86/065

323

In summary, the design structure matrix and PERT chart are very useful for capturing task dependencies, but limited in their ability to assist visualisation of possible design routes. Similarly, the Gantt chart is useful for identifying the time available for task execution, but misleading in its suggestion of a potential process. Conversely, the task sequence diagram shows all possible routes, but appears too complex. Finally, the design state network also identifies all possible routes, but with much reduced complexity when compared to the task sequence diagram. Therefore, it is proposed that the design state network, with its combination of simplicity and completeness, is used as a basis for visualising possible design process routes and identifying the lowest risk routes. The following section discusses possible methods of constructing design state networks and the provision of addition information to assist design process planning. A particular focus here is on the identification of individual tasks within the network.

3.2 Visualising the design state network

There are a number of network construction methods, based on knowledge of possible design states and their associated linking tasks, which can provide adequate separation of the network nodes. The design state network may be drawn manually (Figure 5). Here the separation of states is easily achievable, but the unique identification of tasks is difficult to achieve and a more methodical approach to network construction is required.

Figure5. A manually drawn network

An alternative is the tangent method, an easily automated process that can be used to draw the design state network. It allocates specific line gradients to individual tasks, attempting to maximise the separation of states. It achieves this by allocating gradients with the greatest possible angular separation to tasks emanating from states that exhibit the greatest process divergence (Figure 6). For example, the three tasks emanating from state 27 in Figure 4 are represented by lines of high angular separation in Figure 6. Those states with the largest number of tasks are draw first to ensure that adequate angular separation is achieved. Hence, the tangent method produces a network with well separated states and uniquely identified tasks. In addition, prismatic structures emerge in the network that identify groups of tasks (for example, between steps 2 and 5) which may be done in any order or in parallel.

324

ICED01-C586/065

Figure 6. A tangent network

The tangent method, in particular, produces a useful diagram, which enables identification of tasks by the gradient of the network links. A further benefit is the identification of serial and parallel task groups. A number of other representations have been explored [6], but none provide quite the clarity of the tangent diagram. This is further illustrated by Figure 7, a plot for a 27-task model of mechanical design. The extended mechanical design process is characterised by an initial serial sequence (a) followed by a short parallel sequence (b). This is then followed by two large task clusters (c and e), separated by a bottleneck (d), and concluded by a final short parallel sequence (f). These characteristics have major implications for the success of the process. In particular, it is important to understand the nature of the bottleneck and whether it represents a particular risk to the project. The task clusters also highlight potential for extensive parallel working and the need for resources to be available concurrently.

Figure 7. A tangent network for a 27-task model of mechanical component design

Risk management and design process planning

Despite the benefits of the tangent diagram in characterising a design process, there is as yet there no indication as to which design process route provides the best balance between

ICED 01 -C5 86/065

325

technical and commercial risk. To meet this need, a method that is often used to assess possible design process problems has been adopted. It uses a likelihood / impact graph (Figure 8) to represent possible technical and non-technical risks, where each risk is assessed qualitatively for its likelihood of occurrence and impact on the design process [7]. Risk management procedures are then implemented to reduce unacceptable risks.

Figure 8. The likelihood / impact graph

The impact in this context may be chosen to be, for example, cost of development or time to product launch. The usefulness of such a method is then critically dependent upon the completeness of the assessment and availability of heuristic knowledge of the product and design process. The principle of the likelihood / impact analysis can be applied to the assessment of alternative design routes. If the likelihood and impact of task failure can be estimated for each task on each proposed route, then the route with the lowest predicted cost may be identified. Alternatively the impact may refer to a number of other interdependent measures, for example, a delay in design completion resulting in lost sales opportunities [8]. One method to estimate the cost of failure, Ci, associated with each design route z, is to sum the products of likelihood and impact for each task in the design process:

where d is the total cost of failure and p(n(s>) is the probability of failure of task n(s) on step s of route ; and c(r(s>) is the impact or cost of the task failure. It is important to note that this impact or cost is dependent upon the design route taken to arrive at task n(s) on step s, where:

The lowest cost route may be found by searching for the route with lowest Ci. Values for p(n) can be derived heuristically by observation of the design process. Values for c(r) can be derived by calculating the difference in cost between completion of the original design route

326

ICED01-C586/065

and the design route following failure, where the latter represents the lowest cost option to complete the design. Again there a number of possibilities for representing risk. Figure 9 shows the probable cost overrun for all the routes shown in Figure 6. Note that the risk reduces as the process advances, with zero risk of overrun when the process is complete.

Figure 9. Absolute risk representations

Whilst this clearly shows the range of risks, it does not assist the identification of individual routes. An alternative representation may be derived from the tangent diagram where the line thickness now represents a measure of risk (Figure 10). Preferred routes may be shown by thicker lines. Whilst it is now more difficult to ascertain a direct measure of risk, it is much easier to identify the lowest risk routes starting from a particular design state.

Figure 10. Lowest risk routes

Tangent vector diagrams have been constructed for a number of design processes. In all cases it has been possible to clearly identify tasks which must be performed sequentially or in parallel and task clusters which may be grouped to form larger coordinated activities. In addition, potential bottlenecks in the design process and processes which incur the lowest risk of overrun can be identified.

ICED 01 -C5 86/065

327

Conclusion

Effective process planning is dependent upon identifying the key attributes that characterise a particular process. These include natural process constraints, such as bottlenecks, and networks of alternate process routes. It has been demonstrated that it is possible to improve on current planning tools to assist with this characterisation. In particular, simple graphical representations can be employed to highlight the lowest risk routes through a given process. The tangent diagram, which is a form of design state network, would appear to show the most potential as a visualisation tool. Further work in under way to develop software which will allow the interactive development of process plans, supported by the use of design state diagrams incorporating process risk analysis. References [1] [2] [3] [4] [5] Mass, N J and Berkson, B (1995). "Going slow to go fast." The McKinsev Quarterly. 4: pp 19-29. Clarkson, P J and Hamilton, J R (2000), "'Signposting', a parameter-driven task-based model of the design process." Research in Engineering Design. 12(1): ppl8-38. Krueckeberg, D A and Silvers, A L (1974), "Program Scheduling," in Urban Planning Analysis: Methods and Models. John Wiley, pp231-255. Steward, D V (1981), "The Design Structure System: A method for managing the design of complex systems," IEEE Transactions on Engineering Management. 28(3): pp71-74. Eppinger, S D , Whitney, D E, Smith, R P and Gebala, D A (1994), "A Model-Based Method for Organizing Tasks in Product Development," Research in Engineering Design, 6: ppl-13. Clarkson, P J, Melo, A F and Eckert, C M (2000), "Visualization of routes in design process planning," in International Conference on Information Visualisation (IV2000), London, UK, 19-21 July, pp 155-164. Coppendale, J (1995), "Manage risk in product and process development and avoid unpleasant surprises," Engineering Management Journal. February 1995, pp35-38. Clarkson, P J, Melo, A F and Connor, A M (2000), "Signposting for design process improvement, a dynamic approach to design process planning," in Artificial Intelligence in Design. Worcester, USA, 26-29 June, pp333-354.

[6]

[7] [8]

Dr P John Clarkson Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0)1223 332 742 Fax: +44(0)1223332662 E-mail: pjclO@eng.cam.ac.uk Cambridge Engineering Design Centre 2001

328

ICED01-C586/065

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A PRODUCT AND PROCESS MODEL SUPPORTING MAIN AND SUBSUPPLIER COLLABORATION

B Fagerstrom and H Johannesson

Keywords: Product modelling, collaborative design tools, SMEs, industrial case study.

Introduction

Many main suppliers are streamlining their operations, moving towards more external contracting of their sub-systems. The co-operative aspects of product development are thereby increasing, and therefore the need to manage different types of relationships, and to exchange information and knowledge. The main supplier is reliant upon the sub-supplier's knowledge within certain areas. Thus, it is obvious that the customer-supplier interface now plays a key role, and the product and process model is an important part of the design and development of new products. The point in time for involving sub-suppliers and the ability to quickly put together a team with distributed actors is an important factor for success. Sub-suppliers become more important as they develop and produce an increasing amount of the components needed for the final product. As a result, the main supplier's ability to use sub-supplier's knowledge is a strategic factor for the future. The collaboration between main and sub-suppliers is dependent on the ability to manage the information exchange between interfaces for upstream and downstream tasks, different sub-systems and different organisational functions [1]. Organising and running a development project is a dynamic and complex process, partly due to the fact that knowledge is added as the project progresses. As a result, earlier decisions can be considered unreasonable at a later stage. It is therefore important, that the process continuously supports the exchange of design information and knowledge. When preliminary upstream information is utilised too early by the downstream activity, future changes have to be incorporated in time-consuming subsequent iterations. Overlapping tasks could be better managed through a proper understanding of the properties of the exchanged information. Subsupplier's ability to work with preliminary specifications, to manage overlapping and dependent tasks, and to support the main supplier with essential information is crucial [2]. Products are often built up in a top-down manner, where the main supplier carries out the requirement specification and the product structure, including descriptions for what is to be achieved [3]. When doing this, consideration of downstream processes is very important: subsupplier knowledge must be taken into consideration in a more bottom-up manner in order to avoid sub-optimal requirement specifications and product structures. Functional decomposition of the product is an important step when selecting the product structure and for reducing the complexity. The decomposition makes it possible for sub-suppliers to design sub-systems in parallel, even though the interaction between sub-systems must be taken into consideration [4]. A thorough understanding of the product structure and the tasks to develop

ICED01-C586/076

329

is central in the collaborative product development between main and sub-suppliers [1], where the formal procedure for information and knowledge exchange is often pending.

Product information framework

To remain competitive, an organisation must efficiently and effectively create, locate, capture, and share knowledge and expertise in order to apply that knowledge to solving problems and taking advantage of opportunities. Knowledge is often described as a result of data and information. Information is about placing data in a meaningful context, and a common language for communication is crucial for efficient information exchange. A lot of information about the physical product model is often available, but aspects like decisionmaking, packaging, suppliers, transports, etc are often pending. As the products become more complex, the amount of information to be stored and distributed increases. The need for efficient computer-based tools increases as well. Therefore, digital product models must support the product development process. The models contain product related information needed by different actors and tools in the process. The product information framework in the present study is an object oriented product model based on the so-called function-means tree [3,5], which has been implemented using the commercial software Metis Software. One of the aims of the study is to extend the model to incorporate sub-supplier process information. It is argued that the extended model is a powerful aid for supporting main and sub-supplier collaboration. Many delays in product development projects are related to inadequate specifications. This causes even more difficult problems when sub-suppliers are involved. In order to improve handling of these issues, a more adequate, dynamic approach for the specifications is required [6]. Such an approach must enable learning from experience gained in ongoing projects, allow consideration of alternative new concepts and technology and consider different stakeholders' views. By incorporating the product specification into the product and process model as an integrated part, these issues become easier to manage. There are some shortcomings in information models as well. A lot of the designer's time is spent on process and product-related information acquisition. When the information is found, there are still doubts as whether one may trust it, where a common understanding often is lacking and further discussions with persons provided [7], Designers often look for expertise: an expert to discuss a certain problem with. That expert often possesses a combination of tacit and explicit knowledge not available in the computer-based models.

The product and process information model

The proposed product and process model consists of the enhanced Function-Means (F-M) tree [3,5] (fig. 1) and task-based Design Structure Matrix (DSM) [4,8] (fig. 2). The Olsson table [9] is used as a mean to link context interaction maps between the DSM and F-M tree (fig. 1). The table consists of the product life phases on one axis and important domain aspects on the other. The life phases and aspects are not fixed, and should be determined according to the specific situation, depending on industry-, organisation- and product type, etc. The main objective with the model is to put the needed product-related information into a product model context, supported with information from supplier processes and life phases.

330

ICED 01 -C586/076

Figure 1. Enhanced F-M tree [3,5] and Olsson table [9]

3.1 Product model

The product model contains information about wanted functional behaviour, constraining factors and design solutions, fulfilling the wanted behaviour while meeting the constraints. Its basic structure, shown in figure 1, is an object-oriented, hierarchical representation of different design solutions (assemblies, sub-assemblies, parts and features) and their governing criteria (functional requirements and constraints). The solutions and their criteria constitute a complex product. Both solutions and criteria are modelled as objects. The objects used in the model are Functional requirements (FRs), Design parameters (DPs) (means= systems, organs and components) and Constraints (Cs). Descriptions such as function performance attributes, constraining limit values or design parameter characteristics can be linked to the objects. It is also possible to link describing documents and other models to the different objects. A DP represents the design solution, a FR is a solution driver and a C is a solution restraint. The six different relations used are defined and shown in figure 1. The design solutions (DPs) at lowest level will be linked to part lists in ongoing work. To identify all objects and related information regarding the product life cycle, the Olsson table, with so called "context interaction maps," is used. It is also used as a supporting checklist (fig. 1). Each object triplet (FR-DP-C) in a completed F-M tree has its own Olsson table linked to it, and each relevant table cell contains complementary information, such as company preferences, company standards, process descriptions, operations lists, lessons learned documents and so on. Furthermore, sub-supplier information is in this paper linked via the Olsson table to the main supplier's product model.

3.2 Process model

This paper uses a task-based Design Structure Matrix (DSM) [4] for dealing with upstream and downstream information exchange, which is sufficient for the purposes of this paper. This is shown in figure 2. The DSM is used as an interaction map to describe relevant sub-supplier involvement and processes. Design tasks to be performed are identically labelled in both rows and columns in the matrix. Each marked cell (+) shows a task dependency. Rows indicate information providers, while columns indicate information dependants. There are three types of task dependencies (fig. 2). Independent tasks can be performed in parallel, dependent tasks must be performed in series, and interdependent tasks are coupled, requiring multiple iteration [8]. A lower triangular matrix is optimal, but that rarely occurs in practise [4,8].

ICED01-C586/076

331

Figure 2. The DSM (Design Structure Matrix) principle [4,8]

Different measures can be used to describe the dependency, instead of just a simple (+), e.g. the degree of dependency or the volume of information to be transferred. This increases the advantage of the DSM. The DSM can also be used for other data besides tasks, e.g. parameters, components or teams [4]. This paper applies four different levels to quantify the dependency of information to each task (fig. 2). Furthermore, different actors, such as suppliers and customers, are shown in an additional column in the matrix. The DSM-principle has some shortcomings as well: it is difficult to predict all the tasks that have to be performed during an entire, new product development project. To deal with this problem; the proposed model could be a powerful aid, where the early product model (F-M tree) supports the modelling of primary tasks in the DSM and the involvement of suppliers.

3.3 Managing the model

The modelling procedure starts with formulation of the overall functional requirement and the constraints on the highest hierarchical product level (fig. 1). These formulations are most likely derived from a type of project assignment. Relevant information describing these overall criteria is linked to the requirement and constraint objects, either as attributes, in attribute lists or as referenced documents and models in other software systems. Then, the overall design solution (DP) is selected. The DP, which fulfils the FR and meets the Cs, is modelled as a DP-object. It is connected to the FR and the Cs respectively, and, finally, is described by its attributes and references. The DSM modelling process is dependent on this preliminary concept and the description of the main functions. The early phases for modelling the primary tasks in the DSM, should therefore be modelled simultaneously with description of properties, preliminary concept, main functions, requirement specification, etc. This procedure is somewhat iterative and the DSM supports the process. Next, sub-requirements for the chosen DP are identified and modelled at the next lower hierarchical level in the model (fig. 1). A sub-solution must fulfil each sub-requirement, taking the sub-constraints into consideration. All objects are connected to other objects and linked to relevant information sources in the same manner as the first level objects. All the sub-tasks to be developed are modelled in a master DSM (fig. 2), provided by the main supplier. Available process information from sub-suppliers is linked to the model objects as interaction maps via relevant Olsson table cells. It is also recommended that sub-suppliers carry out their own DSM, with, for example, information about design tasks, prototypes, testing, verification, tooling, processes planning and production ramp up. The main supplier's master DSM covers information for the complete system, such as, different suppliers involved, testing, verification, validation, 0-serie and final assembly. The level of dependency between different tasks is also to be stated (fig. 2).

332

ICED 01 -C586/076

Product and process analysis

All aspects mentioned above, involving different objects and activities with relations to each other are very difficult to manage efficiently. The F-M DSM product information model is a useful tool in this instance. The F-M tree and the DSM show the functional couplings and task-dependencies. This makes it possible to show when, and which, suppliers are involved during different stages of the main suppliers' product development process. It also relates subsuppliers process information to its concerned sub-systems or parts in the main suppliers' product hierarchy and also to concerned product life phases.

4.1 Product coupling analysis

A conflict called a functional coupling [10,11] can result when choosing a design solution to fulfil one of two or more functional requirements on a design solution on the previous higher structure. Graphic functional coupling degree analysis [12], based on the information captured in the F-M tree, can then be used. This technique is based on a graphic interpretation of the axiomatic design equation [10] for a group of parallel DPs and their governing FRs on an arbitrary level in the F-M structure model. The axiomatic design matrix elements then correspond to the z76-relations in the structure model (fig. 1). It is suggested that functional couplings are defined as interactions between incompatible parallel design solutions or between design solutions causing negative constitutive influences [11]. Incompatibility can be of many different types. The main areas of interest in mechanical design are geometry, time, system physics, driving effort and material. Constitutive influence can be described in terms of cause and effect, i.e. often with a constitutive relation. Just as solutions may be incompatible in order to fulfil governing functional requirements they may also be incompatible in order to meet design constraints. Incompatibility caused by constraints can be classified according to the same classification scheme as functional incompatibility. Design solutions incompatible due to geometrical constraints can be coupled in a way similar to incompatible solutions caused by functional requirements. These geometrical couplings can also be identified in the F-M structure model [13].

4.2 Process analysis

When a sub-supplier has finalised the design of a sub-system, the output will normally have an influence on the input to a parallel sub-system. The DSM will support the process to determine in which order the sub-systems may be designed to avoid needless redesign, or at least control the necessary iterative loops that is provided to meet the requirements and to design a first-class product. As the project progresses, additional knowledge is obtained, and the DSM links new features [6] via the Olsson table to the product model. The DSM helps the main supplier to analyse each supplier's information need. The DSM (fig. 2) will indicate what type of information dependency that exists between sub-suppliers and the main supplier. When a certain sub-supplier have essential information, that could be linked via the Olsson table back to the product model (fig. 1). The DSM will also show which suppliers who can work in parallel, where no dependence exists. Furthermore, the DSM could be used to shorten lead times by restructuring the task sequence. That is normally done by striving for a lower triangular matrix (partitioned) [4,8], However, it could also be helpful to consider clustering of sub-suppliers to avoid unnecessary travelling or

ICED01-C586/076

333

rethinking the scope of supply for sub-suppliers if that, for instance, could lead to a decoupling of tasks. Coupled tasks must be decomposed into suitable blocks for iteration [4]. If the iterative loops are extensive and involving too many actors, it could also be possible to divide the loop into sub-loops. There the iteration drivers are essential for selecting sub-loops.

Case study

This paper is based both on theory and on empirical findings from a case study. The case could be defined as a strategic partnership between the customer and the main supplier Autoliv (first tier), for the development of a new complex product (inflatable curtain: a side impact airbag) within the automotive industry. The company Autoliv is a worldwide leader in automotive safety, and also the inventor of the inflatable curtain in this case study. The case study is shown in figure 3, where some of the most essential parts of the study are illustrated. In this case, the customer starts the design process with a description of the properties of the product (item 1). The main supplier (Ml=Autoliv) prepares the design specification and the preliminary concept (item 2) in collaboration with the customer (Cl). The Olsson table (item 3) is used both as a checklist for criteria and to link context interaction maps for the F-M tree. The top-level triplet (FR-DP-C) for the product/sub-system is defined by using information that is linked via the top-level Olsson table. The overall function (FR1) for the product, the overall design parameter (DPI), and the constraints (Cl) are shown as item 4 in figure 3. The Olsson table covers life-cycle phases and different aspects. The aspects could be divided in suitable sub-headings for the purposes of the project. The solution 'inflatable curtain' (DPI) requires three sub-functions at the next hierarchical level below (item 5: FR21-FR23). The top level of the Olsson table is decomposed into subtables simultaneously with the selection of sub-functions and solutions (item 6). The decomposition of the Olsson table is dependent on the selected solutions. As such, it cannot be decomposed in advance.

Figure3. Presentation of case study

334

ICED 01 -C586/076

The relations in the F-M tree are continuously added as the model is built, with an w-relation (interact_with) shown as item 7, an n'6-relation (is_influenced_by) in item 8 and, finally, an ipmb-relation (is_partly_met_by) as item 9. The different sub-systems to be designed and their information needs are illustrated in the DSM (item 10). This case illustrates task dependencies, where iteration is provided for the tasks in row 7-11. It is not efficient to have all four sub-suppliers working in parallel, so it was decided to use the opening mechanism (Supplier 1: SI) and the cells (Supplier 2: S2) as iteration drivers, row 7 and 8 (item 11). After this initial iteration, information could be linked back to the product model, via the Olsson table. The master DSM (item 12) is used for coordination of suppliers and the verification and validation of the entire system. Each supplier could also define each sub-system's in a sub-DSM (item 13). There, the information from the design and verification of the sub-system could be linked back to the product model (item 14). A part-list has to be linked to the lowest level means, which is illustrated as item 15 in figure 3 (DP23, DP3i and DP32). That will be further discussed in other ongoing work.

Discussions and conclusions

In a distributed product development environment, it is essential to determine in which order the sub-systems have to be designed and which actors are dependent on each other, during different stages of the project. A generic F-M DSM product information model has shown promising results. The model describes both the task and object dependencies. It is also helpful for purposes of analysis. Defining the product structure in the F-M tree is important in order to structure the design tasks and locate them in the DSM-matrix. The DSM addresses both task and supplier dependency, using the important design parameters in the product model for the decomposition of iterations into suitable blocks. Furthermore, the DSM illustrates the feedback loop of information from sub-systems/suppliers back to the main supplier's product model, via the Olsson table. The enhanced F-M tree puts the product related information in a product context. The obtained structural product knowledge is essential for selecting the sub-system interfaces. The product model supports the information needed for each sub-system (supplier). The master DSM puts the information into a process context. The model contains the procedural knowledge, which is a good starting point when setting up new projects. It is also helpful for understanding supplier involvement, both from the main and sub-supplier's perspective. It is suggested that the master DSM be performed at a general manageable level, with the detailed supplier information being described in the sub-DSM for each supplier. Therefore, it is argued that the model is not only a model for structuring large amount of information, but also partly a knowledge model for both structural (product) and procedural (process) knowledge in the project. As the main supplier often is dependent on knowledge from suppliers, it is recommended that the F-M DSM product information model be created with personnel from both the main and the sub-suppliers. In addition, at least one person from each supplier should be responsible. It is essential that this is a physical meeting, for two reasons. First, this type of modelling consists of both explicit and tacit knowledge. Second, vital discussions often take place. The case study has shown it possible to have a more flexible approach to both specifications and the product structure, as long as the design process is defined and supported by the information model. The case study results are encouraging. Indeed, the proposed information

ICED01-C586/076

335

model is used in new projects at the studied company. The company also saw advantages with using the model, as the model could be computer-based, which is partly done in this project.

Acknowledgement

The authors would like to thank Johan Stenquist at Autoliv Sverige AB, for valuable input and technical knowledge. Funding was provided by the Swedish Foundation for Strategic Research (ENDREA program). This support is gratefully acknowledged. References [I] [2] [3] [4] [5] Fagerstrom, B. and Jackson, M., "Efficient collaboration between main and subsuppliers", Proceedings of the 4th conference SMESME'2001, Aalborg, 2001 Krishnan V., Eppinger S.D. and Whitney D.E., "A Model-Based Framework to Overlap Product Development Activities", Journal of Management Science, 4, 1997, p437-451 Schachinger, P. and Johannesson, H., "Computer Modelling of Design Specifications", Journal of Engineering Design, 4, 2000, p317-329 Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D.A., "A model-based Method for Organizing tasks in Product Development", Research in eng. Design, 6, 1994, pi-13 Andersson, F., Nilsson, P. and Johannesson, H. "Computer based requirement and concept modelling- Information gathering and classification", Proceedings of DETC'2000ASME, Baltimore, 2000 Akesson, A. and Bjarnemo, R., "Dynamic product design specification", Proceedings of ICED'99, Munich, 1999, pp.389-392 Blessing, L. and Wallace, K., "Supporting the knowledge life cycle", Proceedings of the KIC3 workshop, Tokyo, 1998 Steward D.V., "The Design Structure System: A Method for Managing the design of Complex Systems", IEEE Transactions on Engineering Management, 3, 1981, p71-74 Olsson, F., "Principkonstruktion", Lund University, Sweden (in Swedish), 1978

[6] [7] [8] [9]

[10] Suh, N.P., "Principles of Design", Oxford University Press., New York, 1990 [II] Johannesson, H.L., "On the Nature and Consequences of Functional Couplings in Axiomatic Machine Design", Proceedings of DETC'1996 ASME, Irvine, 1996 [12] Johannesson, H.L., "Computer Aided analysis of Functional Couplings in Structural Axiomatic Design", Advances in Design Aut, Book NQ.H00998, ASME, Vol. 1, 1995 [13] Soderberg, R. and Johannesson, H.L., "Spatial Incompatibility - Part Interaction and Tolerance Allocation in Configuration design", Proc. DETC'1998 ASME, Atlanta, 1998 Fagerstrom, Bjorn IVF Industrial Research and Development, Argongatan 30, SE-431 53 MoTndal, Sweden, and Department of Machine and Vehicle Design, Chalmers University of Technology, Goteborg, Sweden. Phone: +46 031 706 61 57, Fax: +46 031 27 61 30 E-mail: bjom.fagerstrom@ivf.se IMechE2001

336

ICED 01 -C586/076

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23. 2001

IDENTIFYING AND ANALYSING CHANGES IN A DYNAMIC COMPANY

S Suistoranta

Keywords: Industrial case study, competitive products, change management.

1 Introduction
Changes in the environment lead easily to a proliferation of changes throughout the productfamily for a variety of reasons. A competitive delivery process is sensitive to disturbances. Even if the implementation of changes is well managed, it is practical to strive for as few changes as possible. This paper is based on an industrial case study conducted in a company, which designs, manufactures and sells diesel-powered solutions for marine and power producing applications [1]. The study was delimited to the annual production of an engine factory. Change orders, arguments, and explanatory information were collected at different points of the delivery process. A team of specialists with extensive experience in the field analysed the data in the performance of their daily tasks. The objective was to identify the sources of change to better control their impact on the delivery process. The focus was on changes induced by the company's own processes. The findings will be used in internal process development. There are two main reasons why we should strive to reduce the number of changes. First, cost-effective manufacturing and successful delivery are largely based on well-controlled logistics. In view of material management and inventory control every change causes a potential disturbance. Second, every change order initiates a chain of transactions, both in the design office and on the shop floor. Transactions are usually performed by a set of activities, each contributing to cost accumulation or fixed costs. Even though current PDM systems help in managing product data, version history, and engineering change orders, it is obvious that we should find a systematic way of handling the changes and eliminate unnecessary ones.

2 Background
Change occurs constantly and in every aspect of society and human life. In business it means that new markets are opening and new customer needs are being charted. Companies have to maintain a large product variety and be responsive to evolving customer needs at the same time. This is reflected in all levels, especially in the need for product development. The company continuously measures its performance and adjusts its operation to meet the requirements of a changing environment. All changes, especially in the market, affect the business to some extent. The company responds to these changes by means of its processes, which finally implement the changes. The object of change may be a product abstraction, physical product or documentation related to them.

ICED01-C586/087

337

The object of change is an evolving entity, which originates at an abstract level in the form of requirement lists, ideas, and domain structures. It then assumes a more concrete nature in the form of technical specifications, configurations, engineering drawings, and bills of material. These are depictions of the product at different stages and they comprise a continuous information flow, which is united with a material flow to make a physical product in a manufacturing process. Product-related documentation accompanies the product in this evolution. All features and properties, intended or unintended, are involved in the process. In a delivery process the change is intentional alteration of requirements, design, specification or contractual terms. The causes behind the change vary. Some typical causes are: Feedback from different life phases of the product, striving for better manufacturing capability, serviceability, and operability Defects found (if any) in products and requests for corrective design Customer-specific requests Introduction of new technology, product structures or components Introduction of new design tools or manufacturing technologies

A customer-orientated approach calls for flexibility and capability in handling changes during the delivery process. Time-based competition emphasises a change-intensive approach, i.e. product improvements must be promptly implemented.

Sources of change

If we want to emphasise the environment's dynamic nature in generating changes over time we call it a source of change (henceforth referred to as SOC). There is a complicated interaction between the environment, business and company processes, which can independently or collectively behave as a SOC. Depending on the viewpoint we can speak about external sources and internal sources (see Fig. 1). External SOCs usually fall outside the company's sphere of influence, such as society revising a law or normative rules. However, many changes are not mandatory. Changes induced by market trends are fully within the power of the company because it defines in what market it wants to be and with what product portfolio. Based on its own arguments the company makes decisions on product mix and the introduction of new technologies. These decisions typically lead to an extensive flow of changes at the operative level. On the other hand, there are changes from internal SOCs, in which the company has only limited controlling possibilities, such as specific customer requests and cases in which a component supplier fails to meet its commitments, compelling the company to seek alternatives. Documentation in itself also possesses features of a SOC; e.g. misspelling or a typographical error in one document may cause a chain of others to be revised. This may sound like red tape, but we must keep in mind that very often the implementation is triggered by a given document. Documentation also plays an important role in quality systems and may have significant judicial meaning.

338

ICED01-C586/087

Figure 1. External and internal sources of change and the object

4 Germs 4.1 Definition

Flaws hidden in the object always lead to changes, amending of documents and corrective actions. For this we have introduced a new term: germ, which is something that is unintentionally designed into the object and remains undetected until the object meets a particular life phase. A germ carries a potential nonconformity or a malignant disposition. We define it as follows: a germ is a feature, property, solution, principle, mode of action, material, dimension or

ICED01-C586/087

339

whatever factor that makes a potential nonconformity or incorrect parameter settings with respect to the intended life phase process. A disposition is defined as in [3]. We clarify the term with two explanations. First, nonconformity is defined in [4] as nonfulfilment of a specified requirement. This covers the departure or absence of one or more quality characteristics. 'Potential' means that the nonconformity is possible only when the necessary conditions exist. This infers that, at its point of origin, the germ is not a nonconformity and perhaps may never be, unless the conditions in object's later life phases turn unfavourable. Second, we use dispositional approach, as presented in [3]: "By disposition we understand that part of decision taken within one functional area which affects the type, content, efficiency or progress of activities within other functional areas." In a delivery process we may make a decision which carries a germ, affecting the progress of activities later in the process, e.g. in a form of nonconformity.

4.2 Origination
In general terms, the germ originates in a transformation system, which consists of a process, an operator, and an operand. Similarly, in an industrial company we have a delivery process, which consists of sub-processes, a designer and information. We have found four major sources of germs, which are more or less specific to the type of company and product. Process In the delivery process there are typically functions ranging from clarification of customer needs to factory tests. Between the performance of these activities, information is stored, transformed and distributed through contact surfaces, which serve as potential points for origination. A process can be seen as an information cycle, in which the output of each activity adds to the volume of object information, accumulating every time the main process is performed (see Fig. 2). In this system a germ may originate and progress as part of the operand to the next round. Designer Designing is a human activity, and the way the designer performs his work reflects all aspects of life. Despite systematic design practices there is always room for biased thinking, misunderstanding, missing motivation or even casual obstinacy. When solving complex design problems under time pressure, the designer is inclined to accept the first working solution without striving to find one that is more optimal. Even if the work is reviewed and checked, there is always a risk of aporia, which prevents us from seeing the best solution [5]. An eventual need for improving the construction later causes a flow of changes. Another problem is that design personnel undergoes changes: people retire and novices start. Tacit knowledge is difficult to transfer. Novices lack experience and due to over-enthusiasm are often prone to haste. They may find drawings with a perfect solution to a technical problem, but cannot understand the original premise for that particular solution, which makes its reuse unpredictable.

340

ICED01-C586/087

Order information In a sales process it is not rare to find some information speculative, incomplete or missing, thus partially basing the configuration on opinion. Sometimes late requests are also received and must be given preferential treatment. Unforeseen requirements may lead to radical changes in sales configuration and to project-related designing. Product information Maintaining a dynamic product-family means managing a large variety at a high rate of change [6]. The variety is based on different configurations, which are realised by means of standard modules. Continuous product improvement results in an extensive revision program, which comprises a myriad of drawings and bills of material. Rushed sales orders cause sudden overloads in the design office. Project-specific applications are realised by joining adaptive modules or non-modules with standard modules. A strong connection between their interfaces may result in some degree of incompatibility between the modules.

4.3 Mechanisms
We have identified seven behavioural mechanisms of germs: retracing, circulating, hereditary, mutating, reproducing, contagious, and hidden germs (see Fig. 2). Each of them can work independently or together with others, making their identification difficult. Certain mechanisms can apply to only one product variant, covering its all life phases while others work across the whole product-family. These features describe the germ's nature as a change carrier: originating during the delivery process, it is a considerable internal SOC in a fastmoving environment, where the conditions are changing frequently. The behavioural mechanisms are presented in the following list. The numbers refer to the legend listed in Fig. 2. 1. Retracing. The germ originates somewhere in the process. It is perceived in a later life phase. In searching for its origin it is retraced from one life phase to another. Much time and work is needed before the real origin can be found. 2. Circulating. The germ is detected when the object meets a particular life phase, such as A' for example. Corrective design does not fully succeed in solving the problem and the germ appears in a similar form in life phase N+k. 3. Hereditary. A particular solution made in the product development is introduced in commercial applications; e.g. mapping of functions into physical modules. This may cause interference with particular project-related applications. 4. Mutating. A germ that is perceived in a particular life phase (design, production, use, etc.) appears after corrective design somewhere else in a different form. 5. Reproducing. A germ is copied to new designs by reuse, which results in the need for corrective actions later. Meanwhile the new design is reused somewhere else, including the original germs. This occurs especially when details of existing drawings are copied to new drawings. 6. Contagious. A germ that is perceived in and corrected for a particular product variant creates a set of new germs in other variants that use the same design.

ICED01-C586/087

341

7. Hidden. A germ hidden in a structure, appearing only if structural view is changed.

Figure 2. Examples of germ behavioural mechanisms.

4.4 Controlling the origination

Figure 3 shows the relationships between the origin and the behavioural mechanism. First, for each origin there is more than one mechanism. Second, for retracing germ there are four origins and third, product-related reasons are the origin for most mechanisms. To control the origination of germs we suggest taking the following measures: 1. Designer. We stress the recruitment policy, with a focus on aptitude, i.e. education, experience, attitude, motivation, and the desire to achieve professional excellence. Job rotation in the workshop is recommended to extend designers' knowledge on efficient logistics and manufacturing technologies. 2. Process. It is important to find a balance between hard and soft control [6], to develop design rules, and to encourage people to engage in systematic feedback and communication.

342

ICED01-C586/087

3. Order information. Although flexibility is important, standard configurations should primarily be offered. This is also the aim of sales configuration development. On the other hand, we recommend the structured sales process [7], which ensures that all customer needs and expectations are properly clarified and understood. 4. Product information. Standardisation of components reduces a number of different items, which simplifies logistics and reduces inventories. The functional, dimensional, and logistical interchangeability of components widens their applicability. Weak connections between module interfaces are important when developing modular systems.

Figure 3. Relationship between the mechanism and the origin of germs.

5 Implementation process
In a manufacturing company all changes cause a chain of operations. We have divided the changes into two main categories according to their implementation process: 1) those where the company has discretionary power and 2) mandatory changes. Processing the changes of category 1 typically consists of two phases. First, we have to judge the necessity of the change, i.e. consider whether to do it or not. At this phase we compare the cost-benefit ratio, taking into account the whole product-family and the entire life cycle. Sometimes the product's manufacturing properties are decisive. Second, we have to assess the impact on the logistical chain, particularly on the availability of the revised material for ordered products. At the same time we have to decide what to do with the material of older versions, whether to use, repair or scrap it. Here we have to balance between inventory costs, reparation costs, and possibly costs of delayed delivery. Processing the changes of category 2 is different because they are frequently based on rules or regulations coming outside the company. Some of these mandatory changes have a transition period, which makes them essentially easier to implement. Non-conformities must be corrected promptly. The same applies to construction changes, which may, if left unimplemented, cause a risk of failure. The object of change may range from particular product variants up to the entire product-family. Customer requests are negotiable and the changes apply usually only to particular product entities. An experienced designer can contribute to logistical interchangeability when making decisions on the types of materials and component specifications. At the same time he can estimate whether to make or buy and finally, how his decisions affect the inventory. These questions are closely related but it may be reasonable to divide the responsibilities between a

ICED01-C586/087

343

designer and another specialist who makes the release and make-or-buy decisions. Naturally, efficient communication is necessary.

6 Conclusions
In this study we have identified and analysed sources of change, which affect the delivery process of a manufacturing company. Changes come from both outside and inside the company. The external sources of change can be managed proactively. Most changes, however, originate in the internal processes. We introduced a new term - a germ - which means a hidden flaw in the object. It originates in the process and carries a flow of changes through seven different mechanisms. Process development is suggested to focus to the origins of germs for their better control. The logistical arguments are important in implementing the changes. Finally, we point out that change per se is not negative - on the contrary, it indicates the dynamic nature of our world and allows for industrial companies to prove their commitment to a continuous product improvement, both in terms of quality and of environmentalfriendliness. References [1] [2] Wartsila Corporation: "Power Divisions". Available at <http://www.wartsila.com>. Kotler, Philip: "Marketing Management. Analysis, Planning, Implementation, And Control." Seventh Edition. Prentice-Hall International Editions. Eaglewood Cliffs, New Jersey. 1991. ISBN 0-13-563479-2. Olesen, J.: "Concurrent Development In Manufacturing - Based On Dispositional Mechanisms". Ph.D. Thesis from the Integrated Production Systems. Institute for Engineering Design, Technical University of Denmark, 1992. Publication IK.92.116-A. ISBN:87-89867-12-2. ISO 8402:1994 (E/F/R): "Quality Management and Quality Assurance - Vocabulary". 2nd Edition. Hubka, V. - Eder, W.E.: "Design Science. Introduction to the Needs, Scope, And Organization of Engineering Design Knowledge". Springer-Verlag. Berlin- HeidelbergNew York. 1996. ISBN 3-540-19997-7. Sanderson, Susan W. - Uzumeri, M.: "The Innovation Imperative. Strategies for Managing Product Models and Families". Irwin Professional Publishing. Chicago. 1997. Suistoranta, S.: "Structured Sales Process for Configuration". Proceedings of the 5th WDK Workshop on Product Structuring. February 7-8, 2000. Tampere University of Technology, Finland. (In print).

[3]

[4] [5]

[6] [7]

Seppo Suistoranta Wartsila Finland Oy Turku Factory Stalarminkatu 45, FIN-20810 Turku Tel. +358(0)107093097 Fax +358(0)107093169 E-Mail: seppo.suistoranta@wartsila.com IMechE2001

344

ICED01-C586/087

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DESIGN PROCESS PLANNING USING A STATE-ACTION MODEL A F Melo and P J Clarkson

Keywords: design management, design strategy, planning and workflow methodology

Introduction

The timely introduction of new products to market is a critical factor in determining their commercial success. In turn, design process planning is crucial to their timely introduction. The aim of this paper is to present a model for design process planning which enables the identification of possible alternative plans, their comparison, and the selection of the most appropriate. The model, which provides planning guidance for designers, is to be incorporated into a tool that aids decision making in scheduling, thus enabling design process improvement. Difficulties arise in the introduction of new products because of the complexity of the design process. Unlike other processes, in the design process the state of the product after each stage can not be predicted. This frequently leads to iteration. Many design tasks are undertaken to provide information about the fulfilment of requirements and their outcome has a direct impact on the subsequent direction of the design process. Very often, these outcomes force redesign and re-testing. Development plans (sequences of tasks) are thus bound to change, and schedules (resource allocation timetables) are affected in the process. Scheduling is also affected because the highly complex human designer is the main resource involved. To be effective, design needs to re-evaluate the state of the product, and react to it every time. Exiting approaches to design process planning attempt to simplify the process by defining task precedence. This is equivalent to assuming that activities have predictable outcomes and can imply that there is no iteration. This simplifies the model, but at the same time requires the description of the process components in terms of their relation to the process as a whole. For example, in a PERT diagram, a task is described in terms of the tasks it depends upon and the tasks that depend upon it. This means that changes in the model or unexpected situations require revision of the task descriptions, and therefore render the original model unreliable. Exploring and evaluating possible design processes leads to some problems. The necessary definition of starting points, components of the design process, goals and measures for evaluation is not trivial [1]. The model proposed in this paper separates the description of the components of the process from the process itself. The components are then actions that produce changes in the state of the design process. Their potential outcomes depend on the state of the design when the action is performed and, in this way, the states put the actions into context. The current state can be determined at any point in the process, potential future states can be identified, and plans are made by choosing sequences of tasks according to the comparative benefit they offer.

ICED01-C586/073

345

Using the state of the design for process planning

Design can be seen as a series of tasks that are scheduled following precedence relations between them [2]. A complementary view is that design is a process in which a design object (drawings, sketches, manufacturing instructions and parameters in general) evolves and is refined by performing certain actions [3]. This process continues until the design object is considered sufficiently refined. Merging both ideas, a state (described as the refinement of the design object) is repeatedly modified by performing actions (design tasks), until a desired final state is reached. Actions are constrained in that their outcome depends on the input state. State-action models have previously been used for planning and have proved to be useful representation for highlighting ways to produce complex changes within a system [4]. (In this article, in the context of state transitions, the term action is used instead of task, following the usual practice in the literature on the topic.) Our approach to design process planning derived from earlier work on Signposting, a process capture and planning technique which has been successfully applied to a number of design problems [5]. However, the use of Signposting has been limited to identifying only the next step at any stage of the process. Following a review of the Signposting technique and further observation of industrial design practice, a revised state-action model has been developed which allows the identification and evaluation of alternative design routes. This new model is being incorporated in a software tool including uncertainty modelling and scheduling techniques. It supports the construction of a more flexible plan, using a state-action model, which is described by means of an example in the next section.

A state-action model of design

The details of the state-action model are now described with reference to the design of a venting valve. A group of designers at the Technische Universitat Miinchen successfully redesigned the valve, and its associated assembly line, in order to resolve a number of operational problems. The model presented here was built using the experience they gained in the process.

3.1

State description

To represent the state of the design, the design object is divided into parameters that can be separately evaluated. These parameters may be components, dimensions, materials, performance parameters, or any other characteristic of the product that is addressed by the design process. The choice of parameters and their levels of detail is critical for the success of the model. It must be simple enough to be easily understood and used by the designers, while still being sufficiently rich to be able to express the situation of the design process in a useful way for the tool. In the case of the valve, the design was divided by components on the one hand, and by stages of development on the other. This resulted in 27 parameters, shown in Figure 1. The state of the design is represented as the refinement of the parameters that describe the product, or more accurately, the confidence that the designer has on the suitability of each of the parameters. The idea is that the refinement of components, dimensions, materials or

346

ICED01-C586/073

performance parameters is higher if their current state is closer to that of the finished product. Naturally, the completely refined product is unknown during the design process, but designers can readily estimate how far are they from reaching it, and the result of that estimation is what we call confidence. In the example, the designers do not really know whether the VALVE CONCEPTS reached its final state, but they can say that they have high confidence that it has.

Figure 1. Valve design parameters

Representing the state of the design by using confidence values in the parameters has three important properties: It can be derived at any point during the design process. It is clear that designers can take the list of parameters and assign sensible confidence values to each one, and that it will show a profile of the completeness of the process. For example, they can readily indicate if they have low, medium or high confidence in the SCREWING TOOL DESIGN. The final state is known a priori. In the example, the design process finishes when the designer has a high confidence in all the prototypes (VALVE PROTOTYPE, GRIPPER
PROTOTYPE, ASSEMBLY LINE PROTOTYPE, and SO on).

Tasks can be described as changes in confidences of parameters. Each task produces a change in one or more of the design parameters; otherwise, it would not be relevant to the process.

The cases previously studied have proved the use of confidence to describe states and tasks to be simple enough, while providing the information needed for dynamic process planning [4].

3.2

Action description

Design tasks are represented in this model in terms of the states they can produce given their input states. In this sense, they are seen as black boxes that produce some output for a given

ICED 01 - C586/073

347

input. Describing the outputs independently from the input would not be accurate, and describing them as exhaustive pairs of possible inputs and resulting outputs would be unnecessarily demanding. Therefore, an option is to generalise the input-output pairs by using rules of change. The parameter confidence representation allows this to be done. Usually a task affects only some of the parameters, while the others remain unchanged. Relevant parameters should have some level of refinement (reflected in a confidence value) before they can be profitably used by a task. Input states that do not have those levels of confidence will remain unchanged if the task is performed; but if they do have them, at least one of the confidences will improve and a new state will be reached. The basic description of the tasks is thus made by indicating the minimum confidences needed in the parameters required to execute the tasks, and the potential increases of confidence. For example, the task detail design of gripper (illustrated in figure 2) requires a medium confidence in the GRIPPER DESIGN and high confidences in the GRIPPER REQUIREMENTS, VALVE DESIGN, VALVE REQUIREMENTS, and WORKSHOP REQUIREMENTS. If the detail design is successful, the confidence on the GRIPPER DESIGN will increase to high.

Figure 2. Example design task

There are two other aspects of tasks that are supported by the model. One is the cost, in time, money or risk, of executing the task. The other is the fact that most tasks are not deterministic; hence, different outcomes must be reflected by a range of possible changes in confidence. For example, if some technical problems were encountered when doing the detail design of gripper task, the confidence in the GRIPPER CONCEPTS and GRIPPER DESIGN might fall, prompting rework. This task representation is appropriate for planning as it describes not only what designers want to achieve, but also what they might achieve instead.

3.3

Task sequences

States and tasks are the building blocks of the state-action model. Designers describe the state of the design at any point, and the tasks that can advance the design are selected. The task representation identifies then the state that can potentially result from performing the task. In this way, states suggest potentially useful tasks, and tasks produce new states. Task sequences can thus be represented as a state-action-state sequence. They are produced by finding the tasks that can be performed given the current state, the states that can be respectively obtained, the tasks that could be used from these new states, and so on. For design planning, it is possible to estimate in this way the possible sequences of tasks and states that would lead to the conclusion of the design. For example, suppose that in the current state of the design, the designer has medium confidence in the parameter VALVE DESIGN. This means that task detail design of gripper

348

ICED 01 - C586/073

cannot be performed yet, as it requires a high refinement of the VALVE DESIGN. However, task detail design valve can be done in the current state, and has the potential to produce the required refinement. Both tasks can thus be done in a sequence, provided that the detail design of valve task is successful in increasing confidence in the VALVE DESIGN parameter. These task sequences are optimistic since they are produced under the assumption that tasks give the best of their possible outcomes. The set of all the possible optimistic task sequences, for given initial and final design states, represents the search space for planning. Due to the combinatorial complexity of such a set of sequences, it is better to take advantage of the fact that most states can be reached through several different task sequences. The search space can thus be represented as a net, where the states are the nodes and the tasks are the links. Different tasks emerging from a state will diverge to different states, and different tasks emerging from different states can converge to the same state. (A good way of showing a state net is by using a tangent graph showing the different optimistic sequences [6].) However, the problem with using optimistic routes is that they do not allow a useful comparison of the task sequences. The risk associated with executing each task needs to be considered at every stage of the process. In particular, the impact of the alternative outcomes of each task, and the different effects they can have, must be evaluated with respect to their position in the task sequence.

3.4

Choosing the next action

Effective design process planning involves identification of appropriate actions to take given the requirements of the design. Actions are preferred when they are more likely to result in lower commercial risk and maximum long-term profit, and ultimately in a more successful product. Time management is critical in design since commercial risk is directly affected by the time taken to design the product [7]. Hence, by choosing the best plan to minimise the expected duration and costs, commercial risk can be reduced. Alternative plans can be compared by treating the state-action model of the design process as a Markov decision chain when choosing which task is best to perform next. Markov chains have been used previously on similar models to aid planning of the design process [8, 9]. However, these models do not have an explicit and intuitive representation of states, and fail to capture some important aspects relating to the complexity of the design process, such as the designer's decision not to perform a task or unexpected changes in the design state. The state-action model allows the building of a net of states and actions producing state transitions, which can be used to compare the different possible task sequences. This net has the same nodes as the optimist task sequence, but these nodes are also joined by links representing the state transitions occurring when the tasks fail to produce their ideal outcome. These links have a weight, representing the probability of the transition occurring. They are unidirectional, as in the optimistic case, and may represent increases or decreases in the parameter confidences. This enhanced state-action model is an example of a Markov decision model. At each state there is a choice of actions (the tasks that fit the state), and these actions can have different outcomes. Actions have also a cost that accumulates as the process develops, until a final stable state is reached. Markov chains are in general well understood, and from this specific

ICED 01 C586/073

349

kind of Markov chain it is possible to derive information to aid the decisions necessary during planning, i.e., a strategy to minimise the expected duration and costs of the process. The model can be evaluated as a whole to determine the lowest average costs of going from a given state to a final state. This evaluation considers the possible actions that can be done at every state, their costs and possible outcomes (including decreases in confidence). The best policy, which describes the best possible actions for every state, is found in parallel with this evaluation. The algorithms used to evaluate the Markov decision net are standard and can be found in textbooks on the topic. The problem is that even though the number of iterations needed to solve a typical model of the design process is low (two or three using a policy iteration algorithm), the evaluation in each step has combinatorial complexity, and becomes computationally infeasible with large problems. This can be overcome by pre-processing the net to simplify it. This is done by detecting the pairs of tasks whose ordering affects the total rework, and using the Markov net to decide on the ordering of these pairs only, while ignoring the sequences that can be trivially ordered, i.e., those that do not affect the amount of rework. The resulting policy is the same that would be obtained from the complete net, but its computation with the iterative algorithms becomes possible. At the end of the analysis, the dynamic plan that is obtained takes the form of a policy, in which the best actions are identified for each design state. The optimistic task sequences that follow the policy stay as conventional plans, indicating likely routes that can be taken to complete the design process. For dynamic process planning, though, the policy may be used as guide to what to do given the current situation. It is supported by an indication of the additional risk that would be incurred if a different course of action were taken. Conventional plans and schedules can be derived from policies. This can be done by producing an optimistic task sequence net that shows only those tasks that belong to the best policy. A preferred approach is to extract precedence rules from the model. They can be used in addition to the usual parametric precedence relations, as part of the scheduling strategy. Unlike the usual precedence relations, the precedence rules can be broken in a plan, but breaking them has a known cost or risk. Conflicts between precedence rules and scheduling constraints can be solved by comparing the risks and taking the lowest risk route. This has the advantage of including a measure of the expected process risk, which in turn can be used to plan for contingency. In contrast with precedence dependencies, the precedence rules obtained with the model are not obvious from the task descriptions or the process rationale. Precedence dependencies can be easily identified by designers, as they derive the rationale of the process and even of the task description. For instance, in the valve case it is clear that generate gripper concepts cannot be done before tasks generate valve concepts and define gripper requirements have been successfully completed. On the other hand, precedence rules like "detail design valve should precede analyse assembly line" though justifiable and reasonable, are not obvious (see Table 1 for more precedence rules). Breaking this rule would include the relatively expensive analysis of the assembly line in the rework loop of the valve design, causing 36 additional hours of estimated rework. This is an increase of 5% of the total cost of the process. It is therefore in the interest of the project to avoid breaking this and other precedence rules. They should be considered and traded-off with other conditions such as resource cost and availability during scheduling.

350

ICED 01 C586/073

Table 1. Example precedence rules from the valve design model

Precedence rule Detail design valve , Analyse valve Analyse assembly line Analyse assembly line Detail design valve Detail design assembly before before before before before before Analyse assembly line Generate assembly concepts Analyse valve Pre-evaluate gripper Generate assembly concepts Pre-evaluate gripper

Estimated cost of breaking rule

Percentage of total time

47.8 h 39.9 h 36.4 h 25.3 h 23.3 h 13.7 h

7.1 % 5.9 % 5.4 % 3.7 % 3.4 % 2.0 %

Evaluation of planning with a state-action model

The model and its associated tool are being evaluated at two levels. On the one hand, regarding the population of the model, to check that states and actions can be elicited under this representation. On the other hand, regarding the planning strategies given by the tool with a populated model. Models of different levels of complexity have been created, ranging between simple cases of bicycle configuration and the mechanical design of a single component, to the conceptual and detail design of a valve (as used in this paper). Currently, a model of the design process for an automotive powertrain is being constructed with the assistance of Lotus Cars. In all of these cases, the division of the product into parameters proved to be the most critical part of the model elicitation. The idea of defining the parameter refinement needed to perform a task, and its potential outcomes, seems to be quite natural for the designers involved in building these models. The results of evaluating the model, on the other hand, appeared in general to be sensible. Precedence rules are not obvious when building the process, but have an important impact on it. In the valve case exposed, following some of the rules can produce improvements in the order of 5-10% of the total time of the project, which make the analysis worthwhile.

Conclusion

A design process model that considers the state of the design, using the designer's perception of the refinement of the design, has been described. The structure of the model is simple, but allows sophisticated analysis of the process structure, to provide useful insight and guidance for dynamic planning. A measure of the progress of the design process may be obtained, and advice, expressed as simple heuristic rules, can be given on the sequences of tasks that are

ICED 01 C586/073

351

more likely to be effective in meeting the design goals. Current evaluation results suggest that models can be constructed which provide useful output for its planning and scheduling. Further work will focus on elicitation issues, more complex analysis of the model and refinement of the design process representation. Acknowledgements The authors would like to acknowledge the help of the design group of the Technische Universitat Munchen, and in particular of Ludwig Schwankl, in providing information about the valve design and participating in building its model. References [1] [2] Westerberg, A W, Subrahmanian, E, Reich, Y, Konda, S et al. (1997), "Designing the process design process," Computers & Chemical Engineering. 21:pp S1-S9. Steward, D V (1981), "The design structure matrix: A method for managing the design of complex systems," IEEE Transactions on Engineering Management, EM-28(3):pp7174. Ullman, D G, Dietterich, T G and Stauffer, L A (1988), "A model of the mechanical design process based on empirical data," AI EDAM. 2(1): pp33-52. Fikes R E and Nilsson, N J (1971), "STRIPS: A new approach to the application of theorem proving to theorem solving," Artificial Intelligence. 2:ppl89-208. Clarkson, P J and Hamilton, J R (2000), "'Signposting' - A Parameter-driven Taskbased Model of the Design Process." Research in Engineering Design. 12(1), ppl8-38. Clarkson, P J, Melo, A F and Eckert, C M (2001), "Visualisation techniques to assist design process planning, " Proceedings of ICED 2001. DTI (1994), "Successful Product development." Department of Trade and Industry, HMSO. Eppinger, S E, Whitney, D E, Smith, R and Gebala, D (1994), "A Model-based Method for Organising Tasks in Product Development," Research in Engineering Design. 6(1): ppl-13. Carrascosa, M, Eppinger, S E and Whitney, D E (1998), "Using the Design Structure Matrix to Estimate Product Development Time," in Proceedings of the ASME Design Engineering Technical Conferences. Atlanta, GA, 13-16 September

[3] [4] [5] [6] [7] [8]

[9]

Andres F Melo Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0) 1223 332 376 Fax: +44 (0) 1223 332 662 E-mail: afm27@eng.cam.ac.uk Cambridge Engineering Design Centre 2001

352

ICED 01 C586/073

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

INTEGRATED NEW PRODUCT DEVELOPMENT - A CASE-BASED APPROACH

R Valkenburg and J Buijs

Keywords: Design reams, systematic product development, concurrent engineering, empirical study, design education.

Introduction

Nowadays we should know how to develop good products; enough theories and methods have been developed to support new product development. Many product development models have been introduced over the years [1, 2, 3, 4, 5]. The developers of such models were people with a lot of practical and/or industrial experience. Although they have not made their experience explicit, you can sense the practical base of most models. Theories and methods, however, are always abstractions from real life. New product development (NPD) in daily practice is much more complex and as a result few practitioners recognise their activities in these theories and models. Most 'model builders' of the NPD-process had an engineering background, and as engineers they were used to building and using abstract models to produce real artefacts. They were also used to working in highly compartmentalised companies. Companies with an R&D department for the development of new technology, a design department to translate this technology into a new product, an engineering department to transfer this new product in something to be manufactured, a manufacturing department to produce the product and ship it to the customers, and finally a marketing department to try to sell the product to the customers. Deep down in their hearts the 'model builders' thought that this well-designed new product was of course instantly loved by their intended customers, and that marketing was not really necessary. They 'sold' their models of the NPD-process in more or less the same manner. They threw it over the wall to the 'users' and expected, not only that these users would be able to understand the model, but that they would use the model as they intended. Models, however, are always an abstraction from reality. The fact that NPD-processes can be divided into separate steps or phases is also usual in daily practice. Managing the developing design content within these phases, or dealing with iterations is also common practice, but hardly ever dealt with in the theoretical models. In daily practice the design task is not clear or objectively stated. Rather, the product developer has to deal with conflicting interests and to consider contradictory demands. The product developer hardly ever works individually anymore; he is a member of a product development team, together with members from other departments in the company, such as marketing, production, purchasing, or (from outside the company) suppliers and potential clients. This 'know-how' led to more refinement of the models, which usually meant more stages, more definitions and more abstract terminology. In short more logic was built into the models, because logic is the language of engineers.

ICED 01 1 C586/137

353

Although the original 'model makers' themselves knew how to play with their own models and were well aware of the limitations and constraints, as soon as these models were introduced in education these models became goals in themselves. Many of the engineering teachers left practice a long time ago and models of NPD became more important than the practice of NPD. We are also taught about these abstract models at university and were never taught about implementing these models in real life. By applying these models to practice (and also by trial and error) we have discovered an urgent need in real life for simpler, more applicationoriented models. In short there is a need for a more realistic approach towards NPD, not just offering a stage-gate model, but also guidelines to implement it in real life situations.

Learning from case study material

Since 1976 we have collected case study material on NPD projects. At first these descriptions offered a broad view of NPD [6]. Later, data were collected for research on innovation, which led to 120 case histories [7]. Since 1992 we systematically collect detailed case studies for use in education [8, 9].

1. Some products from our case histories: a package design for a homoeopathic medicine by Claessens Product Consultants, a range of cosmetic organisers by Curver (producer of synthetic household products), a traffic sign by njp|k (design agency), a digital copier and printer by Oce (photocopier company), a truck by DAF Trucks N.V., a patient-communication device by Nira (company for communication devices) in co-operation with Well Industrial Design (design agency), a double decker train by The Dutch Railways.

354

ICED 01 C586/137

In this paper we will present examples from this last empirical study. The case histories presented here provide a load of information on NPD-projects within companies. Projects varied in size and type of organisation; some take place in design agencies or consultancies (e.g. Claessens Product Consultants, n|p|k, Well Industrial Design), others within companies or multinationals (e.g. DAF Trucks N.V., The Dutch Railways, Oce). Products varied from relatively simple consumer goods (by Curver), to complex technical systems (by The Dutch Railways). For all case descriptions we interviewed at least four participating practitioners, representing project management, product development, marketing and engineering. Figure 1 shows an overview of some of these products. The analysis of these case histories reveals characteristics of an integrated approach towards new product development.

2.1 Integration of product development and strategy

The Dutch Railways described their vision in "Rail 21', representing their view on public transportation and it's customers in the future. The project for a new double decker train, which is described in the case history, derives directly from this vision. The photocopier company Oce's choice for digital technology had a large impact on their strategy and product development. Functionalities such as printing and scanning came close to the original 'photocopying', which allowed new, multi-functional products. Besides this, the application of digital technology implies software, which makes the development of software applications as important as the development of hardware. These examples indicate that product development is not an isolated activity. It is an activity that should take place in the middle of the company and it's environment. Through products, the company makes a connection between its own strategic wishes, the needs of its customers, and the possibilities left by its competitors. The integration of product development and corporate strategy is crucial; the company must indicate the role of the newly developed product in achieving the future vision it has set for itself.

2.2 Setting the aims for product development

Nira wanted to develop an integrated communication device to be used near a hospital bed, although they realised that this new device would be relatively expensive for the health care market. Until then such a device didn't exist. So the design of such a device would be totally new. Nira choose to collaborate with a design firm, Well Design Associates, to fill the gaps in their knowledge. At DAF Trucks a lot of attention was paid to setting the aims for the NPD-project. DAF Trucks knew the importance of thinking before a project starts. In the 'definition phase' DAF Trucks extensively investigated what the new product should be like and a business case and feasibility study were performed before the 'real' NPD project starts. In this way they try to avoid unnecessary iteration later in the project development. These examples indicate that besides the role of the product in the company's strategy, the company must also have a clear view of what they want with the product, and what the NPDproject aims for. What are the strategic strengths that are built on with this project? What advantages can be made in relation to competitors? What are the most important limitations, risks or key points?

ICED 01 C586/137

355

2.3 Integration of disciplinary knowledge

At DAF Trucks and Oce NPD-projects are systematically performed in teams. At DAF Trucks a 'core team, compiled from different disciplines is given responsibility for the end result. The members of this 'core team' involve people from other departments or even suppliers and customers, if they think suitable. At Oce team work is implemented one step further; all participants of the project, which can have over a hundred people, are co-located. Oce has even built a special building for this purpose, shaped like a UFO. At every round floor of this building, designers, chemists, computer analysts, mechanical engineers, and user interface designers work together on 'islands' of work spaces. R&D-employees are no longer situated in a separate department, but appointed to projects fulltime. NPD being an integrated activity implies that diverse areas of knowledge are needed in NPD projects. This means an integration of disciplines; integrated NPD implies teamwork and revolves around people.

2.4 External orientation

DAF spends a lot of time finding out the needs of the customer. This occurs by continuous market analysis and interviews with drivers and distributors, which sustains new truck designs. Before the project for a heavy-load truck started, over 1700 interviews had taken place with customers, truck drivers and 'non-drivers'. In the development of cosmetic organisers for small girls, Curver paid a lot of attention to customer research. The product they were going to design had to address a new target group. Therefore from very early on in the NPD process, Curver did research with focus groups to investigate the feasibility of the product, as well as to collect the target group's wishes for the product. Later on in the project Curver performed concept tests to check the product's functionality, colours, expected distribution and prices. Knowing what products to develop requires the company to be alert to developments in its environment. An innovative organisation can effectively deal with changes in this environment, such as activities of competitors, suppliers and customers, but also the users of its products. Besides identifying threats from the environment, it is even more important to create opportunities and act upon them with new or redesigned products. Dealing with user information plays a central role within this orientation to the environment. Knowing what the customer wants is crucial to success and even customer participation within the NPD-project is becoming increasingly implemented in companies.

2.5

Structuring the process of NPD

Just like getting a good 'feeling' with the content of the NPD-process, the practising of the process and procedures is important. In the collaboration between Nira and Well Design Associates, the development of electronics, software and hardware was carried out in parallel. This can lead to time- and cost saving. But equally it implies a number of organisational and management problems. By using a systematic method, the process can be structured and the participants within the projects can learn a common language. Practice showed that it is not

356

ICED 01 C586/137

that important which language is used (i.e. saying which NPD model is used), as long as all participants agreed on the same language. The NPD-process in all cases follows more or less the same stages. Of course, for different products and different companies, the emphasis within the processes differs, but milestones like programs of requirements, concepts, and prototypes can be found in all case descriptions.

2.6 Project management

Management is about planning and budgets. We learned from the cases that to be able to achieve the required quality on time and within budget, participants have to be motivated and properly lead. Management is about people. The project manager is a facilitator, both on 'hard' issues (the resources) and 'soft' issues (motivation and trust).

2.7 Creativity in the NPD process

The Dutch Railways conducted a creativity session with 23 people to make an inventory of all needs and requirements, related to the new double decker trains. At the same time they tried to focus thoughts on the concepts of interior and exterior design, so later in the project everyone would know why decisions were made. Nira and Well Design Associates used a creativity session at the beginning of the NPD project to clarify the points of departure. By defining the aims of the project everyone was able to perform their own part within the project (i.e. the development of the software or the hardware) separately. Too often creativity is associated with 'weirdness', artists, or as a trick. The case descriptions indicate that it is especially creativity that should be integrated systematically within the NPD process. It is certainly useful in the creative phases of projects, such as idea or concept generation, but it is also useful in the orientation of problem areas, and selecting or detailing ideas. Dealing with creativity within a company and stimulating the creative behaviour of employees is too often ignored.

Ingredients of integrated new product development

Studying NPD projects provides insights, which are of importance for successful new product development. Few existing models address the integration of corporate strategy and product development, integration of knowledge from all the different disciplines involved in product development and integration of process steps and the management of the quality of the design content within these steps. We have developed an approach that addresses these areas of integration [10]. In our view, integrated new product development is a combination of methodological steps and a way of organising and managing these steps within a dynamic business context. We have introduced a stage-gate model that describes four different stages in the new product development process. In the first stage, 'strategy finding', the strategic direction for the company is stated. During the following stage, 'goal finding', the abstract results of the 'strategy finding' will be worked out into product development assignments. In the third stage, 'product finding', these assignments will be carried out and products will be developed. The last stage, 'implementation', involves the introduction of the product onto the market and

ICED 01 C586/137

357

into the company. For every stage of this process it is important not only to know what should be done, but also what different tools are available to carry this out. The application of this stage-gate model within the company is as important as the model itself. The organisation and management of this approach in a dynamic business context must be aimed at optimisation of the integration of knowledge. We introduce a multi-functional team approach to new product development, and describe how teams can deal with this complex task. Such a multi-functional team is responsible for the integration of knowledge that is needed in the product development process. We also describe other features of the approach, such as the importance of creativity within the process, and the role of the project leader in the project. Both basic elements of integrated new product development - the stage-gate model and the management and organisation - will be described in more detail in the next sections.

3.1 A stage-gate model

Less is more: in our interviews with the different companies we discovered that one of the most important reasons for them to reject theoretical NPD-models is their complexity. Complexity in the number of stages and in the used terminology. NPD-project leaders and NPD-managers want simple models in colloquial language, which are easy to communicate with the members of the multi-disciplinary NPD-team. We looked at numerous models of the NPD-process. NPD-Literature distinguishes five different types of models [11]: 1. stage gate models based on the departments involved; 2. stage gate models based on activities; 3. stage gate models based on NPD-decisions; 4. transformation models; 5. stimulus-response models. We discovered two more: 6. learning models; 7. integrated models. Knowing all these models and working together with lots of companies we developped a model with the least stages which was as integrated as possible. We came up with a four stage model based on the experiential learning model of Kolb [12]. Each of the four stages is aimed at one important goal of the NPD-process. The first stage, 'strategy finding', is aimed at finding the strategic goals of the particular NPD-project. This strategic direction is described in search areas. In the second stage, "goal finding', this strategic direction is translated into the design brief, the specific assignment for the NPD-project team. The result of this stage is the design objective. In the third stage, 'product finding', this assignment is executed and the new product is designed, engineered and tested. The result is the new product. In the fourth stage, 'implementation', the new product is introduced on the market and is used by its intended customers.

358

ICED 01 C586/137

In the strategic steps we suggest a balance between the internal and external orientation of the company. The company should look at its external context; should know what its customers want and what the competition is up to, in order to know that new future business will be successful. However, the company should also know its internal strengths and weaknesses to firmly base these new businesses. In all stages we distinguish between three streams of information. One based on the companies internal strengths and weaknesses and one on the external opportunities and threads. The third stream is the actual NPD-stream in which these two different flows of information are integrated into the new product to be developed. In the product development oriented steps we suggest integration of the different orientations that are required to develop and implement a new product; e.g. marketing, management, production, product development. In every step of the process we indicate the relevant input from all these disciplines and the integrated result of the step.

3.2. Organising & managing

People are the core of every NPD-process. Models without people who are willing to use them are useless. So in our approach organising and managing the people in the NPD-process is as important as the model chosen. We suggest a multi-disciplinary team approach. We call this the Multi-X-approach because maximum diversity of knowledge and insights stimulates the quality of the NPD-process. With Multi-X we stipulate the diversity we are looking for: strive for differences in disciplines, knowledge, gender, age, culture, nationality, etcetra. Of course, at the same moment you want the smallest team possible. Management in general, but NPD-management in particular is about dealing with dilemmas! The Multi-X team itself is not enough. You have to integrate knowledge from group dynamics and organisational development into the approach. If you do not allow time, space and resources for teambuilding, the Multi-X -team will never work. Teamwork requires social interaction and communication of the team members. This implies the challenge to synchronise their thoughts and activities to achieve a design: communication on the content related aspects of the new product development task. It is the project manager's responsibility to achieve good communication in these difficult situations [13]. The role of the NPD-project leader is shifting from leadership to facilitator. But in contrast to the well known idea of the facilitator as content independent our cases and parallel research show that the NPD-project leader should be an expert not only in the NPD-process but also in the content of the particular new product itself. This makes the role of the NPD-project leader very complex indeed.

4. Conclusion
Thanks to our research in a large number of companies, which resulted in series of detailed cases, we were able to expand the traditional NPD-approach. From its narrow based engineering type of abstract modelling, to a more integrated and concrete approach in which a simple NPD-model is combined with a way of working with the model. These additions are the multi-X-team, a project management system and applying creativity. It is this multidisciplinary NPD-team which uses the model creatively as a basis for their project management of the NPD-process.

ICED 01 C586/137

359

We asked the participating companies to give us feed back on our case descriptions. This closing our learning loop showed us that our case based approach is more realistic than the traditional way of describing the NPD-process. References [1] [2] [3] [4] [5] [6] [7] [8] [9] Andreasen, M.M. and Hein, L., "Integrated Product Development". Heidelberg, Bedfor, UK/Berlin, 1985. Pahl, G. and Beitz, W., "Engineering design". The Design Council, London, 1986. Cross, N.G., ''Engineering design methods". Wiley, Chichester, 1994. Roozenburg, N.F.M. and Eekels, E., "Product design: fundamentals and methods". Wiley, Chichester, 1995. Ulrich, K.T. and Eppinger, S.T., ''Product Design and Development". McGraw-Hill, New York, 1995. Buijs, J.A., "Strategic planning and product innovation - some systematic approaches", Long Range Planning, vol. 12, nr. 5, 1979. Buijs, J.A., "Innovation can be taught", Research Policy, vol. 16, pp. 303-314, 1987. Buijs, J. and Valkenburg, R., "Integrale produktontwikkeling". Lemma, Utrecht, 1996. Buijs, J. and Valkenburg, R., "Integrale productontwikkeling". Lemma, Utrecht, second, revised edition, 2000.

[10] Buijs, J. and Valkenburg, R., "Integrated new product development". Lemma, Utrecht, 2001. [11] [11] Saren, M.A., "A classification and review of models of the intra-firm innovation process". R & D Management, vol 14. nr. 1, 1984. [12] [12] Kolb, D.A., "Experiential learning; experience as the source of learning and development". New Jersey: Prentice Hall, 1984. [13] Valkenburg, R.C., "The Reflective Practice in product design teams", PhD Thesis, Delft University of Technology, 2000.

Dr. ir. Rianne Valkenburg and Prof. dr. ir. Jan Buijs Delft University of Technology, School of Industrial Design Engineering, Department of Product Innovation & Management, Jaffalaan 9, 2628 BX Delft, The Netherlands. t: +31 (0)15 2783068, f: +31 (0)15 2787662. R.Valkenburg@io.tudelft.nl, J.A.Buijs@io.tudelft.nl IMechE 2001

360

ICED 01 C586/137

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 2123, 2001

MATERIAL INSTRUMENTATION FOR INTER-TRADE CO-OPERATION - A SOURCE OF INNOVATION: APPLICATION IN THE DOMAIN OF PAINTING AND VARNISH FINISHES
N Stoeltzlen, D Millet, and A Aoussat Keywords: material instrumentation, inter trade cooperation, innovation, paintings and varnishes

Introduction

This article considers the role of material instrumentation in the dynamic of innovation and inter trade cooperation. Within a competitive context, innovation and management of knowledge is an increasing preoccupation in the conception of products. Several actors take part in the product design process. We can quote the designers, the technologists and the marketers: so much competence but different visions. In a first part, we would try to show how material instrumentation can stimulate inter trade cooperation. Then, through an experiment, we would try to show in what material instrumentation can favour innovation.

Inter trade cooperation

We gather under the expression " material instrumentation " all the interfaces and physical intermediaries used in the product design process: numerical sketches, plans, instruments, schedule of conditions, models . . . Synonyms of time saving, they have as main vocation, the total or partial realization of the product. Through our experiments, we realized that the use of such instruments supports "a company memory", exchange of the various points of view and communications between the different actors during the design process. Actually, they transform ideas, knowledge, know-how and competence into tangible objects. " These knowledge can result from internal sources (designers memory) or from external sources (documents concerning objects conceived first by the designer or a third" [1] The existence of these physical intermediaries allows to leave a trace of the company's know-how. Thus, they generate a memory and allow the re-use of knowledge and ideas crossed in a new context and through new company actors. They can thus take over " the intentions " which gave birth to the various intermediaries. " The formalization of the various actors points of view via symbols facilitates the construction of a shared sense and enriches exchanges. These symbols constitute objects borders between professions, by mediatory

ICED 01 C586/572

361

intermediate objects of their relation. They translate their logics and constraints of action and make visible the actors decisions and, give catches to the others ". [2] Furthermore, material instrumentation provokes reactions. It allows the projection of the own knowledge on a tool which crystallizes the various points of view. Besides the problems of respective vocabularies, it is not rare to meet communication difficulties among the different actors. It is not easy to change the point of view. Now material instrumentation allows scoring and clarify each actor's visuals and this precipitate their convergence" / it is by the integration of an important volume of information, competence and ideas that from rich strategic options appear, which allow the company to act of coherent way and to play the set of its advantages. [3] Continuous modeling of actor representations and intermediate materialization within a project of conception returns more explicit action for the others. The creation of a specific physical support clarifies the actions of the various trades and returns so more effective cooperation. The use of these representations and realizations generates strong components of collective training. The set of intermediate successive realizations allows the development of a progressive common project representation by developing its own knowledge. This reflection is illustrated by a visual and tactile inter trade communication support to encourage inter trade communication and to consolidate dynamics of innovation[4], [14]. Indeed, in the example which we shall develop afterward, we realized that there was an important cultural deficit on the characterization of the objective visual and tactile properties of a building material and of its finishing, which makes difficult communication between the various actors and consequently the birth and the broadcasting of new concepts.

3 Experimentation : a visual and tactile support

Visual and tactile perceptions became one set criteria for determining acceptance of many products. Therefore visual and tactile contribution becomes a strategic tool of location and differentiation. It becomes essential to propose to the various concerned actors a support to improve understanding between the various actors to avoid errors of conception due to different interpretations.

3.1 Context
Stylistic innovation became an essential factor of competitiveness on markets general public as different as telephony, car design, cosmetic, or household electrical appliance. Material aspects play a dominating and increasing role. For the manufacturer, visual and tactile dimension became an effective means for consumer seduction and the differentiation of the products which bring value in the product. Various processes of transformation of material, surface treatment and decoration allow to act on this finish. In the first rank of which is situated, in number of applications, the painting and varnish technology. Three major actors take part in the conception of product aspects : the designers, the marketers and the technologists.

362

ICED 01 C586/572

3.2The different actors

We met different potential users of this support to list their wishes. The persons who were met arise from different sectors (design packaging and product, car sector, sensory metrology of car manufacturer, paintings and varnishes applicators . . .). So,we were able to identify the fields of mastery of the various actors (table 1).
Definitions Define the visual and tactile characteristics of the finishing Advise and sell finishing Work out the formulas of paints and varnishes

Designers Marketers

Technologists Table 1 Actor's control fields

These various actors communicate all with diffuse vocabulary and with different perception. The stylist designer uses vocabulary which send back to mental images, impressions, feelings. [5]He works mostly by iconographic analogies. " I seek a colour or for a painting which gives an impression of leather " .The technologist chooses technical vocabulary relating to the chemical constituents, concerning the elaboration of the finish (formulation) or the application. " I seek a finish of tint X having a touch leather and applied by automatic pulverizing ".The marketer uses vocabulary focused on the consumer expectations , according to his interlocutor. This variety of vocabulary is frequently source of conflicts and ambiguities, pulling numerous consequences : problems when designing products (identification, decision), problems when developing (paintings and varnishes formulation), problems when producing (serial applications not corresponding to the reference standard).

3.3Tool presentation
For this inter trade cooperation tool realization, we leaned on the method of multi-field conception developed within the laboratory ENSAM, Paris. We shall not develop [6] this point, it is not the purpose of this article We have, at first realized a state of the visual and tactile art of paintings and varnishes technology by collecting, with formulators and applicators, representative samples of the various visual and tactile families. This stage is very important because of our will to be most exhaustive possible. The collection of samples partner in the analysis of stylistic tendencies allowed us to loose and to confirm a first list of visual and tactile families. This list turns out necessary for our tool conception and the sensory metrology work, used to characterize the visual and tactile families.

ICED 01 C586/572

363

The sensory metrology purpose is to describe objectively visual and tactile characteristics of the samples by associating them sensory descriptors and to organize them by families [13 ]. The work made in sensory metrology allows to have one identical "vocabulary" for all actors. We want to propose a physical instrumentation which can live and evolve with the various users : it is not especially a question of conceiving the same support for all. It is important that it adapts itself to all the implied corporate actors and that the various users can communicate with and through him. It is also very important to consider how the various actors work and how they communicate within the tool development. That is why we met different users, coming from different sectors (the motorcar, produced, design, design packaging . . .) in order to identify their needs. This various meetings allowed us to set up a list "use scenarios" and draw up those in which we will find communication problems (figurel).

Figure 1 : configuration ou se posent des problemes de communication

Further to the functional analysis, were defined the points which the visual and tactile support should answer: To identify and to select a touch : help in the creation, helps in the decision. - To propose and to specify a touch : help in the communication. - To control a touch : help in the validation (development / production). -To develop new touchs : help in the characterization of the existing, identification of the ways of development. So the visual and tactile support becomes at the same moment a support of inter trade cooperation and a technological watch tool. The examples of exploitation of the support are numerous and answer problems customers concrete, namely : -To study visual and tactile preferences for the marketing. - To communicate to distance on the visual and\or tactile depiction of a finish. - To know offer in terms of paintings and varnishes. - To present the technological offer. - To know the correspondence of a touch for the development and the production. - To analyze competition (characterization of a visual and tactile products perception, location on a visual and tactile space . . .). - To direct the developments of new touchs (to understand the influence of the various formulation and application parameters, ingredients and processes).Meetings, associated to the need and functional analysis allowed us to write a list of indispensable elements which have to compose our support:

364

ICED 01 C586/572

Sketch 1 : confirmed principle

The principle which we confirmed is a concrete "multifacet" support articulated around an organization of modules representing one by one the various visual and tactile families. The user can, at first constitute his tool of modules of his choice and develop it by completing it according to his needs. He can also feed it of virgin modules to personalize it, according to the industrial sector for example. The shape of the visual and tactile tool favors confrontation among the three actors because it allows among others : -To compose harmonies -To organize pages of style -To personalize the tool according to its activity -To propose various supports The stylist designer finds there a tool to compare, to choose and to present finishes ; the marketer can present and communicate finishes and the technologist finds there reference standards and all the technical information to formulate and to compare finish applied with samples. Moreover, the descriptors to which various samples are associated offer a system of location, which is the same for the various actors. Every actor can so use the "filter" which is convenient for him and can so understand the way to work of another actor. So, every actor can use " the suited filter " and understand the working way of the others. Rather than to be an universal tool of communication, this tool is in fact a material support allowing the confrontation between the various actors. It offers also easier and more effective communication. The points of view of the different actors converge on this tool. It is so possible to build a real communication between various professions. In the same vision, we can quote a study, basing itself on the phenomenon of color in the product conception realized by Herve Christofol [ 7 ] . This study uncorked in the implementation of an inter trade cooperation tool intended for the designers, for the project managers or for the decision-makers, helping them to understand the phenomenon of the color and to express their creativity within the product conception.

ICED 01 C586/572

365

4 Discussion and conclusion

OCDE defines innovation as an improvement. Thus, a change can not claim to be an innovation if it doesn't bring an advantage for the company, the person and the society. In other terms, " To innovate, it is to take risks, to dash into the unknown, to go to meet the unpredictable ". [8] Innovation is also the capacity to cross of a new idea in marketable object and in a realization of new combinations between various resources professions by the company [ 9 ]. Innovation is collectively admitted as having an individual birth. However, the reason to be is in the sharing. As a result, an innovation does not exist without the membership of the others (hierarchy, users, look for etc. . . .). Innovation is a collective phenomenon but not necessarily voluntary [11]. Indeed, to obtain a gaining change, it is necessary to multiply exchanges enter the biggest number of persons of various professions. As explains it R.W WRIGHT [ 10 ], "Indeed, resources based on knowledge are essential factors of force and constraint in the development of the innovation and the competitive advantage. " In this optics, we recommend the use of instruments physical as " catalyst of innovations ". Our tool modularity allows through the manipulations of the samples to try new combinations without constraints connected to the cost of these attempts. They give concrete expression to new ideas until then little envisaged. Through the unpredictable association of new combinations innovative concepts are born (for example, painting silvered with soft touch) and spread. This broadcasting is facilitated by the use of a realized reference, common to the various actors. Our tool of inter trade cooperation is still in development and it remains completely opened and flexible towards the other sectors in which arises the problem of inter trade cooperation. Moreover, it is very important to formalize such a tool as soon as possible in the product design process in order to avoid conception problems (due to the use of a same vocabulary which doesn't mean the same thing for the different actors, for example) and to improve communication between the different actors. It is evident that this article presents in a concise way made work and that it is not the end in itself. F. Daniellou explains that " competence is not passed on. If one considers them as the track on our body of our personal experiences, it is clear that there is no possibility of " transplant " of the competence of the one on the body to another one " [12]. That is why we decided to create a tool encircling a ground of communication and enrichment : an interactive innovation source.

References
[1] Falzon and collar. " Les activites de conception : 1'approche de I'ergonomie collective ", Colloquium Searches on the design, Instigations, Implications, Interactions, 17,18 , 19 Oct. 1990, Compiegne. [2] Vinck D, 1999 Ingenieurs au quotidien. ed. INP Grenoble, ISSBN 2 7061 0876-2 , p177

366

ICED 01 C586/572

[3] Giget M, 2000 La dynamique strategique de 1'entreprise. ed. Dunod. [4] Stoeltzlen N., on 2000, Conception d'un outil intermetiers. application au domaine des finitions; Memory DEA CPNI, Paris. [5] Lawson B., on 1972, How designers think, architectural Press. [6] Aoussat A ., on 1990, La pertinence en innovation : necessite d'une approche plurielle. document of doctoral thesis CPNI Paris. [7] Christofol H., on 1995, " Modelisation systermque du processus de conception de la coloration d'un produit ". Document of thesis. [8] Interview with Judic J.M. Dr, Faurecia Innovation Department Manager, on 2000. [9] Regenthal, on 1981," Design und seine soziale Funktion ", licht 12/81, p648-655. [10] Wright R.W and Collar. On 1995, " Les principes du management des resources fondees sur le savoir". French Review of management, seven - Oct. 1995 , p70-75. [11] Atkinson A and al., Enhancing the innovation and creativity of technical professionals, technology management. 1988, Publication TM1. [12] Daniellou F, 1999, Actes des journees de Bordeaux sur la pratique de 1'ergonomie. p16 [13] Bassereau, Jean-Franfois.- Cahier des charges qualitatif design, elaboration par le mecanisme des sens.- Thesis ENS AM, 1995 16093 [14] Edward T.Hall - La dimension cachee - essai, Edition du Seuil- 1966

Nadine STOELTZLEN, Dominique MILLET, Ameziane AOUSSAT New Product Design Lab. (Laboratoire Conception de Produits Nouveaux et Innovation) ENSAM (Ecole Nationale Superieure d'Arts et Metiers), Paris 151 boulevard de 1'Hopital 75013 Paris, France Tel: (+33) 01 44 24 63 80 Fax : (+33) 01 44 24 63 59 E-mail: nadine.stoeltzlen@paris.ensam.fr IMechE 2001

ICED 01 C586/572

367

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

GEOMETRY USERS FROM A PROCESS PERSPECTIVE

F Fuxin Keywords: Business process re-engineering, Change processes, Concurrent Engineering

Introduction

This paper describes the Process Domain, which constitutes one of the four domains that form the Geometry Management Process (GMP). The main theme is to establish systematic methods, processes and perspectives on Geometry Based Product Information (GBPI). The result will contribute to elimination of rework and to increased integration in the extended enterprise [1]. The Function Domain and the Requirement Domain have been outlined in greater detail in [2]. The fourth domain, the Realisation Domain, deals with ways of realising geometry representations, that is the tools for generating, packaging, and viewing. Figure 1 outlines the structure of the GMP. The original hypothesis has been that it is possible to divide the GMP into four separate domains. The initial efforts were made in the function and requirement domains. This publication deals with the process domain. The domain is introduced in the following chapter. Next chapter presents the proposed process, both a broader perspective and in detail. The final chapter is conclusions.

Figure 1. The Geometry Management Process and relevant domains.

The process domain

The gradual transition from traditional towards digital product development will favour a well-established process for managing GBPI. The basis of the process domain relies on studies of the evolution of geometric maturity through different stages of the product development process. All studies and surveys were conducted at the Volvo Truck Corporation in Goteborg, Sweden. In the studies, a portion of a heavy truck front axle assembly was used, see figure 2, but issues that are more general have also been taken into consideration. One of the obstacles to increased integration is that the various activities have to be carried out concurrently. It is therefore difficult to manage and sort all the various perspectives on GBPI. Digital product development results in that the digital master, which must be accompanied by new methods and procedures, will replace the physical master. In a company, there is normally a top-down approach where a project plan prescribes different stages to be carried out throughout the duration of the project. The GMP should support the construction of this

ICED 01 C586/607

369

project plan. The process domain's most important question to answer is "when"; when has a component, sub-assembly or module reached a level of detail (L.O.D.) where it supports all the downstream requirements of a specific function (e.g. product preparation, marketing)? Furthermore, it should be possible to adapt the process domain to different levels of the project, i.e. from a generic level to direct realisation level for different activities and tasks.

Figure 2. The chosen front axle assembly.

There are many methods and theories for how product development should be carried out. They normally divide the product development process into phases, for example Concept Development, System-Level Design, Detail Design, Testing and Refinement and Product Ramp-up [3], The process proposed in this publication comes from application of a geometrical perspective on tasks, activities and co-operation in the development environment. It is motivated by the gradual transition from traditional towards digital product development and should not be considered as a stand-alone process but as a complement to existing business processes.

2.1 The broader perspective on the development process

Conceptual development and detail development deal with the creation of the new product. The geometrical foundation is from the very beginning rather vague for those components/modules that not are directly carried over from previous products. During a given project, the geometrical foundation matures and one stage is replaced with the following one; what is taking place is stepwise refinement. Thus, it is reasonable to argue that the development process is iterative during these stages [4]. The design engineer's knowledge about his/her new component/module grows when new problems are penetrated and solved during evolution towards a product that meets predefined specifications [5]. The various activities throughout this iterative sequence are decomposed and generic elements are synthesised. The resulting activities, inputs and outputs are to be considered as generic constituents that populate a generic process. A top-down approach is applied where an important extra stage, preconceptual development, has been included, see figure 3. The growing importance of GBPI is the reason why the preconceptual stage has been introduced. The geometry users in the last stage, industrialisation, will definitely benefit from adequate and accessible GBPI when generating assemble documentation, educational material, service information and marketing brochures. It should be pointed out that these users not are interested in refining the L.O.D., they are interested in applying already created GBPI. However, the activities will justify additional time and resources spent at the earliest stages on definition and adaptation of geometric information. This is the holistic view of GBPI elimination of rework in downstream functions by a structured approach on GBPI.

370

ICED01-C586/607

Figure 3. Proposed different stages in a product development project.

2.2 Basis for process construction

A major project is a complex set of activities that have to be coordinated. A product development process should support and coordinate these activities. Almost all activities that constitute the major process have inputs, outputs and some controls/constraints that must be followed. Furthermore, to realise the activity, appropriate resources and tools must exist. Inputs, outputs, control/constraints and resources/tools are fundamentals of IDEFO. They have been applied to the process domain. From the studies conducted, different factors that influence geometry have been identified. These will be briefly presented. Inputs. Each activity has geometrical input. The L.O.D. will differ depending on where in the process the activity is located. Some fundamental properties of the input will always prevail. The specified product structure must be sent together with the geometric representation, the hierarchical position. The expression "carry-over" has thus far been used for components and assemblies carried over from earlier product projects. A redefinition of this expression is made. The same signification is still valid but it may also denote geometrical input from an earlier activity together with geometrical interfaces for adjacent modules. Resources and tools. Staff and functions that must be made available for fulfilling the refinement activities. Partners and suppliers are also to be considered as resources. The notation tools are the tools needed for realising the refinement activity. The range of tools extends from modelling tools, via assembly and packaging tools to more simple viewers. Controls and constraints. Strategies/rules and guidelines, for example demands on commonality and modules, affect the refinement activities. Time plans are constraints that must be followed. Control of product and process documentation must be undertaken continuously to follow up and secure the project's progress. Output. When the refinement activity is completed, the result - the refined geometrical model - should be made available for subsequent activities. The iterations are caused by what is called geometrical modification requests. Some of the subsequent activities mentioned have an obligation to provide a response. In earlier stages, this obligation may merely comprise simple viewing and communication of opinions, but this could extend to problems, for example when applying the GBPI in assembly simulations. Many of these activities can be directly associated with a given function. Figure 4 illustrates the collected aspects together with some examples taken from different stages.

ICED 01 C586/607

371

Figure 4. Generic structure for decomposition of the process.

Any shortcomings that are discovered must be corrected and they will inevitably result in iterations. Depending on the degree of the shortcoming, the iteration can be directed to the previous activity or all the way back to preconceptual development, in the worst-case scenario. Each stage should refine its given L.O.D. to its next L.O.D. The refinement procedure is more or less independent of the state to which it is applied. Thus, the refinement procedure is subdivided into three chronological steps. Each step is described briefly. Identification. Each stage, and each activity, receives some type of geometrical representation or definition as input. The objective for one stage will be stated in advance. Therefore it is essential that given geometrical prerequisites are identified, stating how the objective might be fulfilled. Have there been any alterations to interfaces or allocated space? This procedure of identification must be performed before any other activities can be initiated. Optimisation. The degree of refinement will improve during the fulfilment of one stage. The assembly structure and physical functions must be optimised towards the stated objective in each stage. In early stages it is of extra importance that these two are highlighted since there will be no physical prototypes where optimisation of these structures and functions can be performed. The focus will shift once the physical prototypes are introduced, and these prototypes will serve as verification rigs where simulations must be validated. Verification. Conclusions and verifications are always important when summing up current status, especially when the same personnel do not perform forthcoming activities. Have there been changes from the initial geometrical prerequisites; will they affect stages and functions downstream? Are the physical functions verified? Is it possible to manufacture and assemble these components and assemblies? The carry-over of components, assemblies and interfaces are verified and summed up here before being sent on to next stage. Preconceptual development Preconceptual development deals with compilation of relevant geometric information at early stages before the actual development activities are initiated. The objective with this stage is to establish geometrical preferences that are as unambiguous as possible. Some of the recommendations proposed will generate extra work during the earlier stages, in addition to the extra effort that must be invested in summing up all the requirements. Eventually, these extra efforts will pay off when the latter stages utilise already-generated GBPI.

372

ICED 01 C586/607

Most companies utilise large carry-over percentages from earlier products. In this work, geometrical interfaces are also regarded as carry-over material. Product structure will strongly influence development and utilisation of GBPI. Product structure issues will be interpreted from different perspectives, such as modular/commonality and geometry users' perspectives. The matter of uncoupled development activities must be addressed during the preconceptual development phase. There are several reasons for conducting uncoupled development, for example advanced engineering projects or other major systems with their own development cycles. Nevertheless, by properly introducing them at this stage, preparations can be made for their incorporation. The finalisation of the preconceptual development is completed when the degree of refinement of the L.O.D. has reached envelope. Identification. This geometrical input to the preconceptual development stage is composed of carry-over material. On top of these prerequisites, considerations must be given to variants of the future product and to requirements of geometry users who will participate in the forthcoming effort. In this context, carry-over material is regarded as either geometrical representations from previous product projects, geometrical interfaces between different modules (or sub-modules/components) or modules originating from uncoupled development activities. Identification of carry-over material is one of the primary objectives since it will serve as a reference for the space allocation of envelopes and decisions upon interfaces. For components and modules that are to be designed, these geometrical entities will serve as boundaries in the development work of each module. The product-planning department will specify which variants are to be included in the project. The specified variants are generated by a modular structure where commonality aspects are taken into consideration. The proposed method for categorisation of geometry users will add additional requirements to the product structure. Thus, by utilising this methodology, relevant GBPI is generated and in this way, geometry users are taken into consideration from the very beginning of the future project and rework in downstream activities is reduced. The refinement procedure for the preconceptual development stage is synthesised in figure 5.

Figure 5. The preconceptual process procedures.

Optimisation. Preconceptual development does not primarily deal with physical function and assembly structures. However, since the geometrical definitions are carried out in the identification procedures, it is feasible to undertake the first preliminary checks of physical functions and assembly structure. Verification. The output from preconceptual development is compiled here. Are the original specifications fulfilled? Is it possible to geometrically generate all variants in a systematic manner? Will different categories of geometry users have access to relevant geometrical configurations? In the verification procedure, response must be received from areas with long

ICED 01 C586/607

373

lead-times. This last remark concerns manufacturing and assembly operations where implementation times normally are crucial for entire projects and for their success. There are also other aspects to decide on when specifying the geometrical requirements of the project. One such aspect concerns communication between companies and suppliers, or partners, when there are different CAD systems [6]. Specifications should be made for neutral formats, and perhaps appropriate application protocols, for communication. Conceptual Development The primary objective of this stage is to evaluate several possible proposals and to reach a final concept. The geometrical input to the conceptual stage is more rigid due to the introduction of the preconceptual stage. For a specific module, the geometrical refinement activities will depend on just how many carry-over parts can be used. The result is that some organisational functions will have to start with an envelope with accompanying interface/interfaces. Other functions should concentrate on optimising an already existent concept and updating interfaces to surrounding modules. From the geometrical point of view, the vague envelopes, together with more defined GBPI, should at the end of the stage form a draft L.O.D. Since one or more design functions may not often be located in the same building, or even the same part of the world, regular collation and follow-up are important. Communication is one of the keys to success for the project. Collaborative work and distributed engineering must rely on, and have access to, reliable GBPI. Identification. The input to this stage consists of a mix of envelopes, interfaces and carryover parts/modules. A module will always have one or many interfaces. This is valid for both envelopes and carry-over modules/parts. The first step towards finalising the concept is to agree upon the interfaces. Different modules are joined by interfaces and so too are the organisational functions responsible for the modules. Interfaces are the physical connections to adjacent modules and they are therefore the facilitators of the physical function specified. The envelopes serve as boundaries when evaluations of different concepts are made. The geometrical interfaces connect the different envelopes. All concepts generated will be evaluated against each other and against how well they fulfil the specification of the new product. The geometrical refinement activities depend on the amount of carry-over parts. Initially, organisational functions sharing an interface must ensure that the interface fulfils all connection requirements. Once a mutual agreement on interfaces is established, the focus is turned to physical function and product structure requirements. Optimisation. At this stage, preliminary evaluations must be conducted for the most credible concepts. Carry-over modules and parts have a well-founded geometrical basis from which to start off. Concepts starting with an envelope will have to be further refined before evaluations can be performed. The lack of physical prototypes implies that most decisions must be made from digital simulations and analyses. Even with low level of detail, it is today possible to perform extensive evaluations; e.g. technical calculation and motion/clearance analysis. This of course requires that the company has built up methods and procedures for supporting assessment during the early stages. Product design is one area where visualisation techniques have made it possible to iterate faster. Verification. Before the conceptual development stage is concluded, the physical function, assembly structure and product variants must be verified against the product specification. The end result is the concept that will go through detailed design. The L.O.D. must at least be of draft quality. Drawings have in the past been the only way to communicate with

374

ICED 01 C586/607

downstream stages. The computerisation of all stages has made it possible for downstream functions, for example production preparation, to both view and utilise already created GBPI. In the latter stages of the refinement procedure of the conceptual development stage, most functions should have access to the draft L.O.D. Management of variants and versions is extremely important. The more functions involved in refinement activities, the greater the emphasis on this type of management. The digital master replaces the physical master, and that lasts for the entire product lifecycle. It must constitute the master reference for all variants and versions. Detailed design The detailed design stage encompasses the fulfilment of the highest level of detail and in the end the introduction of physical prototypes. The gradual transformation of the GBPI, from draft to detailed L.O.D., is associated with rigorous efforts. The generation and distribution of adequate geometry representations rely on competent management of the GBPI and the way in which it should be made accessible to all personnel involved. The concept of digital masters must be clearly stated, communicated and utilised. The initial refinement activities must focus on securing physical function and on ensuring that all suppliers are well informed about the requirements concerning their components and systems. This is the prerequisite for the first generation of physical prototypes. Critical areas and parameters detected from previous activities must be incorporated. There are several functions downstream of detailed design that have high requirements on the level of detail. Some of these functions are to generate illustrations or market material with a high level of both detail and visualisation. Other activities will run in parallel with the refinement activities of the relevant stage. The coordination of geometry-based product information between the parallel activities is important. Identification. Draft is the lowest L.O.D. of carry-over material to enter this stage. Critical parameters detected during optimisation and verification in the conceptual development stage are invaluable as input to the detailed stage. One example is critical clearances detected during motion analysis. There are several functions waiting for the level of detail to reach their set requirements. It is essential to identify when these requirements will be met at this stage. This is necessary in order to be able to start up these activities as soon as possible. An update with the uncoupled activities will identify if there are any mismatches in co-ordination. Before the final refinement activities are initiated, all interfaces should be thoroughly analysed regarding physical function fulfilment. Optimisation. GBPI must be optimised in several different aspects to reach detail L.O.D. It is not until this stage that the utmost refinement can be performed. All radii, chamfers and tolerance zones should be optimised for low weight, tensile properties and cost. Packaging studies, computational models, endurance simulations, manufacturing logistics, assembly operations, maintenance simulations - all these must in the end be performed on real physical products. The physical prototypes that are built are thoroughly selected. The selection is based on earlier experience and from critical specification detected in the conceptual development. In order to further refine and optimise digital product development, any detected mistakes caused by incorrect assumptions in the computer models must be properly documented. They will serve as input to the geometrical prerequisites in the next project. Verification. The physical prototypes must be verified against the product specifications. The prototypes will also verify if it is possible to assemble the products as intended. Verification should be made against rules and regulations (certifications). Verification must also be made

ICED 01 C586/607

375

of the GBPI against the physical prototypes, taking into account tolerance management and measures. One of the prerequisites for digital product development is that the GBPI will reflect reality. Some approximations will always be done and it is extremely important to document this knowledge about what should be considered as an acceptable approximation.

Conclusions

The investigations and studies have clearly indicated that there is a need for a Geometry Management Process. Furthermore, the GBPI must be viewed from a holistic perspective to take full advantage of digital product development. The method of categorisation is one way of mapping corporate requirements on GBPI. It has been proven that it is possible to take the requirements of different categorises of geometry users into consideration in the product development process. The process perspective makes it feasible to detect when the requirements are to be met in the product development process. The breakdown of the process domain into different levels makes it feasible to bridge gaps between project management and personnel working in the line organisation. This article deliberately makes no mention of any tools or systems since it presents the process domain. However, it should be pointed out that in the CAD tool most geometry refinement activities take place. Packaging and viewing tools depend on a geometry base originating from the CAD tool. In these tools, no design modifications are made. Acknowledgements Financial support for this research was provided by Volvo Truck Corporation and the Swedish Strategic Foundation's national programme ENDREA (The Swedish Engineering Design Research and Education Agenda). References: [1] [2] [3] [4] [5] [6] Mantyla, M., Tomiyama, T. and Finger, S. "Knowledge Intensive CAD: Volume 1". Chapman & Hall, 1996. Fuxin, F. and Edlund, S. "Categorisation of Geometry Users". CONCURRENT ENGINEERING: Research and Applications , Volume 9, March 2001. Ulrich, K.T. and Eppinger S.D., "Product Design and Development". McGraw-Hill, 1995. Prasad, B. "Concurrent Engineering Fundamentals: Integrated Product and Process Organization". Volume 1, Prentice Hall, 1996. Blessing, L. and Wallace K. "Supporting the Knowledge Life-Cycle". Ifip Tc5 Wg5.2 Third Workshop on Knowledge Intensive Cad, 1999. Krause, F.-L., Tang, T. and Ahle, U. "Innovationsforum Virtuelle Produktentstehung". Vortrage, 2000.

Freddy Fuxin, Volvo Truck Corporation , Dept. 26603 AB3, SE-40508 Goteborg, Sweden. Tel: 446 31 765 21 63, Fax: +46 31 226203, E-mail: Freddy.Fuxin@volvo.com IMechE 2001

376

ICED 01 C586/607

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

CONCURRENT DESIGN OF PRODUCT AND PACKAGE - EXTENDING THE CONCEPT OF IPD

C Bramklev, R Bjarnemo, and G Jonson Keywords: Integrated Product Development, Interviews, Design of Packaging, Survey

Introduction

As a result of the globalisation of the world economy, many enterprises that previously confined their business activities to national markets are now focusing on broader international markets, thus forming the basis for the establishment of global enterprises. In addition to the extension of markets, these global companies also seek cost reductions through scale economies in logistics, marketing, product development, production and purchasing, and through focused manufacturing and/or assembly operations - Christopher [5], Porter [10]. In order to contribute to the establishment of global enterprises, an interdisciplinary research project has been launched at the Department of Design Sciences, Lund University, Sweden, as a collaborative effort between two of its divisions - Machine Design and Packaging Logistics. The overall objective established for the project is to: "facilitate the establishment of successful global enterprises by providing methods, techniques and an overall procedure model for integrating packaging logistics into the product development process. " By extending the concept of Integrated Product Development (IPD) to include the concurrent design of product and packaging, increased efficiency and effectiveness in the product development process are conceivable. Apart from the apparent advantage of reducing the time to market, environmental impacts in terms of a reduction in the consumption of raw materials due to the possibility of facilitating a "tailor-made" packaging of the product are also conceivable. As a result of the development of more efficient and effective packaging of the products, a reduction in emissions from the distribution of the products is also expected. For the development of the product-to-be, the packaging might provide alternative, less costly, solutions; this especially applies to those products, which have to withstand major structural loads during the distribution phase of the product life cycle. The overall concept of integrating relevant activities from the packaging logistics area into the IPD process has been introduced in a previous paper - see Bjarnemo et al [1 ]. In the paper presented here, the main objective is to:" establish the industrial relevance of introducing the concurrent design of product and packaging thus supporting or rejecting the key element in the previously developed integration concept. " The secondary objective is to: "obtain more detailed information on the actual handling of the interaction between product and packaging design in industry." The latter information is intended to be used either for the further development of the extended IPD concept or for providing a more detailed view why the integration concept has to be rejected.

ICED 01 C586/609

377

In order to obtain the information requested, an explorative survey has been performed in Swedish industry. The findings from this survey and its implications, as outlined above, are reported here.

Basic concepts

In a literature survey reported in Johnsson [7 pp 36-37], a large number of definitions of packaging were found. Based on Paine [9], the following definition has been derived and adopted here: "Packaging is a means of ensuring safe and efficient delivery of the goods in sound condition to the ultimate consumer followed by an efficient reuse of the packaging or recovery and/or disposal of the packaging material at minimum cost". In this definition, "packaging" should be interpreted as ranging from simple wrappings to advanced specialpurpose containers, thus also indicating the hierarchical nature of packaging. One alternative, and maybe a more operational view of the subject in the given context, is to focus on the product features needed in the different phases of the product life cycle. By considering packaging as an "extension" of the product during the manufacturing phase until it is installed/mounted and the packaging is removed from the product, an understanding of the integration of the design and development of packaging and product is facilitated. As long as the technical performance of a product constituted the single most important competitiveness factor on the market, an efficient and effective approach to the design of the product-to-be alone represented the most effective and efficient means of increasing competitiveness. However, as the adaptation to business, industrial design, market/consumer, production, sales etc. became equally important in handling the competition on the global market, new methodologies focusing on the overall development process, the product development process, were developed. Note that the creation of procedure models for the product development process represents an extension of the previous models provided within (engineering) design methodology. In other words, the design procedure becomes embedded in the product development procedure model - see Bjarnemo [3]. The common denominator in these new product development procedure models is the close interaction between a number of the functions of the enterprise, such as design, market, production and sales. Another characteristic of these procedures is the organisation of the work in cross-functional teams. Undoubtedly, the most significant driving force in the development of tomorrow's product development procedures will be the rapid development in modern Information Technology (IT) - including not only hardware and software computer components, but also the links for digital communication. Since communication is the essence of integration, it is only logical to focus on the IPD- procedure as having the inherent potential to become the most successful development procedure of tomorrow in the light of the product development procedures existing today - see Bjarnemo [2]. The product development procedure model referred to here is the original one developed by the late Professor F. Olsson - see [8]. At the Design Policy Conference in London in 1982 this model was revised and renamed. The revision and renaming were undertaken by Professor Olsson in close cooperation with three Danish researchers, Professor M.M. Andreasen, F. M011er Pedersen M.Sc. and Technical Director L. Hein. Together they

378

ICED 01 C586/609

presented the new procedure model under the name Integrated Product Development or simply IPD, see Hein et al. [6]. In Olsson's original model, the procedure integrates four functions or subprocesses: market, production, (engineering) design and business/finance. In the IPD procedure model, the procedure is decomposed into five stages. The underlying strategy utilised for the decomposition of the complete development procedure corresponds to the decomposition of the design phases of the underlying design methodology, which means that the inherent logic of the engineering design process forms the basis of the whole procedure model. In turn, each and every one of these design phases is decomposed on the basis of a five-step creative problem solving procedure. The most important conceptual cornerstone in the building of the IPD procedure is integration. In this context, "integration" should be interpreted as connecting people, processes and technologies. However, when integration is mentioned, it is usually "vertical" integration between the functions (i.e. between the people and the subprocesses) which is referred to. It is important not to forget "horizontal" integration, or maybe more adequately in the present context, the compatibility between the subactivities forming each of the stages of a given function. In other words, the latter integration/compatibility refers to the integration along the time-axis of the project and within each and every one of the subprocesses, thereby focusing not only on connecting people and process but more specifically, on connecting technologies which focus on the product-to-be.

Survey approach

As the IPD procedure model originates from studies of product development processes within mechanical engineering, it is suitable to confine this survey to the same area for theoretical as well as practical reasons. The classification of a product as mechanical is simply based on the fact that its main working principle constitutes the technical realisation of physical (mechanical) effect(s), or that a majority of its subsystems in turn are based on mechanical working principles. In future projects, additional product areas such as those of medical and pharmaceutical devices as well as food and dairy products will also be surveyed. The lack of a commonly accepted terminology creates major problems whenever attempts are made to extract information from mechanical engineering processes, especially when design and development processes in industry are surveyed. To decrease the impact of these problems to some extent, a survey technique based on the combination of a questionnaire and an interview was chosen - see Bjarnemo [4]. In this combination, the questionnaire is simply intended to prepare for the interview, as far as possible. After the interviews, the responses, as transcribed by the interviewers, were sent back to the respondent(s) for correction(s), if necessary. Other issues related to the survey were: Selecting companies and identifying respondents Formulating relevant topics for the interviews

ICED 01 C586/609

379

3.1 Selection of companies and identification of respondents

In addition to being a company developing, producing and distributing their own (mechanical) products, the company selected should not be situated too far away from Lund; 200 kms was deemed "not too far away". Within this area there are no larger mechanical engineering companies, which confined the survey to small and medium sized companies (SMEs). The number of companies, i.e. the sample size, was set at 20. This is a number, which ensures the existence of a corresponding number of companies within the other products areas of interest to the future surveys. Furthermore, the companies were selected "almost" at random. In the present context, "almost" refers to the fact that a majority of the companies are not totally unknown to us, at least not as far as their product development functions are concerned, but we are not familiar with their handling of the development of packaging issue. In each of the companies selected, the product development manager was approached and asked to be responsible for the answers given by the company. This gave the product development manager the freedom to select who was going to answer/discuss the interview topics with us.

3.2 Formulation of topics for the interviews

The preparation of the questionnaire focused on six main topics. These topics/questions were: 1. Company characteristics 2. The process of product planning/product renewal 3. The company's product development process 4. The role of packaging 5. The interaction between packaging and product 6. The role of packaging in the product development process today and tomorrow These topics provide the information necessary for being able to answer the overall questions presented in the objectives established for the project reported here. For each of the topics above, a number of questions were included in the questionnaire and discussed during the interviews. Due to the qualitative nature of the questions and the fact that this survey is of an explorative nature, statistical methods will not be used in evaluating the results. However, statistical methods will be used in the evaluation/comparison of the overall results from this and future surveys.

Survey results

As previously mentioned, each interview was prepared in advance by confronting the product development manager with the six topics and their corresponding questions. In a majority of the interviews, extensive discussions followed each question. For obvious reasons, full accounts of these answers have not been included in the presentation of the survey results below.

380

ICED 01 C586/609

In order to limit the presentation of the findings of the survey to the relevant issues with reference to the objectives established for this paper, the main part of the answers/information obtained is given in the form of a "Yes" or a "No". All the results have been condensed into two tables. In Table 1, each of the companies is introduced with reference to what kind of products they develop and produce. The size of the product development staff as well as the investment in R&D (in % of the annual turnover) are also included in order to give an insight into the company resources available for product development and design. The final question accounted for in Table 1 is the use of a formalised approach to the product development/design processes. Note that the term formalised approach simply indicates the existence of a procedure model to be followed in the development process and that this procedure is documented. The term is used in order to avoid any value added characteristics such as methodical or systematic.
Table 1. Topics 1-3: Company characteristics, PD1 staff and resources and the use of a formalised approach Investment Formalised in R&D development (% of process turnover)

Company

Products

PD'
Staff

A B C D E F G H I J
K L M N

Fuel handling systems for petrol stations Products / systems for handling coins and banknotes

30 25
6

8 15
5

No Yes Yes No Yes Yes Yes No Yes No Yes

Pot washing machines

Sights for firearms Parts cleaners for body shops and tire shops Dialysis machines and equipment Heart-Lung machines and heater coolers Web cleaners, tension control, breaks and pumps Aseptic dosing units / machines for foods Walk-behinds and lawn mowers

4.5 5
90 6 2 15 1 11

7 7 5
25 2

10
2 15

Injection moulding of pharmaceutical devices

Telecom heat exchangers Hygiene systems within geriatric care Industrial metal products; white goods Brakes and brake systems Door automation systems Exhaust extraction systems Power transmission parts and components Recycling systems for stores and industry Industrial door systems 'PD = Product Development

2 15
5 47

20
4 2

No
Yes Yes No Yes Yes No Yes Yes

O P

18
7 12

4 2
4.8 4 4 3

Q
R

3 14

As expected, and useful for the survey, the products supplied by the companies cover very diversified markets. As for resources for the product development function, these range from a staff of 1 up to 90 people; consultants are not included in these numbers. When the investment in R&D is compared, there is a clear demarcation as to which of the companies are relatively newly established and/or have adopted a pioneering product strategy, and those companies which have established themselves on mature markets and thus keep a lower development profile. Note that 35% of the companies claim that they are not using formalised

ICED 01 C586/609

381

approach to the product development process. This figure may be somewhat misleading as, some of the companies that give a negative answer do use a formalised approach in the actual development process, even though it is not fully documented. In Table 2 the main results, referring to topics 4-6 of the survey, are presented. Table 2. Topics 4-5: Package specifications and relation package - product
Topic 5 - The interaction Topic 4 - The role of the Topic 6 - The role of the packaging packaging between packaging and product in the PD-process today and tomorrow

A B C D E F G H I J K L M N 0 P

0
R S T

Y Y Y Y Y Y Y Y Y Y Y Y Y Y N Y Y N Y Y

I, P I, P I, P, Eg Eg, Ex,T, P, L P P, R P P Au, Ce, P, L I, L, P, T Au, H, I, P As, P Au, L, P I, Ex, P P As, P P P P Ce, P

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N Y

Y Y N N Y Y N N Y Y Y N Y Y Y Y Y Y Y Y

N Y N Y Y Y Y Y N Y Y Y Y N Y Y Y N Y Y

Y N Y Y Y N N N Y N Y Y Y Y N Y Y N N Y

N N N Y Y Y N N Y N Y N Y Y Y Y Y Y Y Y

Y Y N Y Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y

Y = yes, N = No
As = assembly/installation support Au = support mfg. automation Ce = cost effective Eg = ergonomic

Ex = expose product P = protect H = hygienic R = environment friendly I = carry information T = traceable L = logistics and distribution adopted

Regarding the specification of the packaging, 90% of the companies carry this out as a part of the overall development project. It was also clearly indicated during the discussions that not only the packaging as such, but the whole product distribution chain, are identified today as being significant factors in the overall development efforts. Not very surprisingly, protect was identified as the single most important packaging function. In i.e. 7, 35% of the companies, this was the only function required of the packaging. The second most important packaging function, corresponding to 30 % "Yes" from the companies, is to inform. In 5, or 25%, of the companies, packaging was used as an integral part of assembly/installation and automation in the manufacturing process. However, several other companies are contemplating this use of packaging.

382

ICED 01 C586/609

In all but one of the companies, the development of the packaging was carried out within the product development project. Even though 75% of the companies claim that the packaging helps to withstand structural loads during the distribution phase, only one of the companies was actively planning to integrate this effect in the actual design of the product. One apparent problem for a majority of the companies, or 75%, was the necessity to decompose the product into subsystems in order to facilitate the transportation of the product. The problem referred to here is the need for costly assembly operations in the field. 60% of the companies agreed that better packaging could contribute significantly to cost reduction. 65% were aware of the customer's demands on the packaging. Note that a number of the companies defined their own personnel installing the product as "customers". In no less than 90% of the companies, the integration of packaging and product development was considered to be an interesting and promising concept.

Conclusions

In the findings of the survey, we discern a strong industrial support for the main issue, namely that the integration concept is industrially relevant, i.e. the concurrent development of packaging and product! A second important findings in the survey is that our previous, preliminary extension of packaging logistics into the IPD process can be given a more definite form. In the preliminary version, packaging logistics was simply considered the "fifth function" to be accounted for during the IPD process. The reason for not integrating packaging logistics into one or more of the four existing functions (market, design, production and business/finance) was the lack of information provided by the second question under topic 4 - see Table 2. On the basis of this information we have drawn the conclusion that packaging development should be integrated into all of the functions. In order to provide substantial support for facilitating this integration process, we have identified packaging design as the key element in the process. Consequently, a parallel research project has been launched, in which a computer based analysis tool to support the designer during the combined efforts of designing product and packaging is under development. The tool is based on newly derived constitutive models of corrugated board material and EPS, utilising a combination of powerful FE-codes such as ANSYS and LS-DYNA. Dr. Ake Burman and Lie. Eng. Martin Eriksson, both at our department, carry out the project. An example is given in Figure 1 below. We have also found a far greater interest in these matters than we anticipated at the beginning of the project. In some of the companies, our survey was considered to have started an internal process of discussing the benefits of paying greater attention to the development of packaging. It should be noted that this process might actually have started long before the companies participated in our survey. The number of considerations and measures already taken by the companies evidences the existence of such a process. One example is the widely adopted concept of integrating, at least formally, the development of the packaging into the overall product development project.

ICED 01 C586/609

383

Figure 1. FE-simulation of packaging and product-courtesy A. Burman and M. Eriksson

Acknowledgements

The authors would like to acknowledge the generous support given by the Swedish companies participating in the survey. References [1] [2] [3] [4] [5] [6] [7] [8] [9] Bjarnemo, R. et al, "Packaging Logistics in Product Development", Proc. ICCIM 2000. Singapore, pp 135-146 Bjarnemo, R., "Product Development in the Virtual Enterprise", Nord Design98, Royal Institute of Technology, Stockholm, 1998, pp 137-146 Bjarnemo, R., "Product Renewal by Using IPD", Proc. ICCIM'97. Singapore, pp 951960 Bjarnemo, R., "Evaluation and Decision techniques in the Engineering Design Process - in Practice", Proc. ICED 91, Zurich, pp 373 - 383 Christopher M., "Marketing Logistics", Butterworth-Heinemann. London, 1997 Hein, L. et al., "Integrated Product Development", Proc. Design Policy, Vol. 2, The Design Council, 1984, pp 86-90. Johnsson, M., "Packaging Logistics - a value added approach", Department of Engineering Logistics. Lund University, Lund, 1998 Olsson, F., "Systematisk Konstruktion", (in Swedish), Department of Machine Design, Lund Institute of Technology, Lund, 1976 Paine, F., "Fundamentals of Packaging", Brookside Press Ltd.. Leicester, 1981

[10] Porter, M.E., "Competitive Strategy", The Free Press, New York, 1980 IMechE 20()l

384

ICED 01 C586/609

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 2123, 2001

A FRAMEWORK FOR DISTRIBUTED CONCEPTUAL DESIGN

A Schucllcr and A H Basson

Keywords: Systematic product development, collaborative design tools, distributed design.

1 Introduction
This paper presents the findings of an investigation into the practicality and the requirements of a support system for distributed conceptual design. Distribution offers a number of advantages over co-located design, and the infrastructure for global design is growing rapidly. A variety of systems for the detailed design phase have already been successfully employed in industry, but conceptual design has received little attention up to now. Based on the "Design Assistant" by Schuster [1], a support system that guides a distributed design team systematically through the initial stages of the mechanical design process, as set out by Pahl & Beitz [2] and summarised by Ullman [3], is described. The focus of this paper is on a methodology for a distributed team of designers in comparison to classical methods for colocated design. In this context the integration of suitable tools for communication, information transfer, and design content input plays an important role.

2 A framework for distributed conceptual design

Product design and development has become a global process. Distributed product development offers a means of including the know-how of experts from all over the world and of making use of resources at different company sites, in different countries [4]. This results in reduced costs and lead-time, as well as in increased quality. The challenge is to connect designers and design teams worldwide and to make formal information exchanges among them more effective and user friendly. Support systems for distributed design must strive to provide the same functionality and convenience that the designers are used to in working with their co-located colleagues. Currently available support systems, e.g. the framework of Huang & Mak [5], implement methodical conceptual design in a distributed environment, but fail to provide proper tools for communication, information transfer and design-content input. A system of three segments, which complement one another and can interact closely, is necessary. The segment "Design Methodology" places a methodology that guides designers through the conceptual design phase and offers tools for concept generation and evaluation at their disposal. The segment "Communication and Information Transfer" co-ordinates the communication between the distributed designers and provides a platform for the exchange of design-related data, e.g. customer requirements, ideas, sketches, comments and decisions. Both segments make use of the third segment, i.e. a support service for various input devices. Figure 1 illustrates the three main segments of a distributed conceptual design environment.

ICED 01 C586/049

385

DESIGN METHODOLOGY Distr. Conceptual Design Methodology Methods and Tools - Lists of Requirements / QFD - Morphological Charts - Creativity Techniques

COMMUNICATION AND INFORMATION TRANSFER Team Management Phone, E-mail, Videoconferencing Shared Workspace, Bulletin Boards Online Catalogues

INPUT DEVICES FOR CONCEPTUAL DESIGN

Graphic Tablet with Pen, Scanner, WebCam, etc.

Figure 1. Main segments of a distributed conceptual design environment

The proposed framework comprises a number of software components referred to as "Assistants". These provide the functionality and the user interfaces for the segments mentioned above. The segments and the accompanying framework components will be described in more detail in the following chapters.

3 Methodology for distributed conceptual design

Classical design methodologies, like the methodologies described by Pahl & Beitz [2], Ullman [3] or in the VDI Guideline 2221 [6], provide a systematic and well established approach to the design process. These methodologies were analysed to determine their suitability for a distributed design scenario and recommendations for improvement were made.

3.1 Specification development

The design process starts with an idea or a need for a new product or a product redesign, as expressed by a customer. The customer can be an external client and/or a department within the company. The recording of the customer requirements usually does not involve the whole design team. This step has therefore to be carried out as accurately as possible, in order to reduce later enquiries to a minimum. In particular, distributed team members far from the customer's location may find it difficult to get in contact with the client. Pahl & Beitz [2] recommend using a requirements list containing the "Wishes" and "Demands" of the customer in a standardised form. The use of uniform lists and questionnaires make the distribution of design specifications easier, since the conversion between file formats, a common source of errors and omissions, is reduced. Checklists containing general and specific objectives and constraints support the process of creating and updating the requirements list. Ullman [3] bases the development of the engineering specification on the "Quality Function Deployment" (QFD) technique, although Suh [7] states that it is only useful for redesign. For a distributed design environment QFD is particularly valuable because of its high information content and the comprehensible graphic representation in the form of the QFD "House of

386

ICED 01 C586/049

Quality" matrix. This step ensures that the problem is understood by all team members, which is a vital aspect, especially for a distributed team. The "Specification Development Assistant" supports the user in recording the customer's requirements and establishing the engineering requirements. Every customer requirement has to be linked to at least one engineering requirement and vice versa. Every team member can make contributions to both lists. The team manager can organise all entries into categories and check the lists for completeness. A "House of Quality" can also be created. Since group discussions cannot always take place, each matrix entry can be annotated to inform the other team members of one's reasoning or to give additional information.

3.2 Functional analysis

The next step is the functional decomposition of the design problem into an overall function and multi-level sub-functions. For distributed design teams a hierarchical, numbered treestructure is more suitable than graphic-oriented diagrams, e.g. functional flow charts, since the tree-elements, their positions and their linkages with each other are easier to record, to store and to impart to the other team members than graphical components. After the decomposition, the lower-level elements of the hierarchy can be grouped into logical units, i.e. related functions or functions that might be satisfied with similar solutions. This procedure is also known as "Functional Packaging" [8]. The functional analysis is supported by the "Functional Analysis Assistant".

3.3 Concept generation

For each low-level element of the tree-structure, i.e. the sub-functions identified in the previous step, one or more suitable solutions must be found. Various techniques to support this process are included in the framework. The proposed solutions for the sub-functions are then combined to a number of concept proposals to satisfy sub-concepts, i.e. functional packages, or the overall function. The "Concept Generation Assistant" is used to describe each solution with a short phrase. The entry can be accompanied by more detailed textual descriptions and links to graphic files, e.g. sketches, diagrams or images from a catalogue. References to other sub-functions can also be made, e.g. when these can be satisfied by the same solution or when an off-the-shelf component is a practical answer. By using one solution for multiple sub-functions it is possible to reduce the component count of the developed product. Each designer can go through the concept proposals generated by the other team members to stimulate creative thinking and eventually lead to more and better solutions. In case too few or unsatisfactory solutions have been identified for a particular sub-function, the team manager can initiate a brainstorming or brainwriting session. Brainstorming and brainwriting are valuable methods, especially when used as computer-based tools in a design group [9]. Brainstorming sessions can be held in the form of group-chats or videoconferences, with the team manager or another person guiding the discussion, taking notes and distributing the collected information to all team members. The biggest problem here is the coordination of a suitable time for all participants. Brainwriting sessions are time-wise unrestricted, since they can run asynchronously. Brainwriting, also called "Method 635", makes use of forms that circulate in the group to collect ideas and at the same time stimulate the designer.

ICED 01 -C5 86/049

387

The number and quality of ideas produced during distributed and co-located brainstorming sessions depend on the knowledge and experience of the participants rather than on their location. The personal interaction of the designers, e.g. the exchange of models and gestures, and the cross-stimulation resulting from it, is an important aspect of a brainstorming session. Nevertheless with the right technical equipment the negative effects of being distributed on the intercommunication could be reduced to a minimum. Other problems, such as a designer's "fear of being foolish" or the use of so-called "Killer-Phrases" might even be neutralized due to the lack of personal contact. For the generation of concept proposals, the "Concept Generation Assistant" provides a list of the functions and sub-functions and their possible solutions. Each user can select one solution for every sub-function and combine them into a number of concept proposals. This approach is similar to the use of a "Morphological Matrix" [2], but does not automatically create a vast and incalculable number of concepts. Instead it allows for the development of numerous different concept proposals that already went through an initial selection process, namely the choice by the user. This increases the chances of obtaining a large number of high quality concepts. The number of concepts generated by each designer is dependent on the time available, the company policies and, of course, the quantity the design team feels comfortable with.

3.4 Concept evaluation

The concept generation is followed by a screening process to eliminate all proposals that do not meet the previously established requirements or that are regarded as not worth further consideration, based on the designer's "gut feel" [3]. Discarded concept proposals are not deleted from the pool, but marked as rejected. In this way they can still serve as a source of inspiration for the designers during the refinement of the other concepts. Different techniques can be used, from simple yes/no-voting to short group discussions, depending on the team manager or on the company's policies. The remaining concept proposals are evaluated in order to determine the most suitable ones for further development. The "Decision-Matrix-Method", or "Pugh's Method" [10], is used to score each alternative concept, relative to another. According to Ullman [3] this method is most effective if each team member performs it independently, to avoid any influencing, and the individual results are compared. The distributed team is therefore not at a disadvantage when using this method. The "Concept Evaluation Assistant" helps each designer to check for compliance with the initial customer requirements and the evaluation criteria. It supports the designers in weighting the criteria and assessing each concept proposal, and calculates the final score.

3.5 Design review and team management

In both co-located and distributed design teams the role of the team manager is very important. The team manager has to decide on an applicable strategy and to coordinate the separate steps of the design process. In many cases the team manager does not directly participate in the design process, but rather supervises the progress of the team. The proposed framework includes a "Team Management Assistant" which provides, among other tools, a questionnaire-based method for design team formation, as recommended by Wilde [13].

388

ICED01-C586/049

All the steps of the procedure presented above can be performed either synchronously or asynchronously with the other team members, depending on the scenario and available equipment. Each phase should be concluded with a design review, moderated by the team manager. These reviews are important elements of the methodologies described by Ullman [3] and Blanchard & Fabrycky [8]. hi a distributed environment the meetings and the exchange of notes provide a deep insight into the project (this is natural in co-located design groups). The users are also encouraged and aided in documenting all their steps in order to allow the fellow designers, or designers of follow-up projects, to understand the decisions made. A "Documentation Assistant" provides templates and guidelines for the proper compilation of the conceptual design specification and other reports. It also assists in integrating the various tables, notes and graphics generated during the conceptual design phase into the project documentation.

4 Communication and information transfer

A greatest disadvantage of distributed design is the restricted communication between the participating team members. Designers in a co-located environment can call for a meeting whenever necessary, but conferences in distributed design teams have to be planned more carefully. Considerations such as office hours in different time zones as well as the availability and suitability of communication tools have to be taken into account. With the continuous expansion and the increasing capacity of the World Wide Web, communication is no longer restricted to telephone, fax and postal mail. Traditional and modern communication means are complementary and should be used in an optimised way. The "Communication Assistant" is a support tool for all communication issues. It keeps track of team members logged into the system, displays the status of availability for synchronous communication, i.e. phone, chat or videoconferencing, together with the necessary contact details, and provides an interface for e-mail, chat and a message board. Information transfer during the conceptual design stage differs from the later phases in content and frequency. The exchanged information consists in many instances of sketches, ideas, mock-ups and other difficult to grasp objects. As the amount of information increases it becomes more and more inconvenient to distribute files in a design team by electronic mail. An alternative is to publish the information on a shared workspace system. The participating designers now do not have to send every bit of information to every team-member that they assume will be interested in the information. Instead, the designers upload their data only once to a shared workspace server, like the BSCW system developed by Bentley et al. [11], and download only the information they need. This also helps to maintain a certain level of consistency, i.e. all team members can work with the same version of a file, as earlier investigation by the authors have shown [12]. Designers need a global perspective of the project they are working on and therefore should have access to as much information as possible, for instance in form of online catalogues and Internet search engines.

5 Input devices for conceptual design

Distributed conceptual design makes special demands on the input devices used. While standard tools, such as a mouse and a keyboard, meet the requirements of subsequent stages

ICED 01 -C5 86/049

389

of the design process, e.g. CAD during the detailed design phase, they are often impractical in creating or annotating a sketch. The proposed framework takes this into account by integrating hardware and software from other disciplines, e.g. graphical design. A case study was carried out by the authors [12] to evaluate tools used for synchronous and asynchronous collaboration in distributed conceptual design. Of particular interest was the suitability for the exchange and discussion of difficult-to-grasp design information, such as ideas and hand-sketches. The tools included telephone, fax, e-mail, videoconferencing and a shared workspace environment, as well as various input devices, such as a scanner and a graphic tablet with pen. The case study confirms the advantages of pen-based sketch input over standard input devices, like the computer mouse, in terms of speed and quality. Personal experience of the first author also indicates the value of digital cameras and WebCams to capture and exchange design information in form of sketches, notes on white-boards, and three-dimensional mock-ups.

6 Conclusions
The investigation into the practicability and the requirements of a support system for distributed conceptual design shows that most elements of classical design methodologies are also applicable to distributed design. Especially the structured approach is an advantage in distributed design environments. But it is not enough to develop a number of tools for design methodology and provide access to this system from different locations. Ullman [3] states that "communication is one of the key features of concurrent engineering, and effective communication is essential among design team members." A methodical approach must be accompanied by a system to enhance the communication and information transfer between the participating designers and support their interaction. The framework segments "Design Methodology" and "Communication and Information Transfer" cannot be put to good use without the provision for advanced input devices, fast and accurate enough to capture a flash of inspiration before it disappears. The framework for distributed conceptual design is currently under development and will be used for validation case studies.

Acknowledgements
The financial support of the National Research Foundation (NRF grant GUN 2034084) and the Stellenbosch University Research Committee is gratefully acknowledged. References [1] Schuster, H.R., "A Computer Aid for Specification Development, Conceptual Design and Manufacturing Cost Estimation in Mechanical Design", Ph.D. Thesis, University of Stellenbosch, South Africa, 1997. Pahl, G. and Beitz, W., "Konstruktionslehre - Methoden und Anwendung". Springer, Berlin, 1997. Ullman, D.G., "The Mechanical Design Process". McGraw-Hill, Boston, 1997.

[2] [3]

390

ICED 01 - C586/049

[4]

Gierhardt, H., Gaul, H.-D., and Ott, T., "Distribution in Product Design and Development Processes", Proceedings of the 1999 ASME Design Engineering Technical Conferences. Las Vegas, 1999, DETC/DTM-8777. Huang, G.Q. and Mak, K.L., "Web-based Collaborative Conceptual Design", Journal of Engineering Design. Vol. 10(2), 1999, p. 183-194. VDI, "VDI Guideline 2221 - Systematic Approach to the Development and Design of Technical Systems and Products", VDI-Verlag, Diisseldorf, 1986. Sun, N.P., "The Principles of Design". Oxford University Press, New York, 1990. Blanchard, B.S. and Fabrycky, W.F., "Systems Engineering and Analysis". Prentice Hall, Upper Saddle River, 1998. Holt, K., "Brainstorming - From Classics to Electronics", Journal of Engineering Design. Vol. 7 (1), 1996, p. 77-82.

[5] [6] [7] [8] [9]

[10] Pugh, S., "Total Design - Integrated Methods for Successful Engineering". AddisonWesley, Wokingham, 1991. [11] Bentley, R., Appelt, W., Busbach, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J. and Woetzel, G., "Basic Support for Cooperative Work on the World Wide Web", International Journal of Human Computer Studies: Special issue on Novel Applications of the WWW. Academic Press, Cambridge, 1997. [12] Schueller, A. and Basson, A.H., "Case Study on Synchronous and Asynchronous Communication in Distributed Conceptual Design", to be published in Proceedings of the 2001 International CIRP Design Seminar. KTH Stockholm, Sweden, 2001. [13] Wilde, D.J., "Using Student Preferences to guide Design Team Composition", Proceedings of the 1997 ASME Design Engineering Technical Conferences. Sacramento, 1997, DETC97/DTM-3890. Prof. Anton H. Basson Department of Mechanical Engineering, Stellenbosch University, Private Bag X1, Matieland 7602, South Africa, Tel: +27 (0) 21 808-4250, Fax: +27 (0) 21 808-4958, E-mail: ahb@ing.sun.ac.za, URL: http://www.mecheng.sun.ac.za/

IMcchE2001

ICED 01 -C5 86/049

391

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A SYSTEM FOR CO-ORDINATING CONCURRENT ENGINEERING

R I Whitfield, G Coates, A H B Duffy, and W Hills

Keywords: Tactical design co-ordination, distributed design, concurrent engineering.

Introduction

Design of large made-to-order products invariably involves design activities which are increasingly being distributed globally in order to reduce costs, gain competitive advantage and utilise external expertise and resources. Designers specialise within their domain producing solutions to design problems using the tools and techniques with which they are familiar. They possess a relatively local perception of where their expertise and actions are consumed within the design process. This is further compounded when design activities are geographically distributed, resulting with the increased disassociation between an individual designer's activities and the overall design process. The tools and techniques used by designers rarely facilitate concurrency, producing solutions within a particular discipline without using or sharing information from other disciplines, and seldom considering stages within the product's life-cycle other than conceptual, embodiment or detail [1, 2]. Conventional management and maintenance of consistency throughout the product model can subsequently become difficult to achieve since there are many factors that need to be simultaneously considered whilst making a change to the product model. Concurrent Engineering (CE) is often regarded as a means of significantly reducing design time to enhance competitive advantage by maximising the amount of parallel design activities. Winner et al. [3] described concurrent engineering as: "a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support. This approach is intended to cause the developers, from the outset, to consider all elements of the product life-cycle from conception through disposal, including quality, cost, schedule, and user requirements." This definition is representative of many of those encountered in that the main emphasis is placed on its systematic approach to the design process as it reduces the design time and hence total design cost, which is one of the main considerations in the entire design process. CE however cannot be fully realised without co-ordination [4] and given a co-ordinated approach without de-coupling dependencies, concurrency will only be achieved where the design process permits. The DMS is intended to tackle some of the issues arising from the above statements by providing a formalism that would enable the design process to be co-ordinated in a tactical manner. This involves determining the actions required to be undertaken to perform a specific task for the right reasons, to meet the right requirements and to give the right results [5].

1CED01-C586/114

393

Design co-ordination is a relatively new concept within the engineering design community and is aimed at improving the performance of the engineering design process. One of the most prominent frameworks associated within design co-ordination is the Design Co-ordination Framework (DCF) [5]. The DCF presents a number of frames, each of which is aimed at representing different aspects of design co-ordination. The DCF also describes the management of the links between the frames. The research presented in this paper identified that tactical co-ordination may be represented by: the goal/result model; the discipline/technology model, and, the task model frames within the DCF. These models are described within section 3. The focus of this tactical design co-ordination system is the management of design tasks, information, goals and rationale within the product development process such that the process may be performed in a timely and appropriate manner. The Design Management System (DMS) was used to manage and co-ordinate these tasks, and evaluate the constraints, maximising concurrent design activity, whilst maintaining inter-task dependencies. Close contacts with industry were maintained during the research programme which focused on the development of the DMS system towards tackling design issues that were considered pertinent to the companies such as reducing design time, ensuring informational consistency, and facilitating, not automating, the decision making process. An application of the DMS within an industrial case study is demonstrated within section 4. The case study represents a number of inter-dependent tasks that need to be performed and constraints that need to be satisfied for the design of a stage of blades within a steam turbine. Conclusions and recommendations are made within section 5.

DMS architecture

The DMS was constructed to co-ordinate the design activity of an agent-oriented design process with respect to managing design tasks, information, goals and rationale, and facilitating the decision making process. A basic representation of a software-based design agent was produced to: manage the functionality of existing design tools; enable communication with the DMS and other design agents, and, demonstrate how the distributed design problem may be managed and co-ordinated. The focus of this work was, however, not towards the development of autonomous agents. Malone et al. [6] proposed two design principles for the design of agent-based systems which were used during the development of both the DMS and the associated design agents: "Don't build computational agents that try to solve complex problems all by themselves. Instead, build systems where the boundary between what the agents do and what the humans do is a flexible one." "Don't build agents that try to figure out for themselves things that humans could easily tell them. Instead, try to build systems that make it as easy as possible for humans to see and modify the same information and reasoning processes that the agents are using."

2.1 The discipline/technology model

The discipline/technology model represents the disciplines which are present within the product as a whole and also within its subsystems [5]. The model also indicates which

394

ICED 01 - C586/114

technologies are required for the design development, as well as displaying how the disciplines and technologies are distributed over the artefact. Within the context of an agent-oriented distributed design architecture, the discipline/technology model represents the structure of the agents and the technologies that they utilise. That is, the agents and associated design tools often reflect the discipline knowledge and technologies within the domain. The model also contains information pertaining to the tasks that the design agents are capable of undertaking. Through the production of a design process displaying the inter-dependencies between the tasks, it is possible to display the relationships between the design agents as well as the technologies. The design agents register their information with the DMS to enable communication, as well as providing information regarding the tasks that the agents are capable of undertaking. Currently this process is confined to software agents, where the tasks that may be performed are defined by the functions that the associated design software may achieve. However, developments are underway to define and model tasks and their associated disciplines and technologies within the DMS to enable the management and co-ordination of human agents. The DMS may manage human agent task enactment by sending an email to an engineer containing a description of the task that needs to be performed as well as the information required to perform the task and the information that the task will produce. When the task is completed the engineer would submit the produced information back to the DMS.

2.2 The design process builder and task model

A graphical user interface was developed which would enable the designer to define the design process at any level of abstraction using information obtained from the discipline/ technology model. A number of different events were defined such as: perform task; branching operations (to facilitate concurrency); process pause; and, decision events, which could be used to define the process as well as co-ordinate the activities of the design agents. The Design Structure Matrix has been adopted as a mechanism for managing the tasks and inter-task relationships within the design process [7, 8]. This concept has been extended such that iteration and decision based branching may be represented within the design process with each process having its own matrix representing the tasks that need to be undertaken to achieve a particular goal. Providing individual representations in this way has enabled the overall goals of a process to be identified based upon the tasks contained within it, as well as enabling the DMS to manage more than one design process simultaneously. Allowing simultaneous management of processes further increases the functionality of the DMS since different aspects of the same design problem may be modelled and evaluated concurrently, for example the determination of the performance of a design artefact within different life phases. The DMS not only manages the dependencies within each individual process model, but also manages the dependencies between process models that are required to co-ordinate concurrent design activity. The new Design Structure Matrices also include decision based dependencies to provide an exit condition from an iterative loop. A number of partitioning and concurrency based criteria were included to evaluate the performance of the design process.

ICED 01 -C586/114

395

2.3 Process information model

The DMS contains a formalism for the management of design information based upon an object-oriented approach. Currently, four different types of information have been developed based upon this formalism: Parameter, Option, File and File Group. The formalism requires all design information used within the DMS to inherit from a base class which provides mechanisms for comparing different pieces of information, serialising information such that it may be communicated across a network or stored persistently on a disk, and enabling information to be displayed graphically within the DMS. Extending the base class enables new types of information to be developed to suit the intended application. For example, if the design problem is to develop an internal combustion engine, the base class could be extended to produce a new information type which provides all of the information required to represent a piston. In addition, this information may be displayed three dimensionally within the DMS, enabling the designer to visualise the information, as well as modify it. Knowledge may also be included within the new information type to constrain how the information may be changed. Each design process has an associated information model, containing information that has been either provided or produced, which is stored centrally within the DMS. When a new piece of information has been generated as a result of performing a task it is placed into the produced area of the information repository, replacing existing or outdated information as necessary. The DMS allows concurrent access to the information model by multiple agents.

2.4 The goal/result model

The DMS does not attempt to take the decision making process away from the designer, instead, it facilitates the decision making by providing the designer with information which would enable decisions to be made more appropriately. Using parametric information made available from within the process information model, it is possible to construct and evaluate mathematical expressions which represent certain requirements or constraint-based goals of the design process, such as, for example, checking that the calculated efficiency is greater than a minimum efficiency. The design goals will be evaluated automatically when the design process has been enacted and the design solution for a particular design concept produced. If a goal has not been satisfied, then the user is notified of the problem, such that decisions may be made with respect to the design concept in order to satisfy the goal. The DMS currently lacks optimisation-based goals, i.e. there are no mechanisms for expressing the goal, "maximise efficiency". Current developments within the DMS include a suite of optimisation software for both the optimisation of the design process and the design product. The optimisation software includes: a robust design tool which may be used to either increase the robustness of a product, or give a good "ballpark" design which is near the optimum, a multi-criteria genetic algorithm which either may be applied to optimising the design process or product, and a multi-criteria simulated annealing algorithm which may also be applied to optimising the design process. Both the multi-criteria genetic algorithm and simulated annealing algorithm have been implemented within the design structure matrix and have successfully demonstrated that the design process may be improved with respect to both concurrency and partitioning.

396

ICED 01 -C586/114

Implementation and case study

The industrial case study used to validate the DMS software consisted of the co-ordination of a number of disparate design agents that were used to evaluate particular aspects of the performance of a stage within a turbo-generator. The associated tasks are represented within the design process seen in Figure 1, which describes the activity that needs to be performed to determine aerodynamic, stress, and vibration characteristics of the turbine, as well as providing information regarding the dependencies between the tasks. The design process area also contains a list of the information that is provided as input to the design process which describes the design concept to be evaluated, a list of output information which describes the corresponding design solution, as well as a list of design goals.

Figure 1. DMS Showing Bladepath Design Process.

A Design Structure Matrix is also used to represent the tasks and dependencies of the design process and provide evaluations of design process based performance criteria. A number of optimisation algorithms may be used to re-sequence the tasks within the design structure matrix with the objectives of improving the process performance with respect to the partitioning and concurrency criteria. Different weightings may be applied to the dependencies to represent strong and weak relationships. In this particular example however, all of the dependencies are defined as being strong since it is not possible to start a tool prior to the completion of a preceding tool.

3.1 Previous implementation

A typical evaluation of a design concept started with the production of a preliminary concept which would provide the necessary information for the process. The concept would then be

1CED01-C586/114

397

evaluated through the enactment of the design process shown within Figure 1 requiring the manual execution of each of the tools in the order depicted by the design structure matrix. The flow of execution through the process is from top to bottom, although it may be modelled in any direction within the DMS. It can be seen from Figure 1 that certain tasks may be undertaken concurrently, however the process was generally managed by a single designer, and as such proved to be difficult to manage more than one tool simultaneously. Upon completion of each task, the information generated required moving to the correct location for the following tasks to maintain informational dependencies. This process was undertaken manually, and found to take approximately 11 minutes. The design solution, spread across a large number of files and a number of different disciplines, would then be examined to extract certain information which would be used within additional manual calculations to determine whether the design concept satisfied the design constraints. Rules would then be applied based upon the designer's experience to vary the parameters, changing the design concept to satisfy these design criteria. A number of iterations are generally required to satisfy the constraints.

3.2 DMS implementation

Design work commences with the design agents registering with the DMS. Agent details are registered within the discipline/technology model of the DMS. This initial communication informs the DMS that the specified agent is capable of undertaking some design activity. The DMS then makes a request that the design agent provides information regarding the nature of the design activity that it can undertake. This information will take the form of a list of tasks, details of files or parameters that the task may require, constraints that need to be satisfied prior to task enactment, and files and criterion that result from the enactment of the task. These task details may be either low-level or high-level terms and may describe an individual atomic task or a group of tasks depending upon the level of abstraction of the implementation of the design agent. The design process may then be designed by decomposing it into the relevant tasks available. Informational dependencies must be maintained during the design of the process. The DMS will notify the user if a task has been included within the process that requires information that has not yet been produced. The task would then disable itself until this informational dependency has been satisfied. The consequence of ensuring informational dependency is that tasks may not be decoupled, and concurrency may only occur as defined by the process. The design concept to be evaluated may be selected and modified by viewing the input files within the design process. Once a suitable design concept has been defined, the process is started with the DMS communicating to the design agents in turn providing them with the necessary information to undertake the current task. Once the design agent has processed the information and executed the associated tool, the design agent will notify the DMS of the information that has been produced from the tool. The DMS then determines from the design structure matrix which tasks are now capable of being enacted and communicates with those agents in a similar manner. Once the process has been completed, the DMS will evaluate any goals that have been provided and notify the user of the outcome. Experiments using the DMS to co-ordinate the activity of those agents operating on the same workstation have produced the same results as that produced using the applications manually, but within 75% of the time due to the removal of the overhead associated with manual enactment. The experiment was repeated with the agents distributed across a number of workstations, resulting with a 46% reduction in the time taken to evaluate the concept whilst

398

ICED01-C586/114

guaranteeing the consistency of the information within the process. This greater reduction was due to concurrent design activity across a number of computational resources. The DMS also ensures that if an application failed to produce a solution, a warning would be issued to the user with a description of the nature of the failure, and the remaining tasks would be suspended.

Conclusions

A new approach to tactically co-ordinating distributed, agent-based design activities has been presented. The approach enables concurrent engineering to be realised through the management of dependencies. From a CE perspective the focus is more towards enabling concurrency, rather than maximising concurrency by de-coupling activities, thus allowing the design process to progress naturally. The approach was evaluated using an industrial case study that had a well-established design process. The activities within the process as well as the management of the information resulting from the activities were previously performed manually using a number of different computer-based design tools. Upon completion of the process, the results from the design activities would be used within calculations to check that the design concept satisfied the constraints. Alterations would subsequently be made to the parameters that were thought to be preventing the concept from satisfying the constraints, and the process would be repeated until the design concept fulfils these requirements. The time taken to evaluate a design concept through the manual enactment of the process was approximately 11 minutes. Each design tool was subsequently managed by a design agent within the DMS. The design process was then constructed using information obtained from these agents. Through the management of the dependencies within the process, two threads of concurrent activities were made apparent. The evaluation of a design concept was managed using the DMS using the same platform as the manual test with the agents distributed across three Ultrasparc workstations and produced a reduction in process time of approximately 46%. This time obviously depends upon the amount of the resources available to the agents, however, the same principle applies for the manual case, and in both the manual and DMS experiments, the resources had 100% of the cpu available to the user. This time may be considerably reduced further with the inclusion of a generic "operational co-ordination" module [4] through the dynamic co-ordination of resources. The DMS was also responsible for managing the constraints such that the stresses within the blades and the vibration characteristics met certain pre-determined requirements. This was achieved by altering various geometrical characteristics of the blades using specific guidelines.

5 Acknowledgements
The authors gratefully acknowledge the support given by the Engineering and Physical Science Research Council who provided the grant RES/4741/0929 that enabled this work to be undertaken. Additionally, the authors acknowledge Siemens Power Generation Systems, for their advice, expertise and for providing the case study.

1CED01-C586/114

399

References [1] Coates G, Whitfield RI, Duffy AHB & Hills W, "A Review of Co-ordination Approaches and Systems - Part II: An Operational Perspective", Research in Engineering Design, Vol. 12, No. 2, 2000, pp. 73-89. Whitfield, RI, Coates G, Duffy AHB & Hills W, "A Review of Coordination Approaches and Systems - Part I: Strategic Perspective", Research in Engineering Design, Vol. 12 No. 1, 2000, pp. 48-60. Winner RI, Fennel JP, Bertrand HE & Slusarczuk MMG, "The Role of Concurrent Engineering in Weapons System Acquisition", IDA Report R-338, Institute of Defence Analyses, Alexandria VA. 1988. Coates G, Whitfield RI, Duffy AHB & Hills W, "Enabling Concurrent Engineering Through Design Co-ordination", 6th ISPE International Conference on Concurrent Engineering, Bath, United Kingdom, September 1-3 1999. Andreasen MM, Duffy AHB, MacCallum KJ, Bowen J & Storm T, "The Design Coordination Framework: key elements for effective product development", International engineering design debate: The design productivity debate, Meeting; 1st Sept. 1996, Glasgow, pp. 151-174. Malone TW, Lai K & Grant KR, "Agent for Information Sharing and Co-ordination: A History and Some Reflections", Software Agents, AAAI Press, 1997, pp. 109-143. Eppinger SD, Whitney DE, Smith RP & Gebala DA, "A Model-Based Method for Organizing Tasks in Product Development", Research in Engineering Design, 6, pp. l13, 1994. Kusiak A & Wang J, "Decomposition of the Design Process", ASME Transactions: Journal of Mechanical Design, Vol. 115, No. 4, 1993, pp. 687-695.

[2]

[3]

[4]

[5]

[6] [7]

[8]

Dr. R.I. Whitfield CAD Centre, Department of Manufacturing and Engineering Management, University of Strathclyde, 75 Montrose Street, Glasgow, Gl 1XJ, Scotland. Tel.: +44 (0)141 548 3020 Fax: +44 (0)141 552 7896 E-mail: ianw@cad.strath.ac.uk Formerly: Newcastle Engineering Design Centre, Armstrong Building, University of Newcastle upon Tyne, Tyne and Wear, NE1 7RU, England. Tel: +44 (0)191 222 8556 Fax: +44 (0)191 261 6059 E-mail: r.i.whitfield@ncl.ac.uk IMechE 2001

400

ICED01-C586/114

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DISTRIBUTED PRODUCT DEVELOPMENT - A CASE STUDY IN INTERORGANIZATIONAL SME BUSINESS NETWORKS

J Pilemalm, S Gullander, P Norling, and A Ohrvall-Ronnback Keywords: Industrial case study, industrial co-operation, SMEs

Introduction

The globalisation increases the competition and causes many companies to live under a heightened strain. Companies are faced with completely new demands and challenges. Some companies are, however, creating new opportunities by increased co-operation across boundaries. Small and Medium sized Enterprises (SMEs) working together in interorganisational business networks enable entirely new business opportunities by means of aggregation of their resources and knowledge. Such networks make it possible for SMEs to develop and to offer more complete systems and products that could not without great difficulties, or at all, be offered by individual companies alone. This implies a need for research and knowledge development in the area, especially regarding how to perform distributed development of new products.

Objectives

The purpose of this paper is to present the results of a study investigating how companies in business networks communicate and collaborate between themselves and with customers, throughout the complete product development process. More specifically, the objective is to investigate factors that facilitate successful collaboration in networks, and if distributed product development can be applied in the Integrated Product Development (IPD) methodology, even when the team is dispersed. IPD is a concept for increasing efficiency and learning in industrial Product Development (PD) [1].

Theoretical framework

In order to respond to new challenges companies have to be dynamic and fractal. A fractal company is an independently acting corporate entity whose goals can be precisely described. It has an integrating approach where integration not necessarily needs to remain in the factory. In this way, a network of companies is created [2]. Cooperation across boundaries in interorganisational business networks enables SMEs to develop and to offer more complete systems and products in virtual organisations. There are several possible ways for creation of such organisations. One is when a leader enterprise builds a virtual organisation by involving partners to a specific business venture. A second is when one or several companies seek to join forces with similar partners to achieve a whole greater than the sum of its parts. A third is when a company creates a unifying factor and engages other parties [3].

ICED 01 - C586/145

401

According to one study, which focuses on coordination and control of interdependent actors in networked biomedical projects, it is indicated that there are certain factors inherent in networks contributing to the success in PD. Examples of such factors include ambiguities about authority relations, geographical dispersion, sensitivities about intellectual property, and problems with knowledge capture and information flow. Further, the importance of different issues varies between networks but also from phase to phase in the networked projects [4]. Previous research regarding SMEs has demonstrated that existing resources, the product type and the project scope influence the design process. Accordingly, three models based on the type of design activities performed, are proposed: Original design that includes all development steps, and the intended product is new to the company and has no prior design history. Evolutionary design that is intended to development of a new product that is basically based on a previous design. Incremental design used for minor changes to an existing design [5J. Most smaller companies do not see any problems in distributed activities [6], This indicates that SMEs could perform PD jointly in inter-organisational business networks. IPD is a concept for achieving efficient PD where integration refers to multifunctional integration between organisational functions, hierarchical levels, activities, divisions and across companies. The performance of IPD is characterised by parallel activities, crossfunctional collaboration, structured processes, and front-loaded development [1], [7], To perform IPD, using network structures is supposed to be a suitable organisational approach to make dynamic and flexible procedures in PD possible. Several advantages have been noted, such as distributed and flat structures, know-how building and knowledge transfer, access to complementary abilities as well as quality, cost and time advantages [8].

Research method

The research project "Distributed Product Development" (DPD) is one of several sub-projects in a project named "New Industrial Cooperation". The overarching project aims at industrial guidance to SMEs in cooperation in PD, but also at long-lasting collaboration between Swedish manufacturing industry, a research institute and several universities. The research question to be answered in DPD is: How should distributed product development in business networks be performed to enable efficient development from idea to final product? This will be answered through identification of important factors that, when exploited in the distributed PD, enhance the probability for obtaining the desired outcome compared to when an ad-hoc distributed PD is practiced. The question will also be answered through analysing to what degree and how IPD has been performed in the cases. In this paper an inter-organisational SME business network (IOBN) is defined as a virtual company consisting of SMEs and connected to a regional or local network. Two types of lOBNs will be discussed in this paper: IOBN with an own product (IOBN-P), and IOBN developing a subsystem as a consultant to an external customer (IOBN-S). In order to answer the research question, three lOBNs were investigated. Approximately 25 companies and organisations have been involved in the study. First several regional networks were contacted with the aim to find and select three regional networks containing at least one IOBN. The key persons at the regional networks were interviewed to identify and elucidate the main actors in three lOBNs (Case A, B and C), one in each regional network. Then the persons involved in the PD at the lOBNs were interviewed. Finally the customers were interviewed. The data was collected through semi-structured interviews, which are

402

ICED01-C586/145

characterised by open questions. The interviews were recorded on tape and transcribed. The analysis was carried out through a process were the material was structured through allocation of codes. The researchers represent different subject fields: Industrial -engineering, -organisation, -marketing, and -economics, which imply a multidisciplinary approach.

Results

The analysis indicated that some aspects were particularly important for the PD and the success of the lOBNs. Those aspects are presented in three sections below. First the two types of lOBNs are described. Thereafter factors judged as important for successful collaboration in lOBNs, and to what degree and how IPD has been performed in the lOBNs are presented.

5.1 Two types of inter-organisational SME business networks

Two types of lOBNs were studied. Figure 1 supports the description of the IOBN-P case and Figure 2 the two IOBN-S cases. Both figures visualise the cases over time and organisationally. In the left section of the figures the involvement of the customers, the collaborators (e.g. C1A in Case A), and the supporting organisations (e.g. S1C in Case C) are visualised over time. The organisations are marked as dark grey horizontal bars. Dotted lines indicate surrounding organisations that might have played some role for the project. The time when the main contract came into enforcement is also indicated. In the right section of the figures, the organisation of the lOBNs and the surrounding organisations are shown. IOBN-P are visualised with a solid rectangle and IOBN-S with a dotted rectangle. Each organisation is visualised with a circle. The adjacent regional network is visualised with a large dotted circle with minor circles symbolising the members. The regional networks surrounding the lOBNs The three regional networks were started during the 1990s. The regional network in which Case A was found, acts in mechanical industry and has approximately twenty members. Case B was found in a regional network that is active in the electronics industry and has only three members. The regional network in which Case C was found, acts in the polymer industry and has approximately twenty members. The main goal of the three regional networks is to support the members, especially by creating new business opportunities. There exist different opinions among the interviewees whether some of the specific lOBNs studied are results of the regional networks or not. Case A - A business network with an own product The idea to Product A emerged in relation to an outrage with several persons killed by a rifle. The inventor realised a need for a gunlock for rifles and started to outline a solution. The inventor who was without experience from the industry contacted some friends and together (CIA) they got into touch with local authorities (SIA and S2A) to ask for support with the first phases of this original development. The customer, which is a government authority, had realised the same problem as the inventor and issued a purchasing request. To continue with the next step it was realised by CIA that more actors were needed. Company C2A was contacted first, thereafter C3A to C5A. The regional network (S3A) might have played a part in finding the right companies. An external independent project leader (S4A) was engaged to manage the project. When finally the order for manufacturing was received (by C3A) from

ICED01-C586/145

403

the customer (Customer A), the IOBN-P established a common enterprise (C6A) to fulfil the order, but also to perform future projects and business opportunities.

Figure 1. Organisations involved in business network A. Case B - A business network developing a subsystem on request from a customer The three members in a regional network (SIB) had manufactured parts of the previous version of the current subsystem, which is a regulation system (Subsystem B) to specific ventilation equipment. When the customer (Customer B) was planning for a new generation of the product, a dialogue was held with C1B. The dialogue ended up with a contract for an incremental design between C2B and the customer. The reason for choosing C2B was their experience of project leadership and of assembling similar products. One person at C2B performed most of the development alone. However, to some extent he had support from C1B, C3B, the customer, some suppliers and other personnel at C2B. The result from the development was judged as successful. Case C- A business network developing a subsystem on request from a customer The idea for the complete product, which is a medical device, originated from a researcher (SIC) who also developed the first prototype. The idea was bought by a company (Customer C), which held the formal leadership of the development of the complete product. Customer C delegated the development of the mechanics (Subsystem C) to a firm of consultants (C1C) but developed the electronics itself. The PD can be judged as a compromise between original and evolutionary design. C1C is an experienced firm of consultants with a network of suppliers, both internal and external to the regional network (S2C). One person at C1C performed the bulk of the development work unaccompanied. However, to some extent he had support from C2C, CSC, the customer, some suppliers, and staff at C1C. The regional network (S2C) might have played a part for finding the right partners. The result from the IOBN-S was judged as successful and an almost complete supplier network came with the subsystem.

404

ICED 01 -C586/145

Figure 2. Organisations involved in business network B and C (B within brackets).

5.2 Important factors for successful collaboration in lOBNs

In this section six factors observed from the three cases judged as vital for successful collaboration in lOBNs are presented. The factors are intensive dialogue, geographically proximity, clear goals and responsibilities, complementary resources, straight business relations and early determination of reward and risk system. In all the three cases there was an intensive dialogue. This was most prevalent in the IOBN-P were all the participants were involved in regular discussions. The physical meetings were frequent and according to the interviewees the participants worked as a real team. The physical meetings within the lOBN-Ss were fewer, but there was an almost daily communication through telephone and e-mail. Consequently there were intensive dialogues, mainly between two persons at each time. In the IOBN-P problems and possible solutions were discussed together which led to better solutions than if the work should have been performed individually. The prevalent intensive dialogues in the IOBN-P indicated increased unanimity, openness and confidence, which was not equally evident in the lOBN-Ss. The requirement specifications were made in terms of functions rather than in technical details and this lead to an intensive dialogue between the customers and the lOBNs. The communication was mainly held between the contacts at the customer and the contractor. The dialogue was especially intensive at the lOBN-Ss. It was mentioned that the contact people should preferably possess equivalent technical competence and be on the same level, and also that the customer had to get the impression that the contractor would manage to fulfil the contract. The need for intensive dialogue made the geographical proximity obvious, especially in Case C in which the involved organisations were dispersed across large distances. According to the interviewees the geographical distance affected the frequency of physical meetings negatively. This was not estimated as critical, but the cooperation could have been even better with less distance.

ICED 01 - C586/145

405

Geographical dispersed teams with less physical meetings imply increased importance of clear goals and responsibilities. However, the distribution of the work differed between the 1OBN-P and the lOBN-Ss. In the latter the responsibilities were fairly clear, which was facilitated through clear interfaces in the products and the subsystems. In the IOBN-P both the team and the product were integrated to a high degree, which made clear responsibilities somewhat less important. Nevertheless, the activities surrounding the PD, e.g. purchasing and marketing were clearly distributed in all the lOBNs. The need for complementary resources was important for the lOBNs. In all the three cases the resources were complementary even though exceptions existed. In the IOBN-P the potential order was so big that the manufacturing resources had to be partially overlapping. Further, in Case C the designing company was replaced due to close down. The lOBNs were based on straight business relations. This was obvious between the lOBNs and the customer as well as between the lOBNs and their subcontractors. None of the customers considered the network organisation form at the lOBNs as important. From their point of view they made a business agreement with one single company. The main importance in the business agreement was mentioned as threefold: the function of the product or the subsystem, the price, and the time for delivery. Previous contact and references, and personal chemistry were also mentioned, but only at the IOBN-S. Finally, ISO 9000 certification was mentioned as important. The contractors mentioned previous contacts as important regarding their choice of partners and subcontractors. There was also some degree of favouritism; the contractors preferred partners and subcontractors from the local region. The contractors' cooperation differed much between partners and subcontractors. The latter's knowledge was mainly used in the late PD phases, and the adjustment of detail to their manufacturing processes was lesser than to the partners' manufacturing processes. To the majority of the companies, the business deals were relatively great. Therefore, early determination of reward and risk system was judged as important. The IOBN-P had a potential for a very large order and even larger in the future. The partners invested much time and money in the PD, but did also receive financial support from external organisations. The partners shared the complete risk of the project and also agreed on sharing possible profits. This was early formalised. The IOBN-S in Case B had a potential for a fairly large order, but the PD was paid trough payment for prototypes. In case C the contractor had no potential for a manufacturing order, but the other partners and the subcontractors had. The customer paid per hour for the development and took the main risk of the project. This was formalised before the development began. Thus, the main risk as well as the possible profits was shared by the partners in the IOBN-P and by the customers in the lOBN-Ss. However, the manufacturing partners and subcontractors risked being excluded from future manufacturing orders.

5.3 Integrated product development in network enterprises

In this section the cases will be analysed trough an IPD perspective according to the theoretical framework. Even though the participants in the IOBN-P knew each other the least in the beginning of the project, the PD in this network was more integrated than in the other two lOBNs. The involved persons worked as a team and thereby the companies become integrated in the actual project. This was particularly obvious in the work just before formal deadlines to the customer and when problems had occurred. The team was very committed to its task and the focus on bringing home the order brought the team very close together. Most of the work was

406

ICED 01 -C586/145

performed at one of the workshops where project information was shared among the participants. Possibly the integration between organisational functions could have been better, the focus was very much set on the manufacturing process. In the lOBN-Ss the integration between individual, functions and organisations were poor. The integration was most apparent between the contacts of the customer and the contractor and within parts of the companies. The small organisations in the lOBNs lead to that the involved person within each company worked close to each other and the integration between hierarchical levels was not a big issue. The issue of knowledge -capture, -transfer and -property has not been mentioned as a problem in the lOBNs. At the frequent physical meetings in the IOBN-P there was great openness and the results were documented. After the order was settled the partners established a common enterprise and the knowledge was transferred to that. In the lOBN-Ss the information and knowledge handling were somewhat restricted to what each partner and subcontractor needed. In all the cases there was a frequent communication through telephone and after some time also e-mail. The IT maturity increased gradually in the projects. The PD in the cases was to some extent performed in parallel. However, only the PD in Case C was following a structured process. The contractor in that IOBN had a settled process and this was followed throughout the project. In Case A and B PD was a new experience for the companies. Customer B had an internal PD-process, but the contact at that company appreciated the less bureaucratic PD performed in the IOBN, even though the lack of experience was a risk. In the IOBN-P the goal was to produce ten prototypes that fulfilled the requirement specification. This was focused throughout the complete PD process after the customer issued a purchasing order for manufacturing. Other aspects like e.g. the price-fixing were largely secondary. In the lOBN-Ss the PD were performed more gradually with different prototypes as goal. In all the three cases the project leader and to some degree the team settled a list of activities with a time schedule. According to the interviews the development time, the cost and the quality have not been mentioned as problems in the lOBN-Ss. However, in the IOBN-P, technical problems delayed the project several times. According to the interviewees it is doubtful if the PD in the IOBN-P would have succeeded if the key persons were experienced in PD. The project would probably be judged as a dead end due to the technical problems and the success it resulted in was judged as a consequence of a very great interest. On the other hand, some of the interviewees requested a more structured PD.

Conclusion

The IOBN-P studied is certainly a product of an entrepreneur choosing complementary partners for a specific business venture. In one of the IOBN-S, the contractor had previous contacts with the customer, but chose complementary partners for this specific business venture in the regional network. There exist different opinions regarding whether those specific lOBNs are results of the regional network or not. To know for certain, probably another research method following the emergence of the lOBNs would be needed. The other IOBN-S studied act as a united front toward the market and it is clear that such an approach might cause new business opportunities, in this specific case in a new area of business. Six factors judged as vital for successful collaboration in lOBNs have been observed in the three cases. They are somewhat supplementary to the theoretical framework. To decide on the importance of those factors more research has to be performed. However, the results indicate

ICED 01 - C586/145

407

that the importance is varying depending on IOBN. The main risk as well as the possible profits is shared by the partners in the IOBN-P and by the customers in the lOBN-Ss. Further, the complexity in an IOBN-P with original design is greater than e.g. in an IOBN-S with incremental design. Thereby the factors observed ought to be more important. The PD in the IOBN-P was more integrated than in the lOBN-Ss. There are several possible reasons for this. The PD concerned an original design, the team was very committed to its task and the team had a possibility to bringing home a large order. In addition the partners own the future product jointly. The fact that the tendency to integrate the individuals in a team increased just before formal deadlines and when problems had occurred indicates that this is a natural way of working at critical situations. The integration in the lOBN-Ss was narrow and most apparent between the contacts of the customer and the contractor and within the companies. This could be a result of a strong contractor, the fact that the network is developing a subsystem, but also on the type of subsystem developed. Finally, our results confirm that the project scope influences the design process. A conclusion is that the difference of design practices between companies [5] is true even between different lOBNs. The need for maturity in PD seems to be dependent on if the IOBN is developing an own product or a subsystem as a consultant, but also on the complexity in the project. The degree of structure in the PD also seems to be dependent on previous experience of PD. References [1] Norell, M., "Managing Integrated Product Development", Critical Enthusiasm Contributions to Design Science. Department of Product Design Engineering, Norwegian University of Technology and Natural Science, Trondheim, 1999, pp 129136 Warnecke, H.J., "The Fractal Company A Revolution in Corporate Culture". Berlin, Germany, 1993 Hedberg, B., Dahlgren, G., Hansson, J. and Olve, N.-G., "Virtual Organizations and Beyond. Discover Imaginary Systems" Chichester, England, 1997. McCormack, U. and Oliver, N., "Networked New Product Development in the Biomedical Industry: An Organisational Perspective", Proc. EIASM '99. Cambridge, 1999, pp 771-785 Carlson, S., Kemser Skalak, H.-P. and Ter-Minassian, N., "Defining a Product Development Methodology with Concurrent Engineering for Small Manufacturing Companies", Journal of Engineering Design. Vol. 8, No. 4, 1997, pp 305-328 Hietikko, E. and Parkkinen, H., "Principles and Tools of Concurrent Engineering in Network of Small and Medium Sized Companies", Proc. ICED '99. Munich, 1999, pp 329-332 Andreasen, M. and Hein, L., "Integrated Product Development". London, U.K. 1987 Vajna, S., Burchardt, C. and Richter, A., "Organizing Integrated Product Development with network Structures" Proc. ICED '99. Munich, 1999, pp 393-396

[2] [3] [4]

[5]

[6]

[7] [8]

Jorgen Pilemalm Royal Institute of Technology, Department of Machine Design, SE-100 44 Stockholm, Sweden, Phone: +46 8 790 68 61, Fax: +46 8 20 22 87, E-mail: jorgen@md.kth.se IMechE 2001

408

ICED 01 - C586/145

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

ORGANIZATIONAL DESIGN - A TOOL FOR EVALUATING ALTERNATIVE EXTENDED ENTERPRISE STRUCTURES

A McKay and A de Pennington Keywords: extended enterprise design, supply chain design, interfacing suppliers and manufacturers to customers,

Abstract
3D Concurrent Engineering (3DCE) draws upon parallels between product and supply chain architectures to provide insights into supply chain performance and design. In essence, 3DCE argues for the parallel development of product, process and supply chain. Three dimensions from which supply chains can be viewed (organisation, technology and business capability) and four kinds of proximity (organisational, cultural, electronic and geographic) that are features of supply chains are provided; in integral (as opposed to modular) supply chains the proximities are close. More broadly, these proximities can be seen as indicators to the likely success of proposed supply chain configurations. For example, data exchange between organisations is more likely to be successful when the organisations have similar hardware and software platforms: a high electronic proximity. This paper reports on research that resulted in the establishment of a software tool that drew upon learning from product design and data representation and applied it to the representation and analysis of alternative supply chain structures. The purpose of this paper is to illustrate how learning from the representation of products, and specifically product structures, can be applied to the representation and design of enterprise architectures. A data model for the representation of extended enterprise structures is presented; supply chains can be seen as paths through extended enterprise networks. This data model has been successfully implemented in a relational database. Its use to support a prototypical software tool that allows alternative extended enterprise structures to be visualised is discussed.

Introduction

Research on the operation of retail packaging supply chains has indicated that there are drawbacks in having information flows mirror the product flows in a given supply chain [1]. Benefits can be gained, especially in terms of improved quality and reduced costs and lead times, by considering and implementing chains for the flow of information that are not necessarily the same as the [product] supply chain. For example, Fisher [2] argues that, before devising a supply chain, one should consider factors such as the demand for the product and the kind of product that is being produced. These can be seen as requirements in a supply chain design process. Krishnan and Ulrich identify four kinds of product development decisions that are alluded to in the literature: namely, concept development, supply chain design, product design and production ramp-up and launch [3]. Like any design decisions, support for decision-making processes related to the configuration of supply chains

ICED01-C586/431

409

require both representations of alternative supply chain structures and tools that allow the alternatives to be evaluated. The research reported in this paper asked the question, "Can techniques used to support product design decision-making processes be transferred to the domain of supply chain design?" Research with industry sectors that produce large systems (for example, aircraft and marine vessels) has concluded that there is a need for people to be able to consider a number of extended enterprise structures in parallel and then make trade-offs between them. Further, these extended enterprise structures cover the entire product life-cycle, from concept to inservice support, rather than the supply chain alone. For example, at the early stages of product development, a prime contractor on a long-term project might wish to explore the risk of key suppliers becoming insolvent through a cash flow enterprise structure. Here, decision-making processes related to the configuration of extended enterprise structures, one of which might be a supply chain structure, are needed; both representations of alternative extended enterprise structures and tools that allow the alternatives to be evaluated are required to support such processes. This paper describes such a tool and its associated extended enterprise representation scheme. The tool allows people to visualise alternative extended enterprise structures. Its use in support of an analysis of the electronic proximities within alternative supply chain structures is described. A case study is used to is used to illustrate the capability of the representation scheme.

Case study

The case study that is used in this paper is a synthetic supply chain based on the fast moving consumer goods sector. It has been synthesised from a number of specific examples from retail packaging chains. A key player in the chain is a sandwich maker that has been required to work, by a supermarket that it supplies, with a given package manufacturer and a given label manufacturer. The supermarket demands that these suppliers will supply the packaging for a new style of pre-packed sandwich. The sandwich maker is a packer/filler during the operation of the supply chain. It also has overall responsibility for designing the packaged sandwiches which includes both labels and a container for the sandwiches. The supply chain is illustrated in the schematic given in Figure 1.

Figure 1: The example supply chain (in operation)

Figure 2: Design chain scenario 2

410

ICED01-C586/431

It can be seen that the product supply chain is defined by the supermarket. However, although it frequently is the case, it does not follow that the organisations must work in a similar chain during the design phase except passing product requirements down the chain (from customer to supplier) and product [design] definitions up the chain (from supplier to customer). In fact, experience dictates that teams of partners are more effective in carrying out design processes than chains of suppliers. Hence, discussions within product development projects lead to questions such as, "What are the best extended enterprise structures for the product development and production processes?" An alternative design chain structure is given in Figure 2. Here the package, label and sandwich makers work together collaboratively on the design of the packs of sandwiches. The dashed circle denotes a "virtual" organisation that works on the design [7]. Later in this paper, these two scenarios are modelled and their electronic proximity evaluated.

Background
Supply chain modelling and research has directed much effort towards improving the performance and operation of supply chains [8]. Supply chain design, on the other hand, has received far less attention [3]. In supply chains the key players are customers and suppliers with information, artefacts and money flowing between them. The research reported in this paper builds upon an alternative view. It considers the notion of an extended enterprise where the key players are stakeholders. A benefit of taking this view is that players who are typically considered to be outside the supply chain, for example, designers according to SCOR (The Supply Chain Council's Supply Chain Operation Reference model'), can be considered as a being a part of a system that is the extended enterprise. Fine [9] argues that supply chains should be designed concurrently with the product and the process: namely, 3D concurrent engineering (3DCE). A logical conclusion from Fine's work is that people carrying out 3DCE will need such tools when they are synthesising and analysing supply chains in addition to product and process design tools [10]. Tools for visualising supply chains are an early step on a path towards tools to allow people to design products in parallel with the organisations [supply chains] that will make, deliver and use them, and then evaluate their potential effectiveness.

2.1 Extended enterprises

An extended enterprise is a collection of organisations related to each other through a network of relationships. Some relationships create pathways along which things flow. For example, a supply chain includes paths through which goods and services flow; supply chain processes are what make the goods and services flow between the organisations in the supply chain. During the operation of a supply chain, supply chain processes make the flows (material and information) flow. The Supply Chain Council's Supply Chain Operation Reference model (SCOR) describes four key processes for each organisation that are needed to ensure effective supply chain operation: source, make, deliver and plan. Supply chains are not the only kind of path that exist. Extended enterprise processes in general make flows flow around extended enterprise networks. An important factor in determining what flows and the most appropriate pathway depends upon the stage of the product life-cycle. Different kinds of relationship exist and organisations can be seen to play different roles, for example, organisational [product] provider, technology provider, business capability provider. Brandenburger [11] identifies co-operation (e.g., along a supply chain) and competition as
1

Supply Chain Council - http://www.scc.org

ICED 01 - C586/431

411

two types of relationship that occur in an extended enterprise. Other relationship types include complementation (doing things that improve the product of another organisation's product for its customer) and collaboration (for example, partnership).

2.2 Designing supply chains

According to Suh [12] any design process includes three processes: synthesis, analysis and decision making. For example, an extended enterprise designer might create [i.e. synthesise] three alternative extended enterprise scenarios. Each scenario could then be analysed and, finally, a decision made as to which was the best, for example, the most fit for purpose or the least risky. Alternatively the extended enterprise designer could decide to create more extended enterprise scenarios. The research reported in this paper used the data model (see later) to capture the alternative extended enterprise scenarios and underpin an electronic proximity tool with which to analyse the scenarios. Presently, clearly defined and rigorous mechanisms for selecting the "best" design are unclear. However, it does appear that what constitutes a desirable supply chain structure depends upon the nature of the flows and the product life-cycle process that is to be carried out. For example, if flow is a commodity and widely available then the closeness of a customer and its supplier might be less of a priority than for a flow that is critical to the success of the customer's own product or process. An earlier example highlighted the importance of life-cycle stage.

Electronic proximity data model

When considered as a structure, a supply chain can be modelled as a collection of related elements and relationships. Lee [13], for example, models a two-level supply chain in terms of the companies on each level and the relationships, in his case an information flow of demand data, between them. In product structures, composition relationships are typically used in administrative tasks (such as planning and purchasing) whereas connection relationships are typically used in technical tasks (such as design, planning to manufacture, manufacture and maintenance) [14]. As in product design, in supply chain design the interfaces between organisations are of primary importance.

3.1 A note on the EXPRESS-G notation

This summary is intended to provide sufficient information for readers to understand the EXPRESS-G diagrams in this paper. In the EXPRESS language [15], entities are used to describe the concepts that are being modelled and the attributes of entities are used to describe relationships between these concepts. EXPRESS-G boxes represent entities and fine lines between boxes represent attributes. The plain end of the fine line is placed at the box representing the entity to which the attribute belongs and the circled end is placed at the box representing the [data] type of the attribute. Boxes are labelled with the name of the entity and fine lines are labelled with the name of the attribute. Thick lines between entities are used to show EXPRESS sub/supertype (specialisation/generalisation) structures. The "(1)'" label means that the sub-supertype relationship is of the ONEOF type.

412

ICED01-C586/431

3.2 Data model definition

The data model that was used to represent supply chain structures and support the electronic proximity analysis is defined in Figure 3 using the EXPRESS-G notation. The identification of each organisation in the chain is represented as an instance of the organisation entity. The organisation_deflnition entity allows a given organisation to participate in multiple chains whilst the characterised_organisation_definition entity allows each participation to be characterised in a number of ways. For example, the electronic proximity for exchanging product requirements may be different to that for exchanging product definitions (such as shape models) because different computing environments might be used in each case.

Figure 3: Data model to support electronic proximity analysis

It can be deduced that a "full" instance of the data model would need to explicitly characterise each communication channel in the extended enterprise or supply chain. The organisation_E_charas entity captures the data about an organisation in a communication channel that are needed for the electronic proximity analysis to be carried out. The characterised_organisation_definition_relationship entity allows each relationship, in this case communication channel, to be characterised. In practice we found a need for only one characterisation of each communication channel but in principle there appears to be no reason to prohibit multiple characterisations. Similarly to the organisation_E_charas entity, the re!ationship_E_charas entity captures the data about a communication channel between organisations that is needed for the electronic proximity analysis to be carried out.

3.3 Data model population

Example instances of the data model, populated with selected parts of the case study data, are given in Figures 4 and 5 using the EXPRESS-1-G notation [17]. Figure 4 shows the relationships between the sandwich maker and the package maker in Scenario 1. It can be seen that each flow, that is one of product requirements and one of product definitions, are represented separately. This is to allow for the fact that different computing environments are likely to be used in the different contexts. The relationships between the sandwich maker, the label maker and the package maker in Scenario 2 are given in Figure 4. There are fewer relationships because each of the flows concerned in Scenario 2 are bi-directional. In practice more than one relationship might need to be represented. However, the purpose of

ICED01-C586/431

413

the electronic proximity is to inform extended enterprise decision makers about the electronic proximity of alternative configurations and not necessarily to reduce the number of relationships that are present. A key point to note in Figures 4 and 5 is that the real difference is in terms of the relationships between organisations and not the organisations themselves. In the design of a supply (or design) chain trade-offs between the different proximities would need to be made.

Figure 4: Partial representation of Scenario 1

Electronic proximity software tool

The purpose of this research was to examine whether insights can be gained by applying product data engineering techniques to the representation of extended enterprise structures. If appropriate, tools to support supply chain designer in their decision making processes [3] become a real possibility. Emphasis was placed more on the underlying representation scheme than on the calculation of electronic proximities. The software that was implemented calculated electronic proximity by considering each defined relationship in turn. For each relationship the characteristics of the related organisations [context of use, software, operating system and hardware] were compared and given a value of 1 if they were the same as each other and 6 if they were not the same as each other. Thus, for example, a pair of companies using the same software in the same context but on different operating systems and hardware platforms are less electronically close than a pair of companies using the same software in the same context and with the same operating systems and hardware platform. Similar values were assigned to characteristics of the relationship itself. The data model was implemented in a relational database [Microsoft's Access] and the electronic proximity software was implemented using SQL queries.

414

ICED01-C586/431

Figure 5: Partial representation of Scenario 2

Conclusions

There is a real need for tools that will support extended enterprise and supply chain design decision-making processes. Research issues include identifying the key attributes of extended enterprises and, initially at least, supporting the quick visualisation of alternative structures. Extended enterprises are socio-technical systems and many of the issues to be resolved relate to human issues, for example trust [18], and to the dynamics of their operation; the latter leads to a need to link work on extended enterprise design with simulation tools. It is not clear that extended enterprise structures can be optimised for all participants. However, given the appropriate tools, it is possible to build robust extended enterprise structures that are fit for purpose. There is an intrinsic interdependency between an extended enterprise and the products and processes of the participating organisations. As such, an extended enterprise system will only perform as desired if it reflects the policies and processes used by the various stakeholders within the system. The research reported here has started to provide an integrated modelling and analysis tool for extended enterprise supply chains. New methodologies are required to handle uncertainties inherent in, for example, supplier reliability and changes of requirements imposed by customers.

Acknowledgements
This research was carried out as part of the UK EPSRC/SII project no. GR/M56715 (MAPPSEE). The academic partners are University of Leeds and De Montfort University and the industrial partners are BAE Systems and Rolls-Royce plc. References [1] Christensen, C.M., The Innovator's dilemma: When New Technologies Cause Great Firms to Fail. 1997: Harvard Business School Press.

ICED01-C586/431

415

[2] [3]

Fisher, ML., What is the right supply chain for your product? Harvard Business Review, 1997: p. 105-116. Krishnan, V. and K.T. Ulrich, Product development decisions: a review of the literature. 1998, Department of Operations and Information Management, The Wharton School, Philadelphia, USA. p. 1-33. Checkland, P.B., Achieving Desirable and Feasible Change: an Application of Soft Systems Methodology. Journal of Operational Research Society, 1985. 36(9): p. 821831. Warboys, B., et al., Business Information Systems: a Process Approach. 1999: McGraw-Hill. Andreasen, M.M., C.T. Hansen, and N.H. Mortensen. On the identification of product structure laws, in 3rd WDK Workshop on Product Structuring. 1997. Delft University of Technology, Delft, The Netherlands. Venkatraman, N. and J. Henderson, Real strategies for virtual organizing. Sloan Management Review, 1998: p. 33-48. Towill, D.R., Supply chain dynamics - the change engineering challenge of the mid 1990s. Proceedings of the Institution of Mechanical Engineers, 1992. 206: p. 233-245. Fine, C.H., Clockspeed: Winning Industry Control in the Age of Temporary Advantage. 1999. Perseus Books

[4]

[5] [6]

[7] [8] [9]

[10] Malone, T., et al., Tools for inventing organisations: Toward a handbook of organizational processes. Management Science, 1999. 45(3): p. 425-443. [11] Brandenburger, A.M., B.J. Nalebuff, and A. Brandenberger, Co-opetition. 1997: Doubleday. [12] Sun, N.P., The principles of design. 1990: Oxford University Press. [13] Lee, H.L.S., C So; Tang, Christopher S;, The Value of Information Sharing in a TwoLevel Supply Chain. Management Science, 2000. 46(5): p. 626-643. [14] McKay, A. A framework for the characterization of product structures, in 3rd WDK Workshop on Product Structuring. 1997. [15] ISO10303-11, EXPRESS Language Reference Manual. Industrial Automation Systems and Integration - Product Data Representations and Exchange. Vol. ISO 10303-11. 1994: ISO. [16] ISO10303-1, Overview and fundamental principles. Industrial Automation Systems and Integration - Product Data Representations and Exchange. Vol. ISO 10303-1. 1994: ISO. [17] McKay, A., et al. EXPRESS-I-G: A graphical notation for EXPRESS-I. in EXPRESS User's Group (EUG'93) Conference. 1993. [18] Clegg, C.W., M.O. Gray, and P.E. Waterson, The "Charge of the Byte Brigade" and a socio-technical response. International Journal of Human-Computer Studies, 2000. 52: p. 235-251.

Dr Alison McKay, School of Mechanical Engineering, University of Leeds, Leeds, UK, LS2 9JT, telephone: 01132332217, fax: 0113 233 2150, a.mckay@lecds.ac.uk IMechE 2001

416

ICED 01 - C586/431

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

CULTURAL ISSUES IN AEROSPACE ENGINEERING DESIGN TEAMS

K H Payne and P J Deasley

Keywords: Concurrent Engineering, Culture, Design Teams, Human Resources

1 Introduction
Recent years have seen the Aerospace industry move to product development approaches that are more concurrent. One approach is the Integrated Product Development (IPD) Process. A principle of IPD is to organise around multi-functional Engineering Design Teams or Integrated Product Teams (IPTs). IPT members are not only multifunctional but also likely to work for different companies, have different nationalities and languages and stem from different sites of one company or even be scattered across the globe. This paper presents research carried out to understand the cultural issues faced by these IPTs in the aerospace industry, and why culture differences are important. Existing approaches to cultural assessment are reviewed, as well as their limitations. A description of a new assessment technique is presented. Based on findings from this technique the paper discusses some cultural issues faced by IPTs. It concludes with suggestions for future work and thoughts about how this information can be used for other means such as training, partner selection and to support distributed IPTs that are increasingly being used.

2 Background
IPTs are composed of representatives from all appropriate functional disciplines, major subcontractors, and customer representatives, working with a team leader to identify and resolve issues and to make sound and timely decisions throughout the design and manufacture of a product. Once on a team, the role of an IPT member changes from that of a representative of a particular function focusing on a given discipline, to that of a team member who focuses on a product and associated processes. Getting people together from several functions is intended to promote a complete understanding of requirements resulting in superior products, which satisfy the customer needs appropriately. In the very basic circumstances IPTs ensure that engineering and manufacturing agree with the product design. In addition, IPTs encourage the integration of customer representatives and the main suppliers to work alongside the prime contractor in the initial development phases. This is primarily to understand the needs of the customer to a greater extent, and to ensure that the customers and the key suppliers are happy with a design at the outset of the development process. In an increasingly global industry, IPTs can include individuals from different countries. Initial investigations were carried out to understand the key issues faced by IPTs. The investigations used techniques such as workshops, surveys and semi-structured interviews, involving IPT members from more than 30 different aerospace organisations. The information collected from this work formed several conclusions. The first was that one of the biggest

ICED01-C586/035

417

problems for IPTs is the 'culture' differences existing between team members. Secondly, culture differences occur at different levels within a team, for example, national, organisational, functional, site and project cultures. Finally, individuals found it difficult to define what they meant by 'culture', and identify which elements caused the greatest problems. A large amount of literature in this area focused on cultures of different nations, for example [1] and [2]; or organisational culture, for example [3] and [4]. The limitations of this are that many existing models fail to consider regional cultures of nations, or organisations. In addition, the structure of IPTs can mean that the culture composition is more complex than previous models can accommodate.

2.1 Subcultures
Culture does not only occur at national or organisational levels. It is incorrect to assume that any nation or organisation is solely influenced by a single culture. In reality there can be any number of subcultures, and it is inappropriate to assume one culture per organisation [5]. By making such an assumption, it should not matter who describes the culture, or at what hierarchical level or geographic region or product division the individual is from, the resulting conclusion should be the same. This is unlikely to be the case. The assumption of a single culture fails to recognise that each hierarchical level; geographic region or product division may be the potential site of a distinct culture itself. This phenomenon is even more likely to apply to IPTs, in which case it would be incorrect to assume one culture per team. The structuring of organisations into work roles affects patterns of interactions between individuals. Each role brings with it specific tasks and a particular status relative to other roles [5]. The degree of interaction between members and between roles differs so that some individuals will interact with others more frequently if they share the same problems, or are working on the same product or project. From these interactions, subcultures will develop. The division of organisations into functions and specialist areas has promoted a greater creation of subcultures. The specialisation of functions narrows the number of employees who are able to do a particular type of work [5]. As each specialisation develops it's own language, norms, perspectives and objectives, sub-cultural abundance should be expected.

2.2 Barriers caused by culture differences

The presence of different cultures can create barriers, leading to reductions in team effectiveness1 due to poor communication [6]. Effective communication between members of an IPT is vital as it allows focus on what is important. Ineffective communication discourages the free exchange of ideas, up and down the product development cycle. With ineffective communication comes the danger that deficiencies discovered in the downstream activities in a product lifecycle may not be correctly communicated to upstream activities [6]. A second barrier is parochialism [7], viewing the world solely through one's own eyes, leading to the belief, "my way is the only way to do things". A person with a parochial perspective neither recognises other people's different ways of working nor appreciates that such differences have serious consequences. Parochialism can be observed when things go wrong and individuals point the finger to somebody else with the refrain of, "If only they had made it the way I had designed it." [8]. A third barrier, ethnocentricity or judging another by one's own standards makes individuals unable to understand another culture. It leads to false
1 Whilst this paper discusses the effect of culture differences on team effectiveness, this is based on perceptions of effectiveness rather than specific measures.

418

ICED01-C586/035

distortions of what is meaningful to others through one's own eyes, causing a failure to understand that another's ways have their own meanings and functions in life and these may be different to one's own. Related to parochialism is arrogance, which reflects one's closure to outside opinion [9]. Arrogance is a similar expression of an unwillingness to value and incorporate the contributions of other cultures. Ignoring these barriers has the potential to reduce team effectiveness; it creates conflict between members and causes misunderstandings, which can lead to engineering changes occurring later in the product development process. It also prevents opportunities for recognising cultural diversity within team members. All too often, cultural diversity is seen as an area of difficulty rather than as an opportunity to build a competitive advantage for the team [7].

3 Culture Assessment
Whilst it is evident that differences are present between different cultural groups, and these differences can be detrimental to IPTs, it is less obvious how to assess the differences and their impact. There are different ways that culture assessment has been carried out. There are many different cultural assessment techniques available. The first type of culture techniques is quantitative in nature. They typically require respondents to rank, or rate their respective culture along a particular dimension, for example, "On a 1 to 10 scale, rank the extent of information transfer within your organisation" [10]. This may involve completing the assessment twice - the first response based on the culture of the respondent's organisation, and the second response based on the culture of another organisation. The technique can also be used to assess differences between actual and desired cultures. Other quantitative techniques require respondents to allocate points between statements, awarding the highest points to the statement that best reflects their culture [11]. There are drawbacks to quantitative approaches. They are simple to administer and analyse, but do not allow for variations in the interpretations of the statements, or rating scales. For example, two individuals rating very strong agreement with a statement may be rating it for different reasons. Quantitative approaches do not capture these reasons. Finally, quantitative assessment techniques assume that the assessor (and the scale developer) fully understand that the exact item being assessed is known and can be evaluated (or quantified) using a single number. This is unlikely to be the case due to the complexity of the phenomenon of culture. The second type of techniques is qualitative in nature. Qualitative data contain rich information that is often deep in content and context. Whilst qualitative information is harder to analyse, it is useful in assessing culture where contextual information is important for understanding meaning. It provides a basis for further exploration and identifies areas of the culture that quantitative assessment would not. An example of a qualitative assessment technique is the Cultural Web [4]. This requires respondents to answer questions relating to six different aspects of culture including 'Symbols', 'Structure' and 'Control Systems', and a 'Cultural Paradigm' representing the core of an organisation's culture.

3.1 Limitations of traditional approaches

One of the limitations of the existing cultural assessment techniques is that many of them have been developed for generic use across different industries. This has a practical benefit as the same technique can be used across many industries, but may be less reliable than a technique developed in, and used in a single industry. The cultural factors that are important for one industry, i.e. aerospace, may be different from those that are important for another, i.e., automotive. The industry itself may be considered as another culture level, i.e.

ICED01-C586/035

419

"aerospace" culture. Different industries operate by different means: they have different relationships with customers and suppliers, different motivations and goals, and different production characteristics. For example, the aerospace industry is a low-volume manufacturer of products with typical lead times of 10-15 years, with new products developed every 10-20 years. The customer plays a strong role in product development and selects the manufacturers of the main sub-systems. In contrast, the automotive industry is a high-volume manufacturer of products that have lead times of (typically) 24-36 months, occurring relatively frequently with new products being developed every 1-2 years. The products are relatively standardised, although the customer is increasingly able to make choices about some of the features of the product, but with relatively little impact on the choice of the suppliers. Probably the most serious limitation of many of the techniques has been pointed out by Edgar Schein [12] who questioned whether the phenomenon was understood adequately. He claimed that the label of "culture1 had been hung on everything from behavioural patterns to new corporate values that senior management wished to incorporate into an organisation. How is it possible to measure something that isn't understood properly? If this is the case, then one of the first objectives in the development of any cultural assessment technique is to understand the concept of culture fully, and in the context of the industry.

4 Developing a new framework

The initial investigations produced many factors perceived to contribute to culture differences and the creation of barriers to effective team performance, including language, motivation, values, politics, and structure. Following an extensive literature review and the identification of 55 cultural factors creating barriers to working together, an industrial survey was carried out to determine which of these 55 factors had the greatest impact on individuals working together. A factor analysis was carried out on the data and based on the results, a five-factor framework was produced to provide a basis for understanding those components of culture that have the greatest impact on IPTs and team members working together. The total variance explained by the factor analysis model was 60.649%. Table 1 presents the percentage of variance explained by each of the resulting five factors. The five factors of the framework consisted of 19 variables from the original 55 variables, about Communication; Leadership; Practices undertaken; the Structure; and characteristics of the working Environment. Table 2 presents the distribution of the variables in the five factors.
Table 1. Variance explained in factor analysis model

Factor

1 2 3 4 5

% of variance 19.637 15.449 9.639 8.135 7.789

Cumulative % 19.637 35.086 44.726 52.861 60.649 (total)

The factors and associated variables were assembled into a workbook. This provided details of each variable and it's relative impact on the culture of the environment, including 49 open questions relating to the variables. For example, "What is the 'working language of your culture?"; "What traditions are present within your culture?".

420

ICED 01 - C586/035

Table 2.

Variables within each factor

Factor Practices Structure Communication Leadership Environment

Variables within the factor Knowledge sharing; Expertise; Decision making; Trust; Roles & contributions; Motivation; Work ownership Reporting hierarchies; Values held; Structure; Management control; Flexibility Language; Approach to communication Support for initiative; Leadership style Stability; Politics; Goals & objectives

5 Case Studies
The workbook was partially validated using three case study applications in order to assess it's effectiveness and usefulness in the industry. A vast amount of qualitative data were produced. Some of the findings are presented below.

5.1 Case study one - Organisational culture

Case study one involved the assessment of culture differences between two recently merged organisations from the military aerospace sector. The merger had created a project set-up where individuals from both organisations were expected to work together. Seven individuals took part, four from organisation A and three from organisation B. One issue was that prior to the merger, organisation B had been a major supplier to A. Individuals from A felt that individuals from B were "muscling into their territory", creating an environment of mistrust. A perceived B as uncooperative and stubborn. B perceived that A was suffering from jealousy due to changes in the way that projects were distributed following the merger. In addition, the prime customers of both A and B (pre-merger) had very different influences on the respective organisations. The customer's culture can heavily influence the culture of a supplier. To a large extent, the main customer of A tends to be defence ministries, both in the UK and abroad. The organisation is driven by (possibly dictated by) the need to develop products to suitable design and cost for government(s) in order to retain their custom. Defence ministries had less direct influence over organisation B. The leadership style of A is perceived as close to manager-centred with a desire to be teamcentred, and possibly attempting to shift to a more democratic direction. The leadership style at B is perceived as being autocratic and manager-centred to a greater extent. Within A, there appears to be a greater focus on responsibility to the functions, whereas in B, responsibility appears to be towards projects. The values held by individuals at B are strongly financial in orientation, i.e. Finance has the last word, and is seen as highest in order of importance. In contrast, individuals at A tend to value 'people' aspects of the work. The main reason for this culture was thought to be the legacy from a Managing Director of B who was known for maintaining tight financial control and a 'process mentality' throughout the organisation.

5.2 Case study two - National culture

The second case study involved an IPT working on a civil aerospace project, with a military application. The project comprised individuals from several different nationalities, but working for the same organisation. The team had been experiencing cultural difficulties

ICED01-C586/035

421

between several of the different nationalities and was interested in understanding why this was happening. Three individuals took part, two British males and an Italian female. The findings indicated displays of nationalism from both the British and Italian respondents, which were negative in connotation. There was evidence of 'Europa-phobia' between individuals of different nationalities, even in the same organisation and at the same site. The Italian respondent felt that foreign team members had the potential for introducing new ideas, yet these were perceived to be rejected because of the potential for misunderstanding by British members. The values of the British and Italian respondents differed. The values of the British respondents tended to relate to the organisation, yet for the Italian respondent the values were towards hard work and perseverance. The Italian respondent described how British people value time, and how they will leave work when it is time, rather than staying to complete work. This reflects the British' sequential culture concerning time orientation, identified by Trompenaars and Hampden-Turner [2]. There were issues concerning language differences even though both groups used English as the working language. For example, the British respondents described problems of explaining instructions slowly and repeatedly.

5.3 Case study three - Site culture

The third case study looked at cultures from different sites within the same organisation working on a military aerospace project. The IPT comprised eight individuals at three different military aerospace sites. Four individuals were from site X, three were from site Y and one from site Z. The team had recently been created for a short-term aerospace project involving the improvement of specifications of an existing aircraft. Findings highlighted that different sites of the same organisation have different cultures. For example, there were differences in leadership and decision-making styles. Individuals at site X were encouraged to be involved with other projects and information was shared openly, yet at site Y, individuals felt that there was very little information sharing between projects, and "people held their cards very close to their chest". One cause of the culture at site Z is the recent threat of closure. This has meant that individuals have operated in a flexible manner to accommodate changes, there is little formal organisational structure, and the company has carried out work outside of the aerospace industry in order to survive. The differences in cultures may be due to several reasons. The first may be company heritage of the respective sites. Each site was owned by different organisations over the past 100 years. Whilst significant changes occur with the introduction of each organisation, several individuals commented that "culture is in the walls", implying even if you change the practices and processes of the people, the basic culture remains. All three sites are located in the north of England, but site culture differences may be partly due the location of the site. There was evidence of culture stereotypes based on geographical location. For example, "they have whippets and flat caps" (a characteristic Northern stereotype), even though the sites are only about 75 miles apart from each other - a relatively short distance in a global industry!

6 Cultural Issues for Aerospace Teams

The case studies raised several issues for IPTs in the Aerospace industry. The first is concerned with culture change. Whilst the desirable solution may be to change the cultures of team members to match other's culture, this is problematic in the context. IPTs are formed on a temporary basis and team members move to new teams on completion of the project. In which case, culture change may be required again for this new team. One suggestion to

422

ICED01-C586/03

overcome this is the use of techniques allowing cultural alignment (as opposed to change) and appreciation, to be carried out. This would allow team members with different cultures to work together without the need for change, yet understand reasons for differences. The second issue is that IPTs have a complex structure consisting of many different types of culture. The inherent nature of an IPT means that at the very least, an IPT will comprise team members from different functions, and major subcontractors. Increasing use of globalisation and consortiums has meant that IPTs frequently comprise team members from different nationalities, different organisations, and different sites (especially for large organisations occupying different locations in one country). With each division comes another subculture, and each team member may be a member of several different subcultures at any one time. The third issue to consider is that the role of leader of an IPT may be more than simply ensuring that a product or project is delivered to specification. The team leader may become a 'controller' of the team culture. For instance, the team leader might have the authority to control how resources are allocated, how individuals behave, how decisions are made and so on. In addition, there is also an issue as to whether cultural behaviours should be encouraged in an environment in which they are not widespread. For example, a typical European greeting of kissing a person on a cheek may not be welcomed in a British engineering office. But does the British team leader have a right to preclude two European partners on his team from greeting each other, or other British team members in this manner? Stereotypes may play a significant part in how outsiders view the culture of others. Mullins [13] describes stereotyping as the tendency to ascribe positive or negative characteristics to a person on the basis of a general categorisation. It occurs when an individual is judged on the basis of the group, to which they belong, for example, individuals belonging to a group are all seen as having the same characteristics. Mullins provides examples of stereotyping, "All Germans are orderly and industrious" (Nationality); "All accountants are boring" (Profession). The danger is that stereotyping is a limited view of the average behaviour in a certain environment, and exaggerates and caricatures the culture of another. It also ignores the fact that individuals in the same culture do not necessarily behave according to the cultural norm, or the stereotype [2]. The impact of customers and suppliers can affect the cultures of team members. In some situations, suppliers can develop cultural traits similar to their customer. Being dependant on major customers for business can mean that companies listen to their customer's needs intently. In some cases, customer's needs and wants have become the raison d'etre of the company's philosophy, [14]. Based on the findings from this research there are implications for training programmes for awareness of the complexity of the IPT structure and it's potential effect on problems that can arise between individuals. IPT members need to be aware of these issues, the origin of cultural behaviour and possible detrimental effects on IPT performance. In addition, there are questions to be considered, for example, do individual differences such as personality characteristics and gender have any effect on the extent to which culture differences might cause problems between individuals in IPTs?

7 Conclusions
The implications of this research to engineering teams include: better team management; more effective team performance; improved team communication (possibly leading to fewer engineering changes); and enhanced collaboration within IPTs. This research was carried out within a project developing tools and techniques for distributed IPTs. Distributed IPT

ICED 01 - C586/035

423

members work apart for long periods, with relatively little collocation. Whilst desirable, it is resource consuming to spend time understanding the culture of colleagues to appreciate why they might work differently. Tools, such as the one described, allow distributed members to appreciate culture differences and their origin. The value of qualitative information extends beyond cultural assessments. The data help to build scenarios to accelerate the introduction of new team members into an IPT. This technique may also provide due diligence potential prior to selecting team members, or to allow customers selecting suppliers, or organisations selecting partners to assess the culture in order to favour those that are most culturally aligned to themselves. It may be more effective to chose teams to work with that are more aligned to one's own culture, to reduce the likelihood of conflict occurring. References [I] [2] [3] [4] [5] [6] [7] [8] Hofstede, G. Identifying Organizational Subculture: An Empirical Approach. Journal of Management Studies, 35 (1), 1-12, 1998. Trompenaars, F. and Hampden-Turner, C. Riding the Waves of Culture, Nicholas Brealey Publishing Ltd., Naperville, IL, 1999. Handy, C. Understanding Organizations. Penguin Books Ltd., Middlesex, 1993. Johnson, G. Managing Strategic Change: Strategy, Culture and Action. Long Range Planning, 25(1), 28-36, 1992. Frost, P.J.; Moore, L.F.; Louis, M.R.; Lundberg, C.C. and Martin, J. Organizational Culture. Sage Publications, Beverly Hills, CA., 1995. Clark, K.B. & Fujimoto, T. Product Development Performance Strategy. Harvard Business School Press, Boston, MA, 1991. Adler, N.J. International Dimensions of Organizational Behaviour. South-Western College Publishing, Ohio, USA, 1997. Ashkenas, R.; Ulrich, D.; Jick, T. and Kerr, S. The Boundaryless Organisation: Breaking the Chains of Organizational Structure. Jossey-Bass Publishers, San Francisco, 1995. Fishbein, M. & Azjen, I.Belief, Attitude and Behaviour. Addison Wesley Publsihers Inc., Reading, MA. 1975.

[9]

[10] Galpin, T.J. & Herndon, M. The Complete Guide to Mergers and Acquisitions, JosseyBass Inc., San Francisco, CA, 1999. [II] Cameron, K.S. and Quinn, R.E. Diagnozing and Changing Organizational Culture. Addison-Wesley Longman Inc., 1999. [12] Schein, E.H. Organizational Culture. American Psychologist, 45, (2), 109-119, 1990. [13] Mullins, L.J. The Nature of Groups. Management and Organisational Behaviour. Pitman Publishing, Maidstone, Kent, 1996. [14] Harrison, M.I. Diagnosing Organizations. Sage Publications, CA. 1987 Katy Payne School of Industrial & Manufacturing, Cranfield University, Cranfield, Beds MK43 OAL, UK Tel: 01234 754194, Fax: 01234 750852, E-mail: k.payne@cranfield.ac.uk, Web Address: http://www.cranfield.ac.uk/sims/cim/people/payne.htm IMechE2001

424

ICED01-C586/035

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

SUPPORTING THE TEAMWORK BY NEW MEANS OF THE INFORMATION TECHNOLOGY

A M Kunz, S Miiller, T Kennel, K Lauche, and K Mbiti

Keywords: collaborative design tools; methodology; information technologies; product development process; design teams; computer supported collaborative work; human creativity;

Abstract

With increasing divulgence of the information technology also possibilities to support the teamwork are arising. In many fields of the product development process an IT-based support is available as for example in the design stage (CAD and PDM). However, the early stages in the product development process still go without the support of the information technology. The topic this paper is to show the causes of that and to show possible solutions.

Introduction

The complexity of new products requires to process the development tasks within a team. Especially in the product development process competition and time famine make the teamwork - the concurrent engineering - urgently necessary. In many enterprise processes modern information technologies are already used, for example in the design process and also in the sales process. In the early stages of a product development process, where in particular new ideas are created, the information technology is hardly used because the current available technology is not suitable to support a teamwork decisively. The early stages of the development process as a basis for a new product are based on creativity and imaginativeness in the individual person as well as in the team. At the present time the teamwork is based on a paper-based working method which is in a multiple way inadequate, however, in particular with larger groups. Also the documentation of a session is difficult since the integration of the results is complicated due to the unwieldy format of the paper presentations.

Motivation

Todays team sessions are based on classical methods like mindmapping, gallery method, outlining-method (6-3-5) etc. These methods are rule-based and their success depends very strongly on the composition of a group. Trained teams with personal experience show higher productivity than spontaneously gathered groups. In this case social competence or different levels in the persons hierarchy has an disturbing influence on the effectiveness of the group. Using the above methods requires self-confidence in order to present ideas, to review ideas of the others or to let own ideas to be assessed.

ICED 01 - C586/040

425

In addition, the use of the methods from the above requires that the contributions must be provided in a hard-copy form which must be clearly and readable. However, in most cases these requirements are not fulfilled. Taking the protocol of a teamsession often becomes very difficult because most of the ideas are created on flipchart papers that are not suitable for a protocol and the flipcharts must be processed afterwards. Additional mistakes arise from that which can noticeable reduce the success of a teamsession. Also very frequently information are needed which are not spontaneously available. This results in delays of the team session.

Contributions

In order to examine how a new technology can be used in the early stages of the product development process to avoid the above-mentioned difficulties a room was furnished with the currently available technique and practical investigations about his use were carried out. The objective was to find out whether this additional technique is usable or leads to a technical overkill. In a next stage the room will be redesigned and complemented by software tools in order to optimize the teamwork. The technology based conference environment is supposed to offer the following possibilities: presentation from system or laptop; mixedmedia-presentation (for example video, slides, overhead projector, plans, posters, rough paper drafts); simplified taking of the protocol; common sketching possibilities; smaller groups (for a short period of time a smaller formation of groups is possible); providing of external information from databases or out of the internet; integration of external participants by the use of videoconferencing; integration of conventional media and methods; possibility of mixedmode and all-digital methods. Figure 1 gives an overview of the technology-based conference environment:

Figure 1. Conference environment

The conference room includes in total three projection screens, two of them are used in connection with a touch-sensitive surface, the so-called SmartBoard. The third projection screen can be used for a stereoscopic projection or video. The touch-sensitive boards can be used for sketching. The color and the pen position are registered by the computer and the sketches are projected onto the touch-sensitive surface of

426

ICED 01 - C586/040

the board. Thus, the digitalization of the drawn pictures also fulfills the demand for a simplified recording and archiving because the data can be stored at any time. The touchsensitive boards represent the common sketching-possibility where the common ideas are created and visualized [4]. A video-conferencing equipment allows the transmitting of picture and sound to a remote station as well as an application sharing. This will allow to communicate and to work collaboratively with additional team members. Thus, it is possible to obtain additional information from further persons and to allow a teamwork via a physical network as well as acquiring spontaneously needed information. For the visualization of existing objects an additional camera is installed. The camera's picture can be projected onto the third projection screen. Small objects and prototypes can be shown to the team as well as conventional overhead slides or pictures. The technology based conference room is completed by the possibility to present videos as well as slides. With the linking of previous media it is possible to realize a mixed-media presentation. An additional connection at the conferencing table gives access to the projectors so that presentations can be directly carried out from a private laptop. The technical installation of the moderation room is completed by the possibility to plot large scale sketches from the touch-sensitive boards as well as the possibility for scaled printouts. Several test were made with the completely equipped conference room. The scope of these test is to find out the benefits of the new conference room and the way how the persons can work with this new technology. Furthermore it is supposed to be examined, whether previous working methods can be moved in the new moderation environment.

First Results

The series of experiments were carried out as far as possible with realistic problems. An essential criterion for the successful use of the conference room was the result and the duration of the session. The tests were carried out with students, with members of the institute and with industry partners in order to receive a representative sectional view. It was essential to the carried out series of experiments were made on real existing projects and not on artificial settings. Thus there was a real demand for moderation technique, for presentation technique or for the metaplan technique in order to carry out the team sessions (up to 10 persons) with maximum efficiency. For the teamsession traditional means were available as well as the described new technologies. The scope of the carried out experiments was to find out where the new technology could not be used anymore and the traditional means were used instead. The working with the new technologies and the different conferencing techniques needs a certain effort. Thus the usage of the moderation room and its technology requires basic knowledge in the information technology in order to take full advantage of the room within a short time.

Influence on the moderation techniques

In the following fields changes of the moderation technique arose that must be considered by the user:

ICED 01 - C586/040

427

6.1 Writing and sketching

The writing and sketching on touch-sensitive boards distinguishes considerably from that on paper. The recording of the pen position and color by the computer has a latency time which can lead to a confusion while working the first time with this device. Furthermore it has to be considered that the person causes a shadow onto the pressure-sensitive face when a front projection is used. Unlike the writing and sketching on normal paper the line drawn from the pen is only visible as soon as the person is out of the projection way. The shadow caused by the person can be eliminated when a back projection is used together with the touch-sensitive board. This solution is much more expensive and requires more space for the projection system. Although conventional pens are used for writing and sketching, the time delay, which is inherent to the system, must be considered at the presentation. The delay causes quantization mistakes when the speed of the tip exceeds the maximum value. This will result in an interrupted line although it was drawn continuously. The user must draw consciously slower in order to avoid those mistakes. The tests showed, that the user wasn't disturbed anymore by the effects from the above after a short training stage. After the training phase the writing and sketching on the touch-sensitive boards were possible as fast and simple as on traditional paper. Thus the traditional method and the technology based method are equivalent on this field.

6.2 Gallery method

During a discussion the writing and sketching is done on a poster. This poster will be used within the gallery method as an elaborated point when the discussion proceeds. The posters are in the person's field of view so they can refer on them if required. The gallery method allows a parallel visualization of several aspects, which can become important in case of comparative discussions. In a contrast to the above the usage of a touch-sensitive board allows only a serial visualization of the currently processed poster. A cross-reference is only possible by paging backward. However, this backward paging represents a break in the moderation process which should be avoided as far as possible. Through the serial representation of the processed posters on the touch-sensitive boards it is not possible to compare the individual posters. In the practical usage within the moderation room this deficiency can be counteract in two ways. The usage of two projection screens allows to visualize the current poster as well as one of the posters before. Thus it is possible to generate a new poster and to represent the preceding relevant posters simultaneously. By that the previously described break in the moderation process can be eliminated. Furthermore there is the possibility to print a poster on a A0-plotter and to use this printout for the gallery method. However, the practical test of these possibilities showed that the use of two touch-sensitive boards as well as the usage of the A0 plotter can only be done by experienced users. Furthermore it has to be considered that no changes or add-ons should be done on the printed posters because these modifications cannot be digitized for a later on usage. However, during the realization of the sessions it becomes clear that two projection screens for the realization of a fluid moderation are sufficient. The additional plotting of the constructed posters during a session was the exception and was not satisfying due to the high time consumption.

428

ICED 01 - C586/040

6.3 Metaplan technique

The metaplan method is used very frequently in workshops in order to create ideas and to find out opinions. This method also can be used for larger amount of session members. Within this method short contributions for a defaulted subject are written onto cards. On a common presentation wall the cards are arranged and combined to an entire unit. This method has the advantage that the participants can create their ideas in a certain anonymity without being disturbed by other influences. At the present time it is not possible to realize a technical supported metaplan method. There is no technique available to label a card, to digitize it and to displace it onto a common work area from the participant's place. If a metaplan technique is needed for a team session it must be done with the use of conventional means. This causes an interrupt in the technology-based teamwork. The results that are elaborated with the metaplan method are not digitized and must be processed afterwards for further use. Beside the time consumption further mistakes and corruption can arise from that. Therefore the metaplan method is not feasible in the above described environment.

6.4 Presentation
Presentations normally consist of two parts. This is the performance of a prepared visualization and the need of supplementary comments. The usage of the touch-sensitive boards offers two possibilities: on the one hand existing PowerPoint-slides can be complemented through additional rough drafts and comments, on the other hand complements can be represented also separately on the second touch-sensitive board. The test of this possibility brought out very good results. The test persons were mainly able to add complements on the second visualization equipment while the presentation was running on the first visualization equipment. The usage of both touch-sensitive boards did not cause any irritating media alternation but raised the listeners attention since the line of vision could be changed. The presenter must get used to the functionality of the touch-sensitive boards together with a PowerPoint-presentation. It allows to switch to the next slide by touching the surface. In the beginning mistakes occurred during the explanations of the slides combined with the human gesticulation (pointing).

6.5 Providing the information

During a session there is the need to provide additional information. The demand for such information arises spontaneous and is not foreseeable. If this information requirement can not be covered by existing materials, an information gap remains that complicates the further process of the session. With the technique installed in the conference room it is possible to retrieve information via the internet or intranet. The carried out test-sessions indicated that many information were already processed by the participants of a session and were provided on servers. Out of this reason the possibility of an information retrieval over a network is very useful. The network access is used in all utilization phases of the conference room: presentations were called up completely over a network and not carried around physically on computers or a missing information is procured during conversation or discussion. The delay which arose from the procuring of the information is marginal in comparison with a delayed session due to missing information. In total the availability of a network is very useful to support an effective teamwork.

ICED01-C586/040

429

6.6 Moderation
The technique installed in the conference room enables the presenter to form the moderation of a session more effectively. This is based mainly on a very good visualization of the subjects of interest. This is of interest when a discussion is based on these objects. If the objects are very small only a few members of the discussion can see them while all others have to wait. This causes an unnecessary delay of the discussion until everyone has seen the objects. The problem is eliminated in the conference room by the use of a camera, which takes the picture of the object and visualizes it on the third screen so it can be seen by everyone simultaneously. Tridimensional objects can be turned by moderator and facilitate thus the recognition of specific qualities or functionalities [5]. The sketching on the touchsensitive board can be visualized via two channels. Thus, the problem of hiding the sketches by the presenter is solved. The second projection screen is not masked and allows the listeners to perceive the visualization and the relevant explanation synchronously. The available technique enables the presenter to choose a fitting visualization device in order to present almost any information without any spill [2] [3]. However, this will result in new requirement profiles for the presenter, which are totally different from the conventional moderation techniques. An example will be the performed visualization with the use of projectors. This requires a partial or completely darkened room unlike a visualization on posters. Thus, the presenter and his gesticulation becomes less important and an important information channel between the presenter and the team-members is disabled. The classical rules of the presentation technique can only be relatively used in the technology based moderation environment. The usage of the devices is an additional task for the presenter and requires also new rules in the moderation. The result of the series of experiments was that persons without experience in moderation techniques are unable to handle both, the presentation and the technical equipment. In this case no benefit arises from the new technology. The available technique encourages the presenter to change the media very frequently which has a negative result on the listeners.

6.7 Teamwork
Very frequently larger sessions or workshops are splitted up into individual teams. These teams have to process exactly defined subject areas. The teamwork is followed by a presentation for the other workshop members. For the effective realization of the teamwork it is reasonable that the team starts with working materials made available by the plenum. It is conceivable that every group gets the complete technical setup. However, this is prohibited by the high costs. Due to the missing technical equipment conventional means like blackboards, flipcharts etc. are used instead. Using these conventional devices causes that the technological chain is disturbed. This implies that identical devices must be used for a later presentation of the teamwork in front of the group. From that a break of the technological concatenation results in a deactivation of the technological support. If a further work of the plenum is needed based on the results of the teams the plenum has to use the same means. In order to use the results of the teamwork later on the conventionally generated posters have to be post-processed and digitized. This results in additional work combined with a restructuring of the poster. Since any change can corrupt the poster's contents it is not recommended to make any modifications.

430

ICED 01 - C586/040

Furthermore a teamwork distinguishes considerably from a presentation. Beside the completely different working methods another essential difference is that the work area is horizontal during a teamwork while it is vertical for a presentation. The available touchsensitive boards are designed for presentation tasks and thus not suitable for horizontal use. Within a normal interaction, for example during drawing or sketching, the persons frequently touch the sensitive surface at several places. Placing the hand on the pad during the writing or sketching will cause digitalization errors. This problem was recognized very fast by the tested persons. However, the above described mistake occurred again and again. The reason for this is that the required single-point input for the touch-sensitive board is not corresponding to the natural movement of the human being. The unnatural way the write or to sketch on a horizontal surface results in a cramp and in fast exhaustion. Combined with that is a clear reduction of the efficiency of a group [1]. Another difference between a teamwork and a presentation is that the teamwork uses other techniques than a presentation, for example it is not moderated. Thus, it is possible that several members of a team can draw simultaneously. However, a synchronous recording of several pen positions is not supported by the technology of the touch-sensitive boards. Therefore the touch-sensitive boards cannot be used for such a teamwork. In conclusion the available technology does not support the work of subgroups very well. However, the available technology basically supports the presentation but not the creative generation of ideas.

6.8 Taking a protocol

To guarantee the success of a carried out session it is necessary that a protocol is taken. Taking the protocol of a conventional session is difficult, since the elaborated documents are not suitable to be taken into a protocol without any modification. Large scale documents like posters have to be reformatted or post-processed in order to make them suitable for the protocol. Very frequently important context information is lost and a later reworking of a session becomes complicated. In addition the preparation of such posters is time-consuming and cost-intensive. In part important posters are linked into a protocol as a photograph. In order to keep the document size small for an electronic forwarding the pictures are embedded with low resolution which complicates the later on use. The carried out series of experiments showed that the possibility of the immediate printout of the posters is regarded as very useful. These printouts can be full-scale by the use of a plotter or they can be scaled down in order to realize smaller formats for a printer. In part the digital data which were created in the plenum could be taken over directly into the protocol. An essential advantage of the digitizing by the touch-sensitive boards consists in archiving and reworking. All written or sketched inputs are in a digital form and can be distributed for example to the team members as a handout. The digitized data can be used in future sessions, either with the functionality of the touch-sensitive board itself or with a bitmap processing program. All the required tasks could be done by the tested persons very easily and result in a higher effectiveness of the carried out sessions.

Conclusions

The different situations of a teamwork were examined, both the work in the plenum as well as the work in smaller teams. The carried out investigations made clear that the technology of the conference room cannot be used completely without further knowledge on the system.

ICED 01 -C586/040

431

Although the intuitive writing or sketching on the touch-sensitive boards is possible after a short training phase the further use of these elaborations as well as the usage of the peripheral units only can be done by a trained presenter. The technology-based conference room does not support all conventional working methods. Thus, in many cases the conventional methods are still needed. Using such a conventional method causes a break of the technological chain. In particular in the presentation technique, in the elaboration of common posters and in taking the minutes the new technology is very helpful. On the other hand other techniques as for example the metaplan technique or the teamwork cannot be supported very well by the new technology. The currently available components only can be used in particular fields. However, they do not offer yet a comprehensive solution for the realization of a complete meeting.

Future work

Future work will aim at eliminating the recognized problems. This will be in particular the realization metaplan technique as well as the realization of an teamwork supported by new information technologies. A continuous technological chain over an entire teamsession is supposed to be achieved. On the one hand this can be done by better software- and hardware and also in the networking of existing components. On the other hand the construction of new interaction devices and procedures have to be realized. In order to keep on optimizing the moderation technique the writing and sketching on the two touch-sensitive boards must be exchanged between the two projection screens as desired. This will realized by extending the currently used software.

Acknowledgements

The above project was funded by the Swiss research fund KTI 4475. 1PMS. We thank in particular the IfAP (Institute for Work and Organization Psychology) and the HGKZ (University of Art and Design Zurich). References [1] Ernesto Arias, Hal Eden, Gerhard Fischer, Andrew Gorman, Eric Scharff; ,,Creating Shared Understanding through Collaborative Deisgn"; University of Colorado, Boulder; CHI-Proceedings Thomas P. Moran, Patrick Chiu, William van Melle, Gordon Kurtenbach; Jmplicit Structures for Pen-Based Systems Within a Freeform Interaction Paradigm"; Proceedings og CHI 1995 Jason A. Brotherton, lanak R. Bhalodia, Gregory D. Abowd; ,,Automated Capture, Integration, and Visualization of Multiple Media Streams"; Proceedings IEEE 1998 Peter Troxler, Kristina Lauche, Kyeni Mbiti; ,,The Use of Interactive Boards for Collective Design Processes"; International Design Conference, May 23.-26, 2000 Orfeo Niedermann; ,,Nutzenanalyse des Einsatzes der Virtual Reality Technologie in der Failure Mode and Effect Analysis"; ETH Internal Research Report 1999

[2]

[3] [4] [5]

IMechE 2001

432

ICED 01 - C586/040

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

THE IMPORTANCE OF INFORMAL NETWORKS TO EFFECTIVE DESIGN MANAGEMENT

N J Brookes, P Smart, and F Lettice keywords: design management, design teams, human resources, concurrent engineering

1 Introduction
"Well, does it really matter how you organise the company or what the functions are or what the organisation inside the functions are? ....A (product development) project or a set of projects are nothing more than conversations and relationships with people. How you have those conversations and how you deal with people enables them to push limits." Project Director - New Product Development, interview transcript from the 'Working the Boundaries' project The aim of this paper is to present the work of the 'Working the Boundaries' project and the way in which this work has highlighted the importance of informal networks of organisational relationships in design management. The 'Working the Boundaries' project was an eighteen month project funded by the Engineering and Physical Sciences Research Council and based in the Wolfson School of Mechanical and Manufacturing Engineering in Loughborough University in the United Kingdom.

2 Background to the 'Working the Boundaries' Project

Much of the recent work on improving design management has focused on developing the formal organization. Researchers and practitioners have concentrated on changing formal organizational structures often to make them more project-focused and have introduced formal processes and procedures for developing new products. This is especially evident in the work of the International Motor Vehicle Program and its related projects [1],[2],[3],[4] and structurally based approaches to concurrent engineering [5],[6],[7],[8]. Although significant individual project success has been reported through the adoption of these methods, problems related to total system performance have also been reported [9],[10],[11]. These focus on the following: the 'functional rump' - product development activities that are difficult to place in projects either because of low volume or scarcity of resources to perform them. organizational learning issues - functional specialists allocated into project teams may gradually lose the distinguishing features that initially made them so desirable.

One response to these undesirable sides affects may be to further change the formal organization but, given the changing external and internal environment this may be an impossible task. Furthermore, research by Henderson [12] at the Sloan Management School, Massachusetts Institute of Technology has indicated that an 'optimal' form is not even

ICED01-C586/272

433

necessary. She has shown in the pharmaceutical industry that the formal organization was not the prime determinant of product development success. Instead she identified that the companies who sought to overcome formal boundaries wherever they were positioned were better at developing products successfully. This immediately begs the question of what mechanism can be used to overcome formal organizational boundaries and whether it can be harnessed in some way to improve the way design is managed and hence assist in improving product development performance. A feasibility study based at Loughborough University , the 'Working the Boundaries' Project, set out to answer this question. In order to do this, the project team made much use of the concept of 'informal organizational networks.' The phenomenon of informal networks within organisations has been widely recognised for some time [13],[14],[15],[16]. Some work has been undertaken to characterise these networks. For example Boutty [17] has identified how different types of relationship share R&D information across organisations. However the role of informal networks in design management remains largely unexplored and no-one has yet addressed the issue of whether these networks can be enhanced to improve the effectiveness of the design process.

3 Research Methodology
The objectives of the 'Working the Boundaries project were: To investigate to see if Henderson's work held true in a different industrial environment i.e. to establish if other organisational factors than formal structure had an impact on successful design management If formal structure was not of prime importance, to identify what organisational phenomena was associated with 'working the boundaries' to result in product development success

The research was highly exploratory in nature. The research team therefore determined that an 'in-depth' qualitative approach was required. To this end, it contacted a major UK automotive design and manufacturer who agreed to act as a case-study subject for the 'Working the Boundaries' project's investigations. The project sought to undertake a longitudinal analysis of twenty years of small and medium-sized automobile product development in case-study company. Using a time-line approach, it aimed to map the major product introductions and the performance of those product introductions. It also aimed to map, on the same time-line, the changes in formal organisational structure during that period and to characterize the changes in overall approach to design management that was experienced during this period. Using this data, the project proposed that tentative links could be developed between the performance of design managment and organisational characteristics present at that time. Because the research team were highly uncertain as to what they might find when undertaking the longitudinal analysis, the following staged research process was adopted:-

434

ICED 01 -C5 86/272

Figure 1 The Research Process for the 'Working the Boundaries' Project

The study obtained its data from project and programme manger and project directors. It used a variety of data collection mechanisms: semi-structured questionnaires non-directive interviews (whose transcripts were then thematically analysed) supporting documentary evidence.

Carrying out the research process in a series of stages proved invaluable. Two particular problems were encountered in generating a time-line for the case-study:Measuring the success of design management The research team began by trying to find objectively reported quantitative data on the performance of design and development projects. This proved difficult for the following reasons: data was never recorded in the first place historic data that was available was held in legacy systems ( sometimes as crude as people's individual filing cabinets) which were difficult to access data often had different datums which made comparisons difficult.

These results were not surprising and were similar to experience in a previous research study [18]. The team determined to measure the success of a particular design project by asking individuals concerned with a particular project to rate it from 1-5 (where 1 represented minimum performance and 5 a maximum level of performance) against the following criteria: design and development costs the quality of the product designed the lead-time for design and development

There are obvious problems with measuring a design and development project in these ways. The ratings used by the project were subjective. A tendency may also exist for an individual to 'mark up' a project in which she or he was concerned. Given the alternative (i.e. not trying to measure at all,) the team decided to proceed with this imperfect measurement of design activity.

ICED01-C586/272

435

Matching structure to project. The second difficulty encountered was matching a formal structure with a particular design and development project. The formal structure was never stable. In between significant step changes it was undergoing a process of constant 'tweaking'. Formal changes to structure were made whilst a project was underway so some projects found themselves operating, over time, with completely different organizational structure. The research team only mapped significant step changes in organisational structure associated with significant resource re-allocations.

4 Research Findings
A simplified time-line for product introductions during the past twenty years is given in Figure 2. Three types of formal organization were used throughout this period. The first was a 'functional' organisation, where separate engineering disciplines were oganised in isolation. The second type of structure was a 'project' structure where virtually all engineering resources were allocated to a particular project and reported to a project director. The final type of formal organizational structure adopted was a 'lightweight' approach where a project grouping of primarily commercial and some limited engineering resource was maintained but the vast majority of engineering resource was organised functionally. When looking at the organisational success of these different structures, a first glance may suggest that a formal project structure was most successful. However this viewpoint must be tempered with the thematic analysis of the interviews undertaken. These indicated that the success of the

Figure 2 Simplified Time-line for New Product Introductions

'project' structure was not due to its inherent characteristics but because it promoted informality and allowed the interviewees to use the informal networks to achieve tasks. The following quotation illustrates this:"Networking, very important. I mean that's how project teams ... that's how the whole company works. It doesn 't matter what the formal organisation is, within reason, we all have to get the job

436

ICED 01 - C5 86/272

done. So long as you know who can help, and do things, via the old network scheme, you can get the right guy on the phone and you talk to him, explain, which is why project teams, I think are better, because they give you that freedom and everybody has that responsibility. So you're all working for a common aim and we're moving forward. "

This suggests that the period of success during the 'project' formal structure was due to flourishing informal networks. The following quotation illustrates how informal networks could be used to improve performance:"If there's a problem, say it's a body problem, and you know this problem, there's probably two ways of getting the problem sorted out. Maybe it's a very big problem the body falls apart after 1000 miles or something. Then using the formal organisation structure you 'd contact the head of this department and he would contact his junior who 'd contact the guy who does the work and then he 'd prepare a report for him and he 'd prepare a report for him and he'd give the information back to you.. The way Chinese whispers work....it means, you know, that you've lost something. You lose the problem definition, you don't quite get the answer to the question that you wanted to ask. You 've got to know that man. If you know him, you can ask him that question. You can have a much broader conversation than saying I've got a problem, please fix it. You can understand why is the problem there ? He understands why you are concerned about it "

Using the thematic analysis of the interviews, it was possible to characterize the informal networks that were designing and developing new products. (See Table 1). It is important to remember that the interviews were non-directive (i.e. they were not specifically asked about the themes outlined). Table 1: Thematic Analysis of Interviews

The informal organisation is important to successful product development

of interviewees stressed the importance of the informal organisation to successful product development 33% said the formal structure had little impact on project performance 80% stated that a network of productive relationships were needed for product development success

The informal organisation is formed form relationships Informal networks last

60% recognised the longevity of relationships over several projects 40% highlighted the importance of trust to productive relationships 33% highlighted the importance of common experience (e.g. similar educational background, similar career history) 25% highlighted the importance of social context (i.e. the relationship is not solely work-based) 15% highlighted the importance of respect

Productive relationships need trust, common experience a social context and respect

ICED 01 - C586/272

437

If the findings of the 'Working the Boundaries project are viewed in the conjunction with Henderson's work, it is the informal network of relationships that overcomes the boundaries of formal structure. Individuals use informal networks to obtain and disseminate information and to re-allocate design and development activities.

5 Conclusions and Further Work

In drawing conclusions from the 'Working the Boundaries' project, there is an obvious need for circumspection. The results were case-study based which immediately limits their wider applicability and the research methods adopted were, of necessity, subject to simplification. In spite of these limitations, the 'Working the Boundaries project' fulfilled its aims within its research boundaries. It identified that other organisational phenomena than formal structure were associated with successful product introduction. It identified these as informal networks of relationships. The conclusions of the 'Working the Boundaries' project can be summarised in the following statement of speculative theory: Successful introduction of new products is associated with using the informal organisation The informal organisation is a network of relationships initiated by an individual that reallocates tasks and re-directs information These informal relationships are strengthened by trust, common experiences, a social context and, to a lesser degree, respect. These informal relationships are long lasting and survive may changes in the formal organisational structure

The implications of this speculative theory are immense. They suggest that successfully managing design may be much less about formal 'managing' (in terms of directing information flows, allocating tasks and identifying formal structure) and much more about 'letting go.' Managing design successfully may mean providing individuals with the skills and opportunities to enhance their own networks of relationships and allowing individuals to use their own networks. Further work is needed to confirm the findings of the 'Working the Boundaries' project on a much wider scale. This needs to not only to investigate other design and development projects in the pharmaceutical and automotive sectors but also to widen the industrial sectors involved in research Given the potential cultural sensitivity of informal networks, it would also be extremely interesting to investigate if similar findings were establishes in other cultures. Further work is also needed to embed the theory developed by the project into a management tool. This would enable organizations to assist individuals in developing and enhancing their own personal networks during the design process.

438

ICED 01 - C586/272

References [1] Clark KB and Fujimoto T, "Product Development Performance:Strategy . Organization and management in the world auto industry". HBS, Boston Mass, 1991. [2] Wheelwright, S.C., Clark, K.B.. Revolutionizing Product Development: Quantum Leaps in Speed. Efficiency and Quality, 1992, (Free Press, NY) [3] Kusiak A Wang J "Efficient Organizing of Design Activities." International Journal of Production Research v31 pp 753-769, 1993 [4] Eppinger AD, Whitney DE Smith RP Gebula D "A Model -base Method for Organizing Tasks in Product Development" Research in Engineering Design v6 nl ppl-13 1994 [5] Backhouse C J, Brookes N J, Concurrent Engineering: What's working where. Design Council/Gower, 1996 [6] Shina S G (ed). Successful implementation of Concurrent Engineering products and processes. New York: Van Nostrand Reinhold 1994. [7] Shenas D G and S Derakhshan. Organisational approaches to the implementation of Simultaneous Engineering. International Journal of Operations and Production Management, Vol 14, No 10, 30-43 1994. [8] Lettice F E. Concurrent Engineering: A team-based approach to rapid implementation. PhD Thesis. The CIM Institute, School of Industrial and Manufacturing Science, Cranfield University, UK 1995. [9] Francia, A, Macintosh, The Market, technological and industry context of business process re-engineering in the U.K. International Journal of Operations and Production Management, v17 n4 pp344-364 1997, [10] Sobek DK, Liker JK and Ward AC, Another Look at How Toyota Integrates Product Development, Harvard Business Review, July-August 1998 [11] Cusumano MA and Nobeka K Thinking Beyond Lean: How Multi-project Management is Transforming Product Development at Toyota and Other Companies. The Free Press. , 1998, [12] Henderson R, Managing Information in the Information Age Harvard Business Review Jan 1994 Reprint no: 94105 [13] Nohria N and Eccles RG Networks and Organizations: Structure. Form and Action. Harvard Business School Press, 1992. [14] Mintzberg H. van Heyden L. "Organigraphs: Drawing how companies really work". v77 n5 Sept-Oct, pp87-94, 1999 [15] Krackhardt D. and Hanson J.R. Informal Networks: The Company Behind the Chart. Harvard Business review July-August 1993 pp104-lll [16] Wenger EC, Snyder WM Communities of Practice: The organisational frontier Harvard Business Review Januray February 2000

ICED 01-C586/272

439

[17] Boutty I, Interpersonal and Interaction Influences on Informal Resource Exchanges Between R7D Researchers Across Organisational Boundaries. Academy of Management Journal, v43, nl, pp50-65, 2000 [18] Brookes, N.J. Backhouse, C.J., "Measuring the Performance of Product Introduction", Proceedings of the I.Mech.E. Part B Journal of Engineering Manufacture 212(B1), 1998, pp 1-11, ISSN 0954 4054.

Corresponding Author's Details: Naomi Brookes PhD DIC Lecturer - Wolfson School of Mechanical and Manufacturing Engineering Loughborough University Loughborough Leics LE11 3TU United Kingdom Tel: +44 (0)1509 227668 Email: n.j.brookes@lboro.ac.uk IMechE2001

440

ICED 01 - C5 86/272

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

MANAGING UNCERTAINTY IN DESIGN COMMUNICATION

M K Stacey and C M Eckert

Keywords: Ambiguity, uncertainty, design information management, collaborative design tools, computer supported cooperative work.

design

teams,

Introduction

The design of complex engineering products involves communicating design ideas and specifications - requirements, constraints, functions, parameters, behaviours, structures and components. These ideas are often exchanged when still tentative, imprecise and incomplete; moreover the forms in which they are expressed can be imprecise and ambiguous. In conversations, sketches, gestures and words are used in combination to disambiguate each other, and designers convey their degree of commitment to ideas by modulating phrasing and tone of voice [1]. But in large-scale design processes, the different elements of designs also need to travel through space and time, to places where misunderstandings can have severe consequences. How can engineers separated by space and time avoid misunderstandings and make effective use of the uncertainty and provisionality inherent in design idea development?

Uncertainty in design communication

In any team designing activity designers need to express ideas for parts of the design that are provisional, imprecise or incomplete. This is obviously true for early conceptual design. Early in the design process designers expect that some information is provisional and may question the status of parameter values and other decisions. But designers have to deal with uncertain information and provisional proposals at all stages in the design process. This provisionality and imprecision is usually apparent to the participants in meetings where ideas are put forward, though there is plenty of scope for misunderstandings. But coping with uncertainty is more problematic in the interactions between separate tasks and activities dealing with related aspects of the design, especially where information is exchanged primarily through diagrams, drawings, CAD models or written specifications. The difficulty of coordinating complex design processes is a limiting factor on the effective use of provisional and uncertain information. In the design of complex products, designers need to made decisions when they cannot assess their consequences; and the designers responsible for mutually dependent aspects of the design need to influence each other's designing to be sure of finding shared parameter values that work for both parts of the design. This requires working with and passing on provisional and incomplete design decisions [2, 3]. But commonly some tasks and parameters are given priority, to give the design process a manageable linear structure, at the cost of harder tasks and suboptimal designs later on. Sometimes more-or-less arbitrary choices are treated as fixed and firm at later stages in the process; other values and decisions are set provisionally while others are left open.

ICED 01 - C586/516

441

In engineering design, conversations are almost always centred round some external representation of the design, such as sketches, drawings, CAD models and prototypes. Moreover, communication between design activities is largely through artefacts such as CAD models, drawings and specifications; they often convey information between designers with different expertise and sets of concepts for thinking about designs, who read them in different ways [see 4]. Often these representations are ill suited to expressing imprecise and provisional information. Many companies feel that once the entire organisation uses CAD models to design and communicate all their problems will be solved, but contemporary CAD systems require precise values, and do not support imprecision or other uncertainty information [but see 5], so that provisional decisions or placeholders look firm.

2.1 Communicating uncertainty in joint designing

Joint designing in meetings is important in most design processes, especially for early conceptual design, where design ideas are typically vague, provisional, imprecise and incomplete. In design conversations sketches, gestures and words are used in combination to explicate and disambiguate each other [6, 7, 8, 9]. The participants in joint designing usually get rapid feedback on whether they have been understood (though clarification is a major activity within meetings). So they can interactively negotiate an understanding of each other's positions, as well as negotiate about decisions, before the (provisional or imprecise) decisions are represented in precise-seeming forms [8]. Designers use rhetorical techniques for argumentation, including subtleties of phrasing and tone, to modulate the degree of belief they express in ideas, and signal willingness to make trade-offs, as well as to express exactitude [8, 1]. However there is no guarantee that all the participants will always pick up these signals.

2.2 Communicating uncertainty between design activities

The need to handle imprecision and provisionality is not restricted to designing individual aspects of the design, or to meetings between designers. In the design of complex products, many design activities make decisions that impinge on activities carried out elsewhere, or later. Resolving conflicts between different aspects of a design is often an important activity. Designers who receive messages and specifications and interpret graphic representations need to know both how far they can rely on what they are given and how far they can change it. The senders need to ensure that further development of the design is not incompatible with what they have done [see 10]. Design handover situations still exist in many industries. Even if a handover is accompanied by a meeting, the recipients usually get little or no indication about what aspects of the design are fixed and essential and which are mutable; and they may only become aware of problems once they are working on their own. They thus have much less scope for interactively negotiating a common understanding of the situation with their colleagues, and so depend much more on clear and complete design specifications. As products become more complex their development becomes more multidisciplinary and increasingly more international. Despite the best efforts of groupware system developers, joint designing in virtual meetings across different locations remains cumbersome, and is hard to make work across cultural, time and language barriers.

2.3 Uncertainty and ambiguity in graphical representations

Ambiguity is created by the availability of alternative referents for words, symbols, and symbolic or deictic gestures [see 9 for examples]. What referents are available depends on the interpreter's understanding of languages and notational conventions, as well as of the design

442

ICED 01-C586/516

situation [see 4]. But the role of prior context in design communication goes beyond the need for the recipient to recognise graphic codes and ascribe the intended referents to words and symbols. Representations of designs are abstractions in which aspects of the design are not fully specified. Understanding how much of what is not shown is fixed, and what can be varied, is as essential as understanding the explicit content of a representation. Alternative interpretations of the omitted elements of a design are made possible by uncertainty or misunderstanding about the interpretive conventions to be applied to a representation, as well as the context in which it is embedded and the assumptions the generator makes about how the gaps will be filled in. Thus it can be ambiguous by omission. In other words, what is implicit in any representation depends on the interpretive skills of the recipient and the extent of the shared understanding of context established between the sender and the recipient. Roughness in sketches expresses lack of certainty, but the viewers often can't distinguish between intended imprecision and poor drawing, or between a qualitative placeholder and a relatively exact depiction, or between a simple form drawn roughly and a more subtle form drawn more accurately [10, 11]. One sketch or drawing often stands for a whole space of possible designs, but the viewer and the creator cannot know whether they interpret this space in the same way. As we have found in the case of knitwear designers' garment specifications [11, 12], the generation of sketches and other forms of external descriptions that constitute accurate and unbiased representations of the generator's understanding of a design is problematic: people don't mean exactly what they draw. Idiosyncrasies and poor drawing in their sketches and diagrams bias interpretation by others towards different central meanings as well as different judgements of imprecision and provisionality. While the reasons for decisions are usually apparent to the participants in joint designing activities, they can be opaque to other readers of design representations. Understanding the reasons for decisions is often essential for interpreting the uncertainty of design information, as well as for interpreting omissions. Methodologies and computer systems for process management place increasing importance on recording the rationales for decisions, as part of managing the provision of contextual information. Some earlier discussions of imprecision, uncertainty and ambiguity in design communication [8, 1] lump all these together under 'ambiguity'. This is confusing, and promotes the currently influential view that ambiguity (more narrowly defined as the availability of more than one qualitatively distinct interpretation) is beneficial in design communication, and that aiming to use computer tools to create unambiguous descriptions of designs is a discredited enterprise; this we doubt [10]. However Minneman argues that designers sometimes do exploit ambiguity. Nonetheless joint designing is very different from communication between activities; handing over ambiguous representations can cause severe problems [11, 12].

2.4 Allowing for uncertainty in design planning

One of the great challenges of design management is to find the right time to start a task. If one waits until all the information is available the process can become rather drawn out. Starting a task too early with insufficient information can lead to later reworking, which in turn can lead to delays in the design process. Many tasks are mutually dependent, because different aspects of the design influence and depend on the same parameters. Design managers can use methods such as Design Structure Matrices [13] to identify the information dependencies between tasks and find the shortest design process requiring a minimum amount of provisional information. Design Structure Matrices also make it possible to identify clusters of mutually dependent tasks, where each task needs the result of the other as inputs.

ICED01-C586/516

443

These clusters can only be broken by using parameter estimates and repeating tasks to converge to compatible parameter values in a tightly integrated design process [2, 3]. Planning design processes to use uncertain information has three conflicting goals: to minimise development time; to minimise the risk of starting tasks with provisional information; and to exploit provisionality and imprecision in solutions to underconstrained problems in optimising other aspects of the design. To meet these objectives designers need to identify those tasks that can be undertaken with provisional information (for example it would not make sense to start finite element analysis with estimates). They need suitable ways to estimate parameter values. And they need to find ways to communicate which decisions and parameter values are fixed and which are provisional, and how far they can be modified.

A typology of forms of uncertainty in design

Greater conceptual clarity about the different forms of uncertainty is needed both for understanding human design behaviour, and for planning and managing design processes to achieve better coordination between design activities. The following concepts are conceptually distinct and potentially useful for interpreting what design actions are compatible with the current state of the design. This typology is discussed with more careful attention to the conceptual status of the different uncertainty concepts in [10]. Precision. How exactly the aspect of the design is specified. (Does x=10 mean 9.998<x<10.002 or 8<x<12?) Less quantitatively, how far the details of the representation are meant exactly or as placeholders for qualitative values or more abstract categories. Typicality. The extent to which the aspect of the design is typical of the range of possible acceptable choices, or shows a central value in a quantitative range. (A sketch or diagram often represents an entire space of possible designs by showing a relatively concrete typical design. The interpretation of what is a typical case varies between individuals.) Commitment (the opposite of provisionality). The degree to which the project is committed to keeping this aspect of the design the way it is (and conversely, how easily it can be changed to meet other needs). Representations of designs such as sketches often include elements embodying provisional decisions (or even non-decisions) to provide a context for other elements with a greater degree of commitment. Sensitivity. How far the aspect of the design can be changed without significantly affecting the rest of the design. (Analyses of sensitivity include the consequences of changing it more than that.) Input Confidence. The degree to which the inputs and assumptions on which the aspect of the design was based are stable and reliable. Understanding. The extent to which the user has sufficient information and expertise to decide the form of this aspect of the design from the input information. Hence, the degree to which an aspect of the design can be relied as being satisfactory in relation to the parameter values and constraints from which it was generated. Confidence. The degree to which an aspect of the design can be relied on as satisfactory. (The product of Input Confidence and Understanding.)

444

ICED 01-C586/516

These aspects of uncertainty are signalled (or not) in the communicative objects and messages (including gestures as well as the intonation of speech) designers use to communicate their ideas. However designers' perception and phenomenological experience of uncertainty is certainly often more wholistic and conceptually messier, for instance in the modulation of subjective degree of belief (confidence x commitment?) [see 1]. What uncertainty information engineers and other designers can, in practice, both use and pass on is a significant open research question. Clarkson et al. [2] argue from extensive experience of industrial engineering design that engineers are content with classifying values as initial estimates, feasible estimates, and final values. Failure to interpret any of these uncertainty factors correctly causes misunderstanding of the scope for further designing. Similarly, uncertainty about these factors (as well as about what the values of parameters or other choices are) causes doubt about how to proceed with a design. This is the consequence of vagueness. Ambiguity in design communication is the availability of interpretations as qualitatively different alternative models, either for individuals, or for those different people with different knowledge and interpretive skills whose interpretations are relevant to the task or situation.

Managing uncertainty in design

The transmission of uncertain information between design tasks is needed for three purposes: to break mutual dependency clusters; to enable naturally sequential tasks to be carried out partly in parallel; and to avoid premature closure of design decisions resulting from imposing a linear sequence on tasks that could achieve better results if treated as interdependent. In all these situations all team members must understand in which way information is uncertain, and what is the likelihood and scope of possible variation. To do this managing uncertainty must be treated as an integral part of managing information flow through a design process. Supporting informal channels. Many studies of complex organisations have found that informal communication channels are vitally important and often poorly understood [for instance 14]. Communication between the people who need to exchange information should be easy and efficient, but is often blocked by the social organisation of the design process [see 15]. When a design process is restructured, for example when parts of it are sub-contracted, it essential to identify the information that flows through informal contacts to ensure that it is not cut off. Meta-information about uncertainty that is never formally recorded is sometimes an important part of this. Understanding task dependencies. Understanding how different aspects of the design are mutually dependent, and what design activities can and cannot achieve with imprecise or provisional information, is an essential first step towards planning the interactions between design activities that are needed for achieving an effective sequence of tasks. This includes making decisions about the priorities of parameters, and providing for the exchange of provisional information between activities so that they can converge iteratively to a compatible design. Assembling negotiation groups. This leads to the question of who needs to be involved in a design activity to ensure that all the relevant issues are considered, and how the designers responsible for one task should interact with their colleagues who are affected by their decisions. Therefore it is important to establish who needs to meet for rapid negotiation and informal briefing; and who needs to be provided with meta-information by message passing or annotation. An answer to this question needs to be cost-effective

ICED 01 - C586/516

445

both globally, in that increasing opportunities for debate and change increases quality without adversely affecting lead times, and locally, in that the communication of uncertainty information by individuals must not impose a burden on designers that is onerous or not clearly justified. Endless meetings often take up a lot of the designers' time and stop them from working productively on their own. Composition of design teams. How team members interpret information depends on their background and experience. The more diverse they are the more likely they are to bring new ideas and insights into the process, but the less likely they are to understand ambiguous information in the intended way or know how widely to interpret uncertain information. Members of task teams who understand connected tasks can anticipate and judge the exactness and commitment of the other tasks' outputs. Assessing the power of design representations. Designers and their managers must be aware of what can be expressed in a certain design representation, and how different people will read it. All representations make some aspects salient and obscure others. Assessing the role of the design representations. Representations of designs serve to structure the design process [4], sometimes in ways that their creators are only partly conscious of, for example when faults in specifications are used deliberately to force face to face communication [12]. Understanding how involvement with the design is organised around CAD models and other information artefacts will help understanding how uncertainty information is used. Coordinating understanding. Designers with different expertise and awareness of context will read sketches and representations of designs differently. They are likely to interpret gaps in incomplete descriptions and indications of provisionality and imprecision differently. However this can be alleviated by coordinating understanding, not just by negotiating over individual designs, but by developing a vocabulary of terms with agreed compatible interpretations (for instance, of signals for imprecision and provisionality). Supporting asynchronous negotiation through the transmission of meta-information. When designers need to create models and records, and communicate asynchronously, they should be able to indicate degrees of uncertainty by annotating diagrams and models. However this annotation needs to be quick and easy enough to be cost-effective.

Computer systems for communicating uncertainty clearly

Computer support for communication in design has concentrated largely on facilitating remote real time communication, thus supporting handling uncertainty indirectly by enabling the use of speech, gestures and sketching, with rapid feedback, in situation that otherwise would be dealt with by telephone or by sending messages. But computer systems can also enhance the effectiveness of message passing and communicating through designs. Nevertheless the human designers still need to make sure that their colleagues can understand the degree and type of uncertainty they wish to communicate. Increasing the bandwidth of asynchronous message passing. One strand of research aims to use remote meeting technology for sending messages using the full resources of face-to-face conversation (sketching, gesturing and referring to objects in the environment, as well as tones of voice signalling degree of belief) [16].

446

ICED 01 - C586/516

Removing the uncertainty from the representation. In some situations communication could be enhanced by enabling designers to create more exact or detailed design information cost-effectively, or by solving technical problems for them [see 12]. Systems that generate designs from user specifications, or guided by user selection, can produce designs that are technically correct and certain at a certain level of abstraction. We discuss elsewhere the role of generative systems in design creativity and communication, arguing that automatic design systems can facilitate creative designing and can fit naturally into some commercial design processes [17]. We present a technological solution to some of the communication problems in knitwear design caused by ambiguity and conflicting indicators of uncertainty: a garment shape design system that uses mathematical models and heuristic reasoning to construct shapes from designers' customary descriptions, incomplete (and often incorrect and inconsistent) sets of parameters [17]. Annotating design information. An agreed vocabulary of uncertainty indicators, and quick and easy methods for adding annotations to CAD models and other representations would make indicating appropriate degrees of uncertainty substantially easier, and hence more likely to prove cost-effective in practice. Planning interactions between tasks. We are developing Signposting systems to support design planning that break task dependency loops and coordinate interdependent activities by exploiting estimated and preliminary parameter values. The first systems use confidence as a qualifier on parameter values ('preliminary estimate', 'good estimate', 'final'), to determine the earliest time that a task can be started [2]. We are currently exploring how a much wider range of uncertainty information might be used to guide task planning and task selection in further Signposting systems [3].

Acknowledgements This research was supported by the EPSRC rolling grant to the Cambridge Engineering Design Centre, and by GKN Westland Helicopters Ltd and Lotus Engineering Ltd. We are grateful to our informants for the time and trouble they took talking to us. References [1] Brereton, M.F, Cannon, D.M., Mabogunje, A. and Leifer, L., "Collaboration in Design Teams: Mediating Design Progress through Social Interaction", in N.G. Cross, H.H.C.M. Christiaans and K. Dorst, (eds.), Analysing Design Activity, John Wiley, Chichester, UK, 1996, pp. 319-341. Clarkson, P.J. and Hamilton, J.R., "'Signposting', A Parameter-driven Task-based Model of the Design Process", Research in Engineering Design. Vol. 12, pp. 18-38, 2000. Stacey, M.K., Clarkson, P.J. and Eckert, C.M., "Signposting: an AI approach to supporting human decision making in design", Proceedings of the ASME 20th Computers and Information in Engineering Conference, University of Maryland, Baltimore, USA, 2000. Henderson, K., "On line and on paper", MIT Press, Cambridge, MA, 1999.

[2]

[3]

[4]

ICED 01 - C586/516

447

[5]

Guan, X. and MacCallum, K.J., "Adopting a minimum commitment principle for computer-aided geometric design systems", in J.S. Gero and F. Sudweeks (eds.), Artificial Intelligence in Design '96. Kluwer, Dordrecht, Holland, 1996, pp. 623-639. Bly, S.A. "A Use of Drawing Surfaces in Different Collaborative Settings" another line for this. Tang, J.C., "Listing, Drawing and Gesturing in Design: A Study of the Use of Shared Workspaces by Design Teams", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1989. Xerox PARC report SSL-89-3. Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies of Group Engineering Design Practice", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1991. Xerox PARC report SSL-91-22. Neilson, I. and Lee, J. "Conversations with graphics: implications for the design of natural language/graphics interfaces", International Journal of Human-Computer Studies. Vol. 40, pp. 509-541, 1994. C.M., "Against Ambiguity", Computer Supported

[6] [7]

[8]

[9]

[10] Stacey, M.K. and Eckert, Cooperative Work, in press.

[11] Stacey, M.K., Eckert, C.M. and McFadzean, J., "Sketch Interpretation in Design Communication", Proceedings of ICED'99. Technical University of Munich, Munich, Germany, Vol. 2, pp. 923-928, 1999. [12] Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis and Computing Solutions", Computer Supported Cooperative Work. 2001. [13] Eppinger S.D., Whitney, D.E., Smith, R.P. Smith and Gebala, D.A., "A Model-Based Method for Organizing Tasks in Product Development", Research in Engineering Design. Vol. 6, pp. 1-13, 1994. [14] Medland, A.J., "Forms of Communications Observed During the Study of Design Activities in Industry", Journal of Engineering Design, Vol. 5, pp. 243-253, 1992. [15] Eckert, C.M., Clarkson, P.J. and Stacey, M.K., "Information Flow in Engineering Companies: Problems and their Causes", Proceedings of ICED'0l. PEP, Glasgow, UK, 2001. [16] Minneman, S.L. and Harrison, S.R., "The DrawStream Station: a tool for distributed and asynchronous chats about sketches and artifacts", Proceedings of HCI'99, Munich, Germany, 1999. [17] Eckert, C.M., Kelly, I. and Stacey, M.K., "Generative systems for interactive design: an empirical approach", Artificial Intelligence in Engineering Design, Analysis and Manufacturing, Vol. 13, pp. 303-320, 1999. Martin Stacey Department of Computer and Information Sciences De Montfort University Milton Keynes MK7 6HP, UK Phone: +44 1908 834936 Fax: +44 1908 834948 mstacey@dmu.ac.uk www.mk.dmu.ac.uk/~mstacey IMechE 2001 Claudia Eckert Engineering Design Centre Department of Engineering University of Cambridge Cambridge CB2 1PZ, UK Phone: +44 1223 332758 Fax: +44 1223 332662 cme26@eng.cam.ac.uk www.eng.cam.ac.uk/~cme26

448

ICED 01 - C586/516

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

MANAGING THE INTEGRATION BETWEEN DESIGN, RESEARCH, AND PRODUCTION IN THE AUTOMOBILE INDUSTRY
H V de Medina and R M Navciro Keywords: design management, product planning, design integration, design teams

Introduction:

The way companies design products is widely recognized as crucial to their success. The companies are being challenged to achieve an integrated environment to develop their products and are acquainted that their success is strongly dependent on their ability to organize, to process and to learn from information that is related to the product development cycle. In fact the development of a new product is nowadays part of a global system of innovation that actually supports the ongoing industrial restructuring for the years 2000's. An integrated strategy for technical, social and cultural change inside the companies is promoting a revolution from the shop floor to the R&D bureau, based on new forms of designing management and work organization. The automobile industry has faced a complete restructuring process in recent years. Carmakers have merged forming conglomerates, R&D has been shared between car manufactures' and suppliers, and so the automobile has been reinvented, as it embodies an invisible set of innovations in materials, sensors, control devices, etc. At the production level, things have followed the same way. Companies are increasing third party work and reducing the supplier base, as well as enlarging the role of the first rank suppliers in the design of new products. Furthermore, partnerships between suppliers and carmakers are established since the launching of a new project, sharing part of the R&D costs and profits. In a global level, the strategies adopted by North American and European companies, for keeping and sustaining their market share, were focused on technical and organizational innovations, specially concerning the reduction of the time lag between conception and commercialization of new models. A wider range of options among standard cars and a great effort on improving the quality and reducing environmental impacts were the main goals. These objectives were reached by integrating research, design, and production as parts of different fields of knowledge, in a multidisciplinary system represented by the dissemination of simultaneous engineering methods for the whole company. By doing so the distance between research and production has been drastically reduced, avoiding back and forth efforts that usually take a lot of time and money from the governments, enterprises and society in general. A number of case studies on automobile industry were developed from the middle seventies up to the nineties. There are still many long lasting international research projects aiming to evaluate and enhance technological and organizational innovation such as the ULASB (ultra light automobile steel body), the PNGV (partnership for a new generation of vehicles), and the

ICED 01 -C586/400

449

EUROCAR (European car program for European Union). Besides, the largest Car Company in the world has its own research driving innovation named "Product Engineering for GM Advanced Technology Vehicles" which includes the EV1 project that reached 23 new patents. Buchholz [ 1 ] stated about it: "Design for assembly drives innovation especially with a new program. At the onset of $350 million EVl program 150 people -including GM engineers, manufacturing engineers, material engineers finance representatives, and suppliers - trained and practice over six months period on design for assembly dynamics. (...) Training time allowed product development teams to address assembly requirements up front (...) if we didn 't design for assembling considerations the EV1, than the plant layout would be radically different - probably twice as large and more complicated". The introduction of new materials in Renault cars followed this pattern: a team of material experts, product designers and production engineers have worked side by side in order to define the requirements for new advances in the materials field. This is the core idea claimed by the so called Concurrent or Simultaneous Engineering where a cross-functional group of experts from all relevant disciplines that affect the project, are supported by computer technology and communication systems. "Concurrent Engineering represents a way of conducting the design work where the various activities related to the product realization process are integrated and performed as much as possible in parallel rather than in sequence [2] ". Task overlapping is the main management method adopted, and its implementation is done through early release of partial design information within the team in order to allow downstream preliminary considerations just from the beginning. For materials producers, for instance auto-parts suppliers and automobile manufacturers the key factor for succeeding in the next century seems to be the continuous and larger cooperation keeping themselves side by side defining together requirements for new advances. And the coordination of this network during the development phase of such complex product as a car is a hard task. In the past, materials were selected from a "menu" where all available materials were listed. Materials substitution was done part by part, e.g. a plastic bumper replacing steel one. Research and development of new materials were done apart from their final applications; new materials used to appear in the market and carmakers selected them instead of the old ones. The shortcomings of this approach were that it did not profit from the functional integration opportunities enabled by new materials processes. During the late eighties carmakers had implemented the engineering approach, and took advantage in reducing the number of parts in a vehicle by integrating functions embodied in new parts. Boujut and Jeanet [3] give to us a good example of how hard is to involve suppliers from the beginning of a product development and how crucial is to create instruments to a cooperative type of coordination for the so called "interface actors". In fact this choice was enabled by a process of global innovation that can be defined as the results of an integrated system of car designing from R&D, to production level redefining all phases in parallel such as materials selection, electronic devices, new embodied technologies, new assembly line organization and techniques, the workers profile and specialization etc. From now on they do all that in partnership networks including materials suppliers, auto parts producers, electronic systems dealers, and, together, they have to rethink globally the conception of new cars balancing technical performance and environmental impacts, from the birth to the death of the new vehicle. In other words, they are supposed to do life cycle

450

ICED 01 -C586/400

analysis of the product during the project development. For instance, they have to go from the assembly to the disassemby specifications to enhance the recyclability of the automobile as a whole. And they have to do this as fast and as "innovatively" as possible in order to be competitive for the next century. This means that companies are being challenged to achieve an integrated environment - what they call "plateau project" in France - to develop their new products in order to compress the design cycle and improve project effectiveness. So the costs of the design phase seems to be increased by the incorporation of R&D activities as well as the investments done on pilot and industrial plants. Actually, design activities were enlarged including, in a broader view, from the first marketing idea till the end of car's life, passing by R&D, prototypes; vehicle engineering, up to final assembly, "disassembling" and recycling. Furthermore, they have to pass through all those phases together with their partners and always keeping the final client in mind, as the Clio project schematic view shows to us [see the picture at the end of this article].

The Automobile life cycle: Designing for innovation

In the last twenty years, the automobile industry established a new pattern of innovation and production management that incorporates systematic and continuous technological advances and that enables organizational evolution as well. As a result, the innovation process is getting more and more integrated enhancing a synergic view of product and process design, R&D, and manufacturing. In other words, by means of Simultaneous engineering and beyond it the design activity was enlarged in order to cope with innovation requirements from product research to the industrialization phase. Moreover, technological and organizational change is now part of the same process of global and continuous innovation supported by flexible new car's projects. In this context, technological and organizational learning is enabled, by means of this integrated environment, where design activities are developed and managed simultaneously [4]. In this scenario partnership is a key word. Different kinds of knowledge are shared by the automobile designers and suppliers, and a multidisciplinary know-how has been created as a result of team work in "plateau" at the development of projects for new and innovative cars. Furthermore, the way automobiles are being conceived and manufactured by the end of their first century also changes the concept of the most representative product of our era. What is really a car nowadays? Is an automobile just a means of transportation? Or is it a better way of life, a place to live in, to work in, or a tool for leisure? For the MIT definition a car is "a four wheeled, internally powered personal transport apparatus for road use, designed to carry a driver and a few passengers. " But in fact a car is an hybrid object that is recognized by its shape but not by its technological and social complexity. We would say that it is not one product but multiproduct conceived and assembled as a jigsaw puzzle. And this grysaw puzzle is not a regular one, which is formed by articulated parts, because in the case of the automobile these parts are not only articulated but also integrated in a synergic way so every little detail affects the final result [5]. In this sense Clark and Fujimoto [6] have a better definition: "a car is a complex 'fabricated-assembled' product, comprising a large number of components, functions, and process steps. " These authors have pointed out the diversification of automobile models that provides to consumers, more than ever, a growing different range

ICED 01 -C586/400

451

of options. In their words: "Twenty years ago, the American car buyer had to look long and hard to find a model with anything but a traditional V-8 engine with rear-wheel drive. Today, the variety of engine-drive train combination is large - 4, 5, 6, 8 and 12 - cylinders, multivalves, front-wheel drive, and four wheel drive. Looking at other parts of the car, we find new technology in brakes and suspensions, engine control systems and materials and electronics "[9, page 8]. This is a good picture of a two-decade effort in speeding innovations to bridge the technological gap of car industry compared to the high-tech sectors, such as for example aeronautic, space, and electronics. These sectors were the pioneers in the use of new materials. They took advantage of technological developments that came from physics, chemistry and materials science itself to generate all sorts of product and process innovations. Quoting Bragg [7] on the role of these advances for automobile industry: "Now, more than ever, materials research and development is critical for satisfying customers. Now, as from the dim beginning of this proud industry, the role of materials people is often backstage. The automobile designer will always be creative. Many ideas and design have been spawned, only to wait until materials development made the dream a reality. " So the automakers are nowadays redefining their product according to the consumers' expectations, reaching to improve the engine performance as well as to rend new models more comfortable, safer, easier to drive, and environmentally friendly. To meet these needs, the industrial project of a new model has to be alive in order to incorporate the continuous technical advances that can provide new functionalities to the car. This is achieved by means of an integrated design environment where simultaneous engineering methods are the key management tool employed. This new pattern is no more a top car makers issue, as it used to be two decades ago, it is now widely spread throughout automobile world companies as a philosophy of work organization to keep their competitiveness by means of continuous innovation strategy. The redrawing of the project coordination as well as its physics and organizational basis allowed the car companies concentrating on what differentiates them competitively. This strategic choice that demands a hard job on coordinating internal and external partners-actors' contributions, as can be confirmed by the Renault Clio project and the Technocentre story that we have studied.

Managing the Designing Integration for the New Renault Clio

This successful story was written by 600 persons that have shared an integrated engineering environment called "plateau-projet", physically located at Renault Technocentre and supported by updated technology in communications that enabled cooperative and simultaneous work. The design group was formed including people of inside and outside Renault, such as partners like GE Plastics and Omninun Plastiques. GE was in charge of the development of a new composite for car's wing use. So it is also the story of the Noryl 974, a new polymer-based composite developed during the project result of the partnership between Renault, GE and Omninun Plastiques, which would be the wing's producer. The New Clio was designed at Technocentre Renault, considered by SIA -Societe des Ingenieurs Automobile- the most advanced research center for automobile R&D. By all the indicators of technical and economical evaluation this project overpassed the Renault millestones and the project leader's best expectations[8]. This successful team was due to the <plateau-project organization that joined all the partners-actors in aiming at the goals established for the car, as can be seen at the schematic view of the plateau-project Clio.

452

ICED 01 -C586/400

In fact the Technocentre represents a summit of experts coordinated by Renault, by means of a pool of sponsors and permanent collaborators who believe that working together in tight networks is the only way to do the best job they can. The architecture of the Technocentre was conceived to permit people to work as they were playing together,e.g. acting as synchronically as possible. They are functionally placed in order to get easily all the information or collaborations needed in all phases of a new car project. Everything was planed to facilitate everyone's job and to increase overall efficiency. The three main blocks of this complex are sited in order to put the progressive phases of the development of a new vehicle side by side or in the same sequence they are suppose to follow to. So engineers, managers, technicians and highly skilled workers combine all their competencies working on researches, designers, product/process, quality, information etc. and purchase all the specialists needed for car development. The first building contains the advanced engineering and design units; the second one at the heart of the Center houses the project department and the project platform teams, surrounded by the Vehicle Engineering and the Research Department as well as the Purchasing Department; the third is the Prototype Building Center where a new product development ends by having the project specifications validated at manufacture level. Other facilities such as laboratories for materials certification and quality control are also part of this Research-Development and Engineering (R&D&E) complex. In a word, the Technocentre is a tool designed to aid research, as defined by Renault corporate communication in the special issue of Renault Magazine R&D. The same source states what we had already seen during the time we had been there: "The concept of this Center was Renault response to the key strategic challenge of reducing the development time for new vehicles to 36 months by 2000 and 24 moths subsequently, and ultimately saving at least 1 billion French Francs (150 million Euro) on the development costs of each new vehicle. The Technocentre is home to an 8500 strong workforce, including 2,000 non-Renault employees (partners and suppliers involved in project development)."[9] Even the shop-floor workers from Flins, the largest Renault production plant, came to Technocentre to work on the prototype and to assemble the first 30 cars at the mini plant they had installed there. In short, they participated in the assembly systems selection. Moreover, some of them went to the suppliers' industrial machine plants to be in touch with the new automated systems for welding and final assembly uses. The New Clio was launched simultaneously in three plants in Europe: Valladolid in Spain, Novo Mesto in ex-Yugoslav, and Flins in France, in October 1998 and one year later in Airton Senna plant in Sao Jose dos Pinhais near Curitiba in Brazil. It comes in 7 versions concerning the engine specifications and the fuel systems adopted: four gasoline versions (1.0 -only for Brazil- 1.2; 1.4; e 1.6) 8 V.; two diesel versions (1.6 16 V and a turbo-diesel direct injection); plus one electric version for urban uses. And this year, 2000, Renault is planning to have a new 1.0 16 V for Brazil market, which associates a 1.6 regular engine performance to a lower gasoline consumption. [14] Besides in Brazil Renault is also doing some high tech research on fuel cells in partnership with the Hydrogene Lab of COPPE/UFRJ since 1999. So the New Clio results are the best evidence of Renault's global innovation strategy that, coordinated by the designing activity, has been promoting an integration of R&D between auto makers and suppliers and also promotes new forms of flexibility for industrial innovation once for all. And even more than that we can say that this project is still alive. We mean that it

ICED 01 -C586/400

453

is still being improved in order to incorporate new advances in industrial process, engine systems and materials to meet new environmental requirements as well as to make it more performance and cost effective. While the discussion at the European Parliament to establish European Directive on end of life Vehicles was still taking place the New Clio was launched in October 2000 already conceived to be 95% recyclable. Table l:The New Clio in Numbers Compared to the old one Indicators Investments: Designing phase Industrialization phase Production Costs reduction Reduction of Industrial area in the plant Downsizing of the assembly line Reduction of time production (IMVP) Reduction of auto parts to be assembled Reduction of welding operations Reduction of the steps for the engine check in Reduction of fuel consumption Reduction of CO2 emissions
Change rate: USS 1.00 = 6.00 FF Source: Medina 2000 [2]

Results 3,3 billions of Francs 4,2 billions of Francs

12% 25% 19%

6 hours
25%

20% 37%
15% 12%

These successful results were obtained by means of a new style of project management the so called the "plateau project" where all the groups in charge of each automobile systems worked together at the conception, design, prototyping and assembly line. Outside partners shared even the patents obtained as was the case of the Noryl 974 for the Clio wings. And as mentioned before, this project is still alive and is now being improved by an international group including Argentine, Turkish and Brazilian engineering teams that had joined the French team at Technocentre.

Concluding Remarks

Managing design for innovation was the main strategy adopted by the world car companies regarding all these requirements integrating activities such as R&D, design, prototyping and industrial production. Although different actors are affected to this context the coordination of internal and external partners is crucial to the success of the project. The best trajectory for keeping competitive market share is to work in simultaneous parternships for R&D, design, and engineering activities up to the industrial level. Working in network partners share risks and profits and also get more innovative solutions to reach the sustainability of the automobile for one more century.

454

ICED 01 - C586/400

This is surely a great opportunity for the less developed countries' automotive plants to get into design activities, which up to now have concerned only the headquarters bureau employees. Especially for Brazil we think that is important to get into new projects designing from the very beginning to participate at the materials selection as well as the research for innovative technical solutions. The only way we have to do so is to establish long term R&D partnerships with the carmakers, as Renault and COPPE/ UFRJ have been doing since 1999 concerning materials for fuel cells engines. References 1. Buchholz K., The Hiden Design Advantage: Manufacturing Input in Automotive Engineering. SAE, pp. 57-59, August, 1997. 2. Medina, H.,V., (2000), O proieto e a difusao de novos materiais na industria automobilistica. PhD. Thesis in Production Engineering at COPPE/UFRJ, fevereiro 2000. 3. Boujut J-F, Jeantet A., Involving Suppliers in early product Development : a Challenge for the purchasing and engineering functions, Proc. ICED' 99, Munich August 24-26, 1999, pp. 1001-1006. 4. Bellgran M., and Aresu E., Different Design Preconditions in Simultaneous Developement ofProducts and Production Systems, Proc. ICED' 99. Munich August 24-26, 1999, pp.325- 328. 5. MEDIA TECH, (1998) publication des ressources humaines editee par Renault, N 13, mai 1998 6. Clark K.B., Chew. W.B. and Fujimoto T., Manufacturing for Design: Beyond the Dichotomy Production/R&D, in SUSMAN, G.I., (editor), Integrating Design and Manufacturing for Competitive Advantage. NY, USA, Oxford University Press, 1992. 7. Bragg R., Materials Key to 100 Years of Automotive Progress, in Automotive Engineering. SAE, pp 93-99, dec. 1996. 8. SIA - Societe des Ingenieurs Automobile- "Le Technocentre an autout decisif pour lavenir Renault" site internet: http://www.sia.fr/actualites , 05/15/1999. 9. R&D The Road of Innovation, special issue, Magazine Renault of Research and Development, N 14, October 1999. 10. Birch S., Design, development and globalization> in Automotive Engineering. July 1996, pp.8087. 11. Boyer R., Freyssenet, M., "The world that changed the machine: some conclusions; successful firms 1974 to 1992, in La Lettre du GERPISA. N 117, nov. 1997, Paris. 12. Brindenbaugh P.R., "Strategically Integrated Partnerships for Materials and Auto producers", JOM Journal of Mining, pp 18-19, July, 1995. 13. Buchholz K., "Manufacturing, R&D Practices Vary Among Automakers", in Automotive Engineering. SAE, USA, October, 1996. 14. Buchholz K., <Simultaneous Engineering saves time and money, in Automotive Engineering. SAE, pp.97-99, November, 1996. 15. Freyssenet M., Les transformations du travail en groupe chez Renault>, pp 185 a 197, em L'avenir du Travail en Chaine. sous la Direction de DURAND J-P; STEWART P., CASTILLO J. J., editions La Decouvert, Paris, 1998. 16. Freyssenet, M., Mair, A., Shumizu, K. and Volpato, G., "Conclusions : the Choice to be made in the Coming Decade" pp. 452-462, in FREYSSENET, M., MAIR, A., SHUMIZU, K. and VOLPATO, G., One Best Way ?. London, Oxford University Press, 1998. 17. lansiti M., Real-World R&D: Jumping the Product Generation Gap. Harvard Business Review May-June 1993, USA. 18. Naveiro, R.M. and O'Grady, "A Concurrent Engineering Approach for Desing Assistence of Casting Parts", Proc. ICED' 95. pp.22-24, Praga, August. 19. R&D the Road of Innovation, (Jan.2000) Renault N 15 and (Jan.1999) Renault N 8 e 11. 20. Sharif s. and PAWAR K.S., "Product design as a mean of integrating differention", Technovation. 16 (5), pp 255-264, printed by Elsevier Science Ltd. In Great Britain, 1996. 21. Shimokawa K., Juiirgens, U., Fujimoto, T., (1997) Transforming Automobile Assembly: Experience in Automation and Work Organization. Introduction, pp.1-16, Berlin, Springer Verlag.

ICED 01 -C586/400

455

Heloisa Medina (hmedina@cetem.gov.br) is Senior Researcher at CETEM and Ricardo Naveiro (ricardo@pep.ufrj.br) is Professor of Product Design at Universidade Federal do Rio de Janeiro.

With Authors 2001

456

ICED 01 -C586/400

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

RESEARCHING THE THINKING PROCESS IN DESIGN TEAMS - AN ANALYSIS OF TEAM COMMUNCIATION

J Stempfle and P Badke-Schaub Keywords: Prescriptive models of the design process, thinking process, design teams

Introduction

The thinking process of designers is not yet fully understood. Design theory and methodology [e.g. 1, 2] postulate a sequence of steps that designers should follow in the process of product development. A similar sequence is postulated for general problem solving processes in cognitive psychology [3]. Our research reveals, however, that the actual thinking process of design teams seldom matches the postulated step sequence. Despite the fact that the thinking process does not follow this postulated step sequence, regularities can nonetheless be observed that shed light on the "natural" thinking process of design teams. A two-processtheory of thinking in design is being proposed capable of explaining the thinking process we have observed empirically.

Theory

Team communication in design teams can be differentiated with regard to two communication focuses, content and process. With this differentiation we take into consideration that teams, in order to reach their objectives, do not only discuss the content of a given problem, but must also structure their own interaction process (for example, teams have to decide in what order subtasks are to be addressed).
Content Underlying Basic Thinking Operation Process

Goal Clarification Exploration Solution Generation * Analysis ' Generation Planning

1
Analysis

1
Evaluation * - - - - - Comparison - Evaluation

1
Decision Control * Selection

1
Decision

+
Control

Figure 1. Steps in the design process and underlying basic thinking operations.

ICED 01 - C586/215

457

Social psychologists such as Morgan, Glickman, Woodward, Blaiwes and Salas [4] make a similar distinction when separating group activities in task-work and team-work activity. Under both of the two communication focuses of content and process a set of steps can be proposed. Each step is associated with one of four underlying basic thinking operations. Figure 1 depicts the steps in the design process and the underlying thinking operations. In the above model, we propose that content and process-related activity of design teams can be described in similar terms, with the same basic thinking operations underlying both process- and content-related activity. Concerning content, the above step sequence differentiates between actions focused on the goal space (goal clarification) and actions focused on the solution space (all of the remaining steps). Two of the four basic thinking operations proposed above, generation and exploration, are also stressed by creativity researchers Ward, Smith and Finke [5], who in their GENEPLORE model propose generative and explorative processes to be the main ingredients of creative activity. Both generation and exploration of ideas serve to enlarge the solution space. In order to work out a solution to a given problem, however, design teams must also carry out operations that serve to narrow the solution space. This narrowing of the solution space is done by comparing one or more solutions to each other and to the requirements of the task and by selecting the most viable option. The steps above are arranged in an intuitively compelling order that matches the step-models proposed in design methodology [1,2] and cognitive psychology [3]. We do not propose, however, that teams follow the steps proposed above in this fixed order, but expect teams to frequently interpolate between the different steps in various ways. The aim of this research is to investigate whether transitions between the steps are arbitrary, or whether systematic transitions can be found that frequently occur in design teams.

Research Methods

In this paper we present results from one field study and three laboratory studies. In the field study we have investigated a design process in a German automotive supplier. A team of four people working on a joint task has been observed over a period of six weeks. In the laboratory studies three student teams majoring in engineering have been presented with a complex design task that they were to solve in a one-day-period. The communication observed in the studies has been recorded and categorised by means of a multilevel coding system. The top two levels of the coding system correspond to the main communication focuses and the design steps that have been described above. Communication in the team has been analysed sequentially in order to investigate the underlying thinking processes of the team.

Main findings

4.1 Distribution of utterances among the categories

Figure 2 displays the distribution of utterances in the four groups among the two major communication focuses content and process.

458

ICED 01 - C586/215

Figure 2: Distribution of utterances among the two major communication.

In both, the field study and the laboratory studies, a similar distribution of utterances among the main categories results. This distribution can roughly be described by the "2/3-rule": In 2/3 of their communication design groups deal with the content whereas 1/3 of the group communication aims at structuring the group process. Similar results are reported from problem-solving groups in non-design contexts [6]. On the level of steps in the design process, the distribution of utterances among the steps is quite similar in the four groups as well, with a medium correlation between the distributions of .98 between the four groups. The following figure displays the average frequency of design steps in the four groups.

Figure 3: Distribution of utterances among the steps in the design process (average of all groups).

In the observed teams, most of the team communication is concerned with analysis of both, the content (42%) and the process (17%). The next frequent category is the evaluation of content (15%) and process (5%).

ICED 01 - C586/215

459

Regarding the pure frequencies of the communication categories, the observed design groups cannot be very much differentiated. On the other hand, differences in performance and style of the groups exist that apparently cannot be explained by the findings reported so far. The question that remains is how do groups go about in their design process? What are the similarities and the differences between groups?

4.2 Analysis of transitions between categories

In order to conduct an analysis of the team design process, transitions between categories have been analysed. The question to be answered is: Is team communication "chaotic" in the sense that any sequence of categories is likely to appear or are there regularities, with one category systematically following after a specific other category? In order to answer this question, the transition probabilities between all of the categories have been calculated and then compared to the baselines of the categories. If, for example, content analysis occurs in 42% of all team communication, but after a content analysis in 65% of all cases another content analysis follows, this means that sequences of content analysis are highly likely to occur in team communication. The following figure displays transition probabilities between the two communication focuses content and process (average of all four groups). In the figure, a connection that ends with an arrow displays a transition that is significantly more likely to occur compared to the base rate (as calculated by a Chi2-test). A connection that ends with a straight line displays a transition that is significantly less likely to occur compared to the base rate. The first number behind the connection is the transition probability, the second number is the base rate probability:

Figure 4: Transition probabilities between the two major communication focuses (average of all four groups).

The transition probabilities displayed in the figure are significant for all four studies. In all four studies, transitions within the same communication focus are highly likely to occur whereas transitions between the two communication focuses are highly unlikely to occur. On average, teams spend 6.3 utterances on content-related communication before switching to process-related communication, whereas sequences of process-related communication have an average duration of 3.2 utterances before the group switches to content-related communication. These findings reveal that the design process in teams is best described by a constant interweaving of content-directed sequences with process-directed sequences, both of some - but different - duration.

460

ICED 01 - C586/215

In the following analysis of transitions between the design steps, we focus on content-related utterances only. For the calculation of transition probabilities, the four studies have not been "averaged", but instead the results of all four studies have been calculated separately in order to ensure that the results are not solely an artefact of data aggregation. The following figure displays transitions between the design steps in the four studies that are significantly more probable than expected given their respective baseline.

Figure 5: Transitions between design steps.

One interesting result is that for every design step except the step 'decision', a transition within the same step is highly likely to occur. The proposed design steps thus seem to be steps indeed in the sense that groups tend to spend more than one utterance on the same step before moving on to the next step. In the three laboratory studies, a feedback loop evolves consisting of analysis and evaluation, in the field study a feedback loop between solution generation and evaluation. The repeated interplay of analysis and evaluation thus seems to be at the core of the collective thinking process in the laboratory groups. While analysis enables the teams to widen the solution space, evaluation serves to narrow it down again. The constant interpolation of analysis and evaluation might enable the groups to keep the size of the solution space at an acceptable level.Of special importance is the fate of solution ideas. When a new solution idea is being proposed, the team's immediate reaction often decides on the acceptance or the rejection of the idea. Regarded from a methodological perspective, one would expect new ideas to be followed by a thorough analysis. What one would not expect is an immediate evaluation. In fact, creativity techniques such as brainstorming [7] explicitly prevent groups from premature evaluation. Our results show, however, that groups frequently do not follow such recommendations, but do evaluate solutions immediately without prior analysis. In three of four observed groups, a new idea is highly likely to be followed by an immediate evaluation without prior analysis. Only two (because the lab group 3 shows both loops) of four observed groups frequently progress from solution generation to analysis. From a theoretical viewpoint, an immediate evaluation of a solution idea without prior analysis must be regarded as problematic. Two errors are likely to occur. One is premature rejection of a solution because it does not seem to fit the constraints of the task structure. Oftentimes, however, a solution that does not fit at first sight can be transformed in order to produce a fit with some effort. Indeed, most creative solutions are not intuitively compelling

ICED 01 - C586/215

461

at first sight, but must undergo several transformations before their usefulness becomes obvious. A second error that is likely to result from a premature evaluation of solution ideas is the premature adoption of a solution that proves problematic later on. A complex design task is comprised of many different requirements and constraints, often too many for people to keep in mind. Thus, a crucial constraint may be forgotten, with a false positive evaluation of a solution idea resulting. Both errors are grave. In the first case of premature rejection of a solution idea, an ingenious idea may be discarded and lost for the group. In the second case of premature adoption of a problematic solution idea, groups may spend considerable time working out a solution only to find out later on that the solution does not work. Given the proposed negative effects of premature evaluation of solution ideas, how can we explain the proceedings of the three of four observed groups?

A second look at the step-by-step-paradigm: A two-processtheory of thinking in design

We do, in fact, propose that the observed sequence of solution ideas being followed by immediate evaluation is not simply an error committed by some teams, but that this process represents the "natural" thinking process teams adopt by default. We will thus call the sequence of solution generation - evaluation process 1. As a reason for this proceeding of teams, Ehrlenspiel's [9] construct of "cognitive economy" can be cited. Decision researchers [see e.g. 9] have long shown that when faced with decision tasks of various kinds, humans do not strive to find the best of all possible solutions, but rather strive to find a workable solution with minimum effort. In a first, quick screening process, the number of possible alternatives is thus immediately reduced to a few remaining options. In the same manner, the premature evaluation of solutions in design teams may serve to a priori limit the solution space to a handful of promising alternatives. This behaviour can thus be explained by the tendency of teams to spend minimal cognitive effort on the problem. We do not propose that teams strive for cognitive economy consciously. A limited memory capacity and the fact that our conscious thinking works in a serial, not in a parallel mode, forces us to reduce problems to small chunks and to limit the number of options we consider. In problem spaces of little or moderate complexity, process 1 will frequently be quite successful. In problem spaces of high complexity that require numerous transformations before a solution can be adopted, however, process 1 is likely to fail oftentimes. Nonetheless, in two of the observed teams (lab group 3 realised both processes) a proceeding different from process 1 has been observed. In these teams, solution ideas were frequently followed by analysis before an evaluation took place. We will call the sequence of solution generation - analysis process 2. Out of four observed teams, two teams frequently employed process 2 (lab study 2 and 3). The performance of these two teams has been rated substantially higher by independent design experts, who had no knowledge of the hypothesis presented in the paper, than the performance of the two teams who primarily employed process 1 (field study 1 and lab study 1). Process 2 violates the principle of cognitive economy, since teams using process 2 will most likely spend time on the analysis of solution ideas that are later on being discarded. If this is the case, why do some teams still adopt process 2 at least some of the time? We believe that several factors may cause teams to switch from process 1 to process 2.

462

ICED 01 - C586/215

Failure of process 1: Once a team has discarded a considerable number of solution ideas without coming up with a workable solution, the team may be forced to re-analyse the solutions that have already been discarded for the lack of alternative solution ideas, thus switching from process 1 to process 2. Beach [9] has observed a similar process in decisionmaking tasks, with subjects conducting a second screening process with a relaxation in the constraints if the first screening failed to produce an acceptable alternative. The lack of new solution ideas may thus lead to a re-analysis of already existing ideas. Disagreement and challenging of ideas: As has been observed in one of the observed groups, disagreement and the challenging of ideas can lead to a careful analysis of solutions. In one of the groups one team member frequently contested solution ideas that others had already accepted. This stance of challenging lead to a careful re-analysis of the solution idea, oftentimes with new and important insights evolving. In the same manner, the same group member kept uttering one solution idea repeatedly although the team had already decided to drop the idea. After the fifth re-analysis of the solution idea, however, the idea was finally accepted by the team. Disagreement thus seems to enhance analysis, a result that is already implemented in the well-known method named the devil's advocate. Adoption of a methodology: In the four teams we have observed, only one team (lab study 2) tried to structure the design process by use of a methodology. This team actively used creativity techniques such as brainwriting, thus consciously separating the processes of solution generation, analysis and evaluation. This approach enabled the team to avoid premature judgements. Many creativity techniques suggest suspending judgement, thus allowing oneself to explore even "off-the-wall"-ideas. The use of such techniques may help to transgress from process 1 to process 2. Self-reflection: We agree with Schon [10] in stating that self-reflection is the key to successful design for both individuals and teams. Self-reflection may lead teams to consciously realise that they are stuck in a process-1-approach. From this point, teams can alter their proceeding. We do not agree with Schbn, however, in that individuals and teams do self-reflection by themselves. Speaking about the teams we have observed so far, we have not yet met a single "reflective practitioner". On the contrary, genuine self-reflection occurred very rarely in the teams we have observed. The teams seemed to be rather reluctant to criticise their own actions and thinking. This may be caused by the fact that if a group member criticises the team's approach, this may be perceived by others as a threat to the team as a whole. In the few instances where we have observed such criticism in the observed teams, the reactions of the team have been unfavourable. We therefor conclude that if self-reflection is to occur in teams, it must be actively encouraged.

Conclusions

The results and interpretations presented in this paper have important implications for the education and training of designers. While we agree with Schon [10] that conventional design methodology [1,2] with its strongly scientific approach is counterintuitive to many practitioners and therefore difficult to employ in practice, we are convicted that sole reliance on the natural "artistry" of designers will produce errors that can be prevented. Our research reveals a tendency in design teams to spend minimal cognitive effort on the design task. Solution ideas are often quickly being evaluated without careful analysis, a premature narrowing of the solution space seems to be a common phenomenon. We have

ICED 01 - C586/215

463

called this proceeding process 1. While process 1 may be effective for the resolution of simple tasks, it will create problems when dealing with tasks of high complexity. For such tasks process 1 should be replaced by process 2. Solution ideas should be analysed carefully before evaluation takes place. In order to achieve this end, we suggest educating design teams in the active and conscious use of self-reflection and in a new way of using design methodology. Teams should not use any methodology "by the book", but should be capable of flexibly using any method or technique suitable to their momentary needs. What we observe is that it is not knowledge that is lacking, but competence. This competence can best be perceived as "meta-knowledge", the knowledge about how to use what you know. Self-reflection and meta-knowledge should become prime objectives in the future education and training of design teams as it is elaborated for the critical-situation approach by Badke-Schaub [11]. References: [1] [2] [3] [4] Pahl, G. and Beitz, W. "Engineering design". London, Springer, 1984, 1995. VDI Design Handbook 2221, "Systematic Approach to the Design of Technical Systems and Products". Dusseldorf, VDI-Verlag, 1986. Dorner, D., "The logic of failure". New York Metropolitan Books, 1996. Morgan, B. B., Jr., Glickman, A. S., Woodward, E. A., Blaiwes, A. and Salas, E., "Measurement of team behaviors in a Navy environment" (NTSC Report No. 86-014), Orlando, FL: Naval Training System Center, 1986. Ward, T. B., Smith, S. M. and Finke, R. A., "Creative Cognition", in R. J. Sternberg, Handbook of Creativity. Cambridge, Cambridge University Press, 1999 Fisch, R., "Eine Methode zur Analyse von Interaktionsprozessen beim Problemlosen in Gruppen" [A method for the analysis of interaction processes in problem-solving groups], Gnippendvnamik. 25, 1994, pp. 149-168. Osborn, A. F., "Applied Imagination - Principles and Procedures of Creative Thinking". New York, Scribner,1957. Beach, L. R., "Four Revolutions in Behavioral Decision Theory." In M. M. Chemers & R. Ayman (eds.), Leadership Theory and Research. Perspectives and Directions, San Diego, Academic Press, 1993. Ehrlenspiel, K., "Practicians - How they are designing? .. and Why?" Proceedings of the ICED '99. Miinchen, 1999, Vol. 2, pp.721-726.

[5] [6]

[7] [8]

[9]

[10] Schon, D. A., "The Reflective Practitioner: How Professionals Think in Action". New York, Basic Books, 1983. [11] Badke-Schaub, P., "Group effectiveness in design practice: Analysis and training by a critical-situation-approach", Psvchologische Beitrage. 41, 2000, pp. 338-355. Dipl.-Psych. J. Stempfle Dr. P. Badke-Schaub University Bamberg, Institute of Theoretical Psychology, Markusplatz 3, D- 96045 Bamberg, Germany, Tel.: ++49 (0)951 8631864, Fax: ++49 (0)951 601511, e-mail: joachim.stempfle@ppp.uni-bamberg.de J Stempfle 2001

464

ICED 01 - C586/215

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

TOWARDS A SCIENCE OF ENGINEERING DESIGN TEAMS

A Mabogunje, K Carrizosa, S Sheppard, and L Leifer

Keywords: Design Teams, brain imaging, video observation, computer simulation

BACKGROUND AND OBJECTIVES

The last few years have witnessed a renewed interest in various typologies to classify the dominant or preferred behaviors (cognitive and social) of engineering designers during the product development process. See for example research on p-designers (high experience and little or no training in formal design methodology) and m-designers (low experience with training in formal design methodology) conducted by Gunther et al [1]; research on the relationship of individual styles of problem solving to representations in the design process by Eisentraut et al [2]; research on the relationship between the diversity in the personality of team members and design performance by Wilde [3]; study of how individual particulars such as theoretical education and demand for quality affect the outcomes of critical situations in industry by Frankenberger et al [4]; behavioral and electrophysiological study of effect of experience (novice vs. expert) on design problem solving by Goker [5]. Coincidentally, this renewed interest comes at a time when new technologies, which increase our capacity to observe designers in action, have become widely available. Among the new technologies that have come into recent use by researchers are the video camera, the functional magnetic resonance image scanner, and the computer. Furthermore our ability to process the observed data has also improved, such that we can better determine the relevance and predictive accuracy of these typologies. These improvements in the instrumentability of design teams suggests that in future we will be able to build better models of the workings of design teams and formulate hypothesis which can be readily tested and validated. This paper is conjectural and represents an attempt to plan future research by building on past empirical work in the context of modem tools. Today we compose teams primarily based on the background experience in a given field of knowledge and the task requirement. For example we may compose a team consisting of two electronics engineers and one mechanical engineer. This kind of composition, based on domain knowledge, in addition to other structural factors like the organizational arrangement, communication tools, and computer tools is analogous to the "physics" of teams. On the other hand a composition that considers the cognitive style of the individual members, their temperament, their response to stressful situations, and the pattern of interaction with other team members is analogous to one based on the "chemistry" of teams. The objective of this paper is to explore a future scenario in which such a science can be applied to real world situations. A priori this exploration will be based on three key ideas. First is to select a commonly observable design phenomenon. We believe this will keep us grounded in design practice and help in prioritizing our research questions. Second is to build on the "observeanalyze-intervene" research methodology [6]. This methodology is a form of action research that emphasizes intervention as an important way of understanding complex systems. The

ICED 01 - C586/477

465

third idea is to use computer simulations as an integrating tool in our work. We intend to draw on the results of empirical studies we have done and other related studies in coming up with testable hypothesis. Based on our previous work [7,8] we were struck by the high number of concepts and variables that need to be considered by researchers when studying design teams. Computers give us the ability to externalize our evolving understanding of design teams into symbolic models, which can then be easily shared and manipulated. We believe this approach will make it much easier to consolidate our findings and develop our understanding. In the rest of the paper we elaborate on each of these ideas using concrete examples. We will then conclude by reflecting how such a science of design teams as we propose could be applied to future design scenarios.

Classic design problem: "Requirements Deviation"

Our first idea is to choose a commonly observable design phenomenon. We believe this strategy will appeal to practicing engineers and thus make it easier for us to find subjects within this population. Furthermore we believe that grounding our theories in practice will give us an important criteria for prioritizing our research questions. Figure 1 illustrates a common problem we believe most designers are familiar with. This is a problem in which over the course of time the request of the client becomes transformed into an artifact that fails to meet the client's needs.

What the client requested Day 1

What marketing thought the client requested Day 10

What engineering thought marketing said the client requested Day 15

What production manufactured for the client Day 30

Figure 1. An illustration of the requirements deviation problem

We believe a science of design teams will enable us to estimate the likelihood of this deviation or "creep" from the original intent. In other words we would like to make predictions of the form described below: When a design team D with properties Dl, D2,... working in an environment E with properties El, E2, ... in a market M with properties Ml, M2, ... is assigned a design problem P with properties PI, P2, ... in time T with properties Tl, T2, ... the result will be 0 with properties Ql, Q2 ... As seen above, there is a high number of variables necessary to make any good predictions about the performance of design teams. We believe our research approach using a combination of multiple observation methods and simulation-based analysis is the necessary and sufficient situation to address such a complex issue. We will elaborate on the specific elements of this approach in the next two sections.

466

ICED 01 - C586/477

Research Methodology

The "observe-analyze-intervene" method is an iterative approach to research that emphasizes the development of interventions as a way to perturb a system and test underlying assumptions. Illustrated in figure 2, the method begins with the observation phase whereby a real world phenomenon is observed and recorded. In the next phase, the data collected is analyzed and interpreted. This interpretation is then used in the third phase to inform the design of new tools and methods that will impact the behavior observed in the initial real world situation.

Figure 2. The Observe-Analyze-Intervene methodology, through its intervention step allows a complex system to be perturbed and reveal hidden assumptions.

The cycle is then repeated in such a way as to deepen one's understanding of the real world phenomenon and, refine or change the tools and methods that were earlier introduced. The method has been very useful to us in the design of computer and communication tools to support design work and we believe it offers a practical way to develop a science of design teams. As we discussed and thought about the new technologies mentioned earlier (video camera, functional magnetic resonance scanner, and computer simulation) we realized that essentially all three, in addition to the more traditional social science tools of interviews and surveys, allowed us to access the design process from different perspectives and each had its limitations. For example video/audio recordings were useful for observing external actions and audible utterances, but were of limited use when it came to knowing anything about the nature of the designer's thought process. Brain imaging would allow observation of the internal cognitive activity of the designer but tell us nothing about the designer's beliefs, motivations, and attitude. Interviews and questionnaires will allow us to leam more about a designer's beliefs, motivations, and attitude, but nothing about what the designer actually does in practice. We shall now describe each of the three primary observation methods in turn using illustrative examples from empirical work.

3.1 Video Observations

Effective communication between engineering design team members is essential for high performance in product development. In turn effective communication depends on successful transfer (sending, receiving and processing) of information. This information may range from data and facts to creative ideas. Previous work by Felder and Silverman has shown that individuals differ from one another in how they prefer to receive and process information [9]. They referred to these preferences as learning styles, and developed a set of five dimensions, each consisting of a pair of poles (shown in parenthesis), that could be used to describe individual preferences. We believe these dimensions namely Perception (sensing, intuition); Information Reception (visual, verbal); Information Processing (active, reflective); Information Sequencing (sequential, global) and Information Organization (inductive,

ICED 01 - C586/477

467

deductive) will be of particular importance to understanding communication difficulties in design teams. Figure 3a shows a sample profile for an individual in the information reception dimension.

Figure 3. a) A sample profile of an individual with a moderate preference to receive information visually, b) Team learning style distributions. Team 1 was formed such that its members, on the average, strongly preferred to receive information visually. Team 2 had a moderate preference to learn visually. Both Team 3 and Team 4 had a mild preference to receive information visually.

In a recent study we looked at the relationship between individuals' preference for receiving information and their methods of sending information. It was initially anticipated that each individual's mode of presenting information would match his or her preferred mode of receiving information, and that this match would result in improved communication. To study the congruency (or incongruency) of how individuals prefer to receive information and how they go about sending information an experiment was designed and conducted. The experiment consisted of four teams of engineering educators engaged in a design exercise which was videotaped. Their information reception preferences are shown in Figure 3b. Results based on analysis of the video tapes and individual Learning Styles Inventories showed that most participants preferred to receive information visually and engaged in drawing very little during the design exercise. If the definition of "visual communication" was expanded to include using drawings, communicative gesturing (i.e., using hand gestures to describe a physical object or action), using hardware, and referencing hardware, visual communication went from comprising an average of 3.8% of the design time to an average of 21.1% of the design time. This means that a large majority of the communication was mismatched with the preferences of the receivers [8].

3.2 Interviews and Questionnaires

Since there is only so much we can learn from externally observable events, the use of interviews and questionnaires to complement our video-based observation is imperative. From the types of data that could be gathered through these methods we can learn more about individual attitudes and beliefs. Not only will this be important in explaining behaviors we observe, it could also lead to new ways for understanding design.

3.3 Brain Imaging

There are several techniques to image the brain, and two of the primary constraints have been the degree of resolution (2D versus 3D) and the invasiveness of the technique. Goker, M. at Darmstadt University for example conducted an electroencephalography study to compare brain activity of novice and expert designers while they were solving simple design problems, Goker [5]. A major breakthrough came with the development of the functional magnetic resonance imaging (fMRI) technique, which is non-invasive and has high 3D resolution. FMRI is based on two key ideas: 1) during brain activation the oxygen content of venous blood increases in the region of activation; 2) when a human is placed within a magnetic

468

ICED 01 - C586/477

resonance field, the increased blood flow causes an increase in magnetic resonance signal intensity. The resulting techniques of brain imaging essentially allow us to explore structure-function relationships in the brain i.e. how activities in distinct neural processing come together to perform complex tasks such as reasoning, reading, remembering, and visualizing. In recent years, a number of physiological studies, which have shown strong implications for design performance, have been reported in the literature. In a more recent study at the Stanford Cognitive Neuroscience Laboratory, the researchers were able to identify specific brain activities that differentiated between visual experiences, or images, that were later remembered well, remembered less well, or forgotten (Brewer et al. [10]). As an illustration, this latter finding can be adapted to the requirements creep problem by assuming the subjects are representatives of the marketing department. Consider therefore the situation in which we recorded the brain activity of the subjects during the design exercise, where they are generating and refining a space of images that describe a potential solution to the design problem, and a week later, we have them describe this space of images to another set of participants representing the engineering department. Brewster et al's work should potentially enable us to know the strength of the memory of the images for each marketing representative. Conceptually then, this will enable us to predict which representatives will have a higher probability of relaying incorrect information.

Computer Simulation

We see from the foregoing that the number of variables that would be required in a science of design teams could be very large. We would definitely make simplifying assumptions but even when we do this, we still need to keep track of the variables we eliminate, and the rationale for each assumption. In earlier work, we used a computer simulation program named virtual design team (VDT) to model and simulate the project performance of an engineering organization [11]. While VDT was not specifically written to study small size design teams, we believe it can be conceptually adapted for this purpose. In order to understand our adaptation we will review a few of the basics of VDT.

4.1 The virtual design team (VDT)

In general, the conceptual model in VDT seeks to explain how actor variables, task variables and organizational variables affect the duration and quality of an engineering project. Actor variables include elements such as the skill of the actor with respect to a particular task, her preferences for using certain communication devices during task execution and her position within the organizational hierarchy. Task variables include a description of the level of complexity of a task and the degree of uncertainty associated with the task activity. Organizational variables include such variables as the structure and communication policy. The relationship among these variables is based on a combination of Galbraith's theory of information processing in firms [12] and heuristics for estimating the duration of tasks and quality of decision making during the execution of a project. These heuristics focus on the process by which the first line actor handles exceptions. In general, there are three options: doing nothing (default delegation), reporting to a colleague (lateral communication) or reporting to a supervisor (vertical communication). In communicating with the colleague or supervisor, a further choice is made with respect to the communication medium to use, memo, fax, telephone, e-mail, or face-to-face meeting. These choices are constrained by certain

ICED 01 - C586/477

469

factors and have consequences. They are constrained by the organizational structure and the communication policy within the organization. The consequences relate to how the choices affect other members of the organization and ultimately the total time to execute a given task. In a short form, the total time to complete a task T is the sum of: 1) The nominal time (time it will take an average actor uninterrupted) 2) The communication time (when an exception occurs this is the time interval between sending a message to one's supervisor or colleague and getting a reply) 3) The rework time (if there is a problem, this is the time it takes to fix it). In addition VDT predicts the project quality based on the number of unanswered communications and number of uncompleted rework. When these numbers are high, quality of work is judged to be poor. For our purposes, we define a product development process as a series of team meetings inter-spaced with individual work and in the next section we will describe a hypothetical situation in which we combine our three observation methods to estimate the likelihood of the deviation in the requirements creep problem.

4.2 Image Communication Model

Consider the different possible variables in a simple communicative transaction in which a person A wants to communicate an image to a person B. The send mode could be words, gestures, or sketches; the receiver may be inattentive, half attentive, or fully attentive; the image invoked in the receiver's mind could be the same as the senders, very different, or the receiver may draw a blank; the receiver may decide to verify correct reception or not, etcetera. We have illustrated this in the model shown in Figure 4. Assuming that each of the variables has an attribute of quality, we can proceed to explore how quality can be measured in each case. Transmission, verification, and confirmation quality could be determined by comparing the input image with the output image. Alignment is found by comparing the mode in which the information is sent by person A with the preferences for reception of person B. For example, reception preferences lie along the continuum from visual to verbal. Send modes are speech, sketches, communicative gestures, using hardware as a simile, referencing sketches, and metaphoric speech or some combination of two or more of these modes which can be classified along a continuum from visual to verbal. Based on this model we expect to be able to estimate the accuracy of the image being communicated using a factor that is the product of the qualities of transmission, attention, reception, alignment, verification, and confirmation. Using the same model we can also estimate the time it takes to communicate an image as the modified sum of the transmission the reception time, the verification time and the confirmation time. We expect individuals will differ in terms of their likelihood not only to expend time in these areas but also to iterate through the process until confirmation is achieved. Armed with these estimates we can for example estimate the number of meetings it would take for a given team to successfully communicate a given set of images. We can similarly estimate the failure rate we can expect given their likely behaviors as observed from their interview and questionnaire data, brain scan recording and video recording, thus predicting the likelihood of the team to deviate from the client requirements. Figure 5 shows how computer simulation can be used in the analysis phase of our work and in so doing complement our observation methods and lead to more informed interventions.

470

ICED 01 -C586/477

PERSON A

PERSON B

Figure 4. Model of a simple communicative transaction in which person A attempts to communicate an image to person B. The basic steps are: transmission-alignment-reception-verification-confirmation.

Figure 5. Video observation, brain imaging, and surveys provide three perspectives for observing the design activities. Computer simulation provides a way to analyze the data, develop a better understanding of the interactions, and make more informed decisions about interventions.

Summary

As we mentioned in the beginning, our aim was to make a sketch of future research by building on past empirical work in the context of modern tools. In so doing we have described a scenario whereby the improvements and availability of better tools to observe the workings of design teams will lead to an increase in the accuracy and reliability of our models of design and hence our predictions of design performance. Working from first principles, such a science of design teams will not only enable us to develop new strategies for managing design teams it will also make it possible to develop better environments to support the process. In this future, it appears to us that the quality of the outcome will be judged by both process and product variables - that is both the quality of the final product and the design team's subjective experience of the process, including the quality of their communication.

ICED 01 - C586/477

471

References [1] Gunther, J., Ehrlenspiel, K., "How do Designers from Practice Design? What can Design Methodology Leam from Them? How can Design methodology Support Them?," in Designers - The Key to Successful Product Development, Frankenberger, E., Badke-Schaub, P., Birkhofer, H., (eds), Springer-Verlag, 1998. Eisentraut, R., Gunther, J., "Individual Styles of Problem Solving and their Relation to Representations in the Design Process," Design Studies 18, pp 369-383, 1997. Wilde, D.J., Berberet, J., "A Jungian Theory for Constructing Creative Design Teams," in proceedings of the ASME conference on Design Theory and methodology, pp 525, Boston, MA, 1995. Frankenberger, E., Badke-Schaub, P., Birkhofer, H., "Factors Influencing Design Work: Empirical Investigations of Teamwork in Engineering Design Practice," in proceedings of the International conference on Engineering Design, Tampere, Finland, August 1921, 1997. Goker, M.H., The Effects of Experience during Design Problem Solving," Design Studies 18, pp 405-426, 1997. Tang, J., Leifer, L.J., An Observational Methodology for Studying Group Design Activity, Research in Engineering Design, v2, pp. 209-219, 1991. Leifer, L.J., Design Team Performance: Metrics and the Impact of Technology, in Evaluating Organizational Training, Brown, S.M., and Seider, C., (eds), Kluwer Academic Publishers, Netherlands, 1998. Carrizosa, K., and Sheppard, S., "The Importance of Learning Styles in Group Design Work." Proceedings, Annual Frontiers in Education Conference. ASEE/IEEE, Kansas City, T2B 12-17, 2000. Felder, R., and L. Silverman "Learning and Teaching Styles in Engineering Education." Engineering Education, 674-681, April 1988.

[2] [3]

[4]

[5] [6] [7]

[8]

[9]

[10] Brewer, J.B., Zhao, Z., Desmond, J.E., Glover, G.H., Gabrieli, J.D.E., "Making Memories: Brain Activity that Predicts How Well Visual Experience Will Be Remembered," Science 281, 5380, pp 1185, 1998. [11] Mabogunje, A., Leifer, L.J., Levitt, R.E., and Baudin, C., "ME210-VDT: A Managerial Framework for Improving Design Process Performance", Frontiers in Education Conference, Atlanta, Georgia, 1995. [12] Galbraith, J.R., Organization Design: An Information Processing View, Interfaces,4,2836,1974 First authors name: Ade Mabogunje Institution/University: Stanford University Department: Center for Design Research, Department of Mechanical Engineering Address: 560 Panama Street, Stanford, California 94305-2232 Country: USA Phone: 1-650-725-0150, Fax: 1-650-725-8475, E-mail: ade@cdr.stanford.edu IMechE 2001

472

ICED01-C586/477

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DIMENSIONS OF COMMUNICATION IN DESIGN

C M Eckert and M K Stacey

Keywords: Design teams, collaborative design tools, computer supported cooperative work, design information management, taxonomies, ethnography.

1 Introduction
In industry designers interact and collaborate with each other in many different ways, often on the same day. Many of these different types of interaction can be supported effectively with computer tools - but a tool must meet the needs of the situation it is used in. However research on collaborative designing and on design groupware often focuses exclusively on one interaction paradigm. This paper explores the variety of interaction in design by developing a set of dimensions for classifying design scenarios. It discusses a number of important interaction scenarios we have observed in our studies of design practice, and their implications for the development of computer support tools.

2 The Problem
The term design covers a large number of different activities. Designing as a mental process is the generation of a description of a new product, through a repeated cycle of reformulating the problem, synthesising a potential solution, evaluating it, and reformulating the problem again. However, design in its broader cultural sense includes all activities involved in the generation of a complex product. Many of these activities do not contribute directly to generating the product description, but instead to establishing the requirements it must meet or testing its properties. At present there is no complete taxonomy of different design tasks. Frost [1] provides a useful classification of design products, which can be used to assess characteristics of their design processes. While there are many attempts made to describe engineering design in general in taxonomic form [for instance 2], detailed taxonomies address only particular issues. For instance Ullman [3] classifies decision problems in design; and Kaplan et al. [4] are concerned with the information requirements of tasks requiring interaction between designers. In contrast to Kaplan et al. [4], we are looking at communication activities within large design processes, where the mode of collaboration is not necessarily predetermined by the task rather than by the organisational set-up. Medland [5] classifies communication activities into four types: delegation, reporting, awareness, and problem handling (for resolving conflicts between design elements or constraints).

3 Research on Design Communication

How designers communicate, and how designers could communicate, has been studied from a variety of different angles and intellectual perspectives. But discussions of collaborative

ICED 01 - C586/518

473

designing usually consider only a handful of activities; and support systems for cooperative design are developed for specific scenarios, when consideration of a wider range of uses could reveal a broader range of requirements and potential pitfalls.

3.1 Groupware for Engineering Design

A variety of computer technologies enable designers to collaborate effectively across long distances or when involved in large projects. Information management systems that support communication through record-keeping are one important strand of development, especially important in applying methodologies such as SSADM to software development. Other developments include systems for enabling participants in face-to-face meetings to share software and computer representations of information; and support for transmitting a variety of material including video messages through time and space to colleagues working separately, to replicate for message passing the resources available in meetings [6]. There has been extensive research on computer support for collaborative designing by remote designers using shared workspaces simultaneously. Systems are in commercial use that support video-conferencing, and working collaboratively on shared CAD models across the Atlantic. Successful research systems have provided a face-view video channel as well as voice, and allowed remote users to share sketches [for instance 7], and also desktop views and near-screen hand gestures. Research on shared workspace systems has both driven and been driven by experimental and observational studies of design meetings [notably 8, 9, 10].

3.2 Studies of Communication in Collaborative Designing

Research on design collaboration has largely focused on team meetings. Many studies have given a group a design brief and analysed the resulting design activities [see 11 for twenty detailed analyses of the same episode of collaborative design by various different researchers]. Design conversations almost always employ sketches, drawings, prototypes or other visual referents (but these can sometimes be imagined [12]). Communication in joint designing is multi-modal: speech, drawing and gestures are used in combination, with each channel used to explicate and disambiguate what is expressed in the others [8, 9, 10]. This multi-modal communication involves the use of argumentation strategies and rhetoric [10, 13, 14, 15], and subtle modulation of the degree of commitment with which a proposal is put forward [10, 15]. Minneman [10] points out that describing the design itself is just one aspect of design discourse. He classifies the content of design communication according to a 3-by-3 matrix: Communication can be about an artefact, or a process, or a relation (between individuals or groups, or between people and tools, rules, representations etc). It can describe the state (that something is now in), or how and why something got to be the way it is (making sense), or how something might or should develop (framing the future). There has been extensive research on how using computer technology influences how people interact in meetings. One important finding is that people will exploit ways to communicate that don't exist in conventional face-to-face interactions. For instance by drawing or gesturing in the same place at the same time in a virtual workspace [7]. Another is that using group support systems influences what happens in meetings, but how they change what happens depends on both the technology and the purpose of the meeting; for instance decision-making is different from idea generation [see 16]. Minneman [10], Bucciarelli [13] and Henderson [14], among others, have studied large-scale engineering processes as participant observers. They report that complex designs are

474

ICED 01 - C586/518

developed largely through social processes of argumentation and negotiation. They view designs as arising through a process of negotiation between participants, where information is activity communicated and actively made sense of, rather than seeing it as passively flowing through an organisation. However this view downplays the role of designers working on their own and needing to communicate actively to pass on the results of their work. Henderson [14] shows that graphic representations play a critical role in structuring the design process and conveying information between people with different knowledge and responsibilities. Designers' learned representation-specific interpretation skills determine how and how much they understand - representations mean different things to people with different expertise.

3.3 Our Research on Design Communication

Between 1992 and 1997 we carried out an ethnographic study of design processes in over 25 knitwear companies in Britain, Germany and Italy, which was originally intended as a requirements analysis for an intelligent design support system. This found that the communication between knitwear designers and knitting machine technicians was a major bottleneck, and identified a variety of factors contributing to communication breakdown [17]. The most important were the difficulty of expressing designs clearly and unambiguously in the available representations, and failure to recognise communication problems. These findings have informed our studies of engineering design. In 1999 we interviewed 23 experienced designers and design managers in a study of the customisation process in helicopter design [18]. In 2000 we conducted a series of interviews in an automotive company studying design planning. Communication was not the primary target in any of these studies, but the aspects of design we studied depended on communication. While knitwear design is far less complex than engineering, with smaller teams and a much simpler product, it exhibits many of the characteristics of engineering design [17]. In knitwear design we could observe all aspects of the design process and see people communicating in different situations. It was only possible to talk to a small fraction of the participants in the engineering processes, who were all specialists in their fields. None communicated with colleagues in as many different situations as did the knitwear designers. In all the organisations we studied designers did some joint problem solving with other designers. For example all the knitwear designers in a company jointly work out a colour scheme for each season. But they develop conceptual designs for garments independently, and hand them over to technicians in the form of inaccurate, incomplete and inconsistent specifications; they only negotiate over the design when the technicians perceive that they cannot interpret the specifications accurately [17]. In the engineering companies we have studied, designs are handed over to colleagues with different technical expertise. The handovers are discussed in formal meetings, but often only by the bosses of the people doing the designing; if people knew each other, conflicts were sometimes resolved through local negotiation, but communication across organisational fields was always problematic [see 19]. What aspects of design the researcher studies is not independent of how a design process works. What gets done individually and what is done in meetings depends on the particular problem, but also on the structure and culture of the organisation. In large organisations and complex products, the complexity of the process inevitably leads to more handovers and information transmission between people who don't know each other. We have studied design cultures in which passing on specifications and other asynchronous communication is important. Had we looked solely at communication or at processes where the major participants design together in meetings, our study would have used methods more similar to the sociological studies mentioned above and come up with more similar findings.

ICED 01 - C586/518

475

4 Dimensions of Communication Situations

The situations in which designers interact vary in a large number of ways. The dimensions of variation we list below are not orthogonal: common situations have related values along a number of the dimensions. These different situations can create different types of communication breakdown; they influence how designers behave and what they need in the way of computer support for their collaborative activities. Form of Communication o Place: Participants are face-to-face vs participants are geographically remote. o Time: Communication is interactive in real time vs communication is asynchronous. o Size: Interaction between pair - interaction between many. o Identity: Recipients are known (conversation, private notes) - recipients are unknown (record keeping, subcontractors to be found, open audience). Form of Task o Objective of task: Generation of ideas or alternative solutions vs convergent problem solving vs decision making from alternatives vs acquisition or imparting of pre-existing information. o Division of decision-making: Joint problem solving - negotiated handover - sequential problem solving. o Hierarchy of decisions: Different participants' tasks are of equal importance - some tasks are subordinate to others. o Duration: Interactive or communicative activity is brief - activity is extended. o Information type: Facts, proposals, specifications vs opinions or judgements or prognoses vs problem-solving strategy advice (see section 3.2). o Time pressure: Task is time critical - task is not urgent. Subject Expertise o Equality of expertise: Participants have equal levels of expertise - Some participants are more knowledgeable than others. (One important interaction type is apprentice consults more experienced colleague.) o Balance of Expertise: Participants have shared expertise (and use the same concepts and can interpret each other's terms and representations) - participants have complementary expertise. o Mental representations: Participants conceptualise topic in similar terms - different terms. o Familiarity: Participants know each other - participants cannot make assumptions about others' knowledge. o Context: Participants share contextual information - participants have different (or no) knowledge of the context. Tool Expertise o Competence with groupware: Experienced frequent user (skilled and comfortable with using the medium) - novice or infrequent participant. Organisation o Hierarchy: Participants at same level of hierarchy - participants have different status. o Interest: Participants inside same company - participants working for different companies.

476

ICED 01 -C586/518

o Security: All information can be shared - some information must not be shared (for instance in dealings with suppliers, or with people without security clearance). Representation of information o Medium: Speech, gestures, hand drawn sketches, hardcopy printouts of text files or CAD models, web pages, shared files, physical objects such as prototypes... o Form of information: Text, data plots, tables, diagrams, code, photographs. . . o Notation: Some fields have alternative notational conventions for the same information.

5 Interaction Scenarios
Some of these dimensions determine most of the characteristics of an interaction situation. They define common interaction scenarios, which turn up in many different industries. These scenarios reflect typical work situations, which require their own computer support. One way to classify scenarios is by the way that the inputs to the tasks of the participants are related. Handover. One person undertakes a design task and finishes it is far as possible, then passes on the design to another specialist in a different aspect of the design, through a written or oral specification. The expectation is that the next person will do what is required within the specification rather than advancing the design by changing the specification. The participants are often co-located but communication is asynchronous. Later tasks are often seen as subordinate, so that two-way negotiations are excluded. For example, knitwear designers give their technicians specifications, without much discussion unless problems occur [17]. Such over-the-wall sequential design processes are still quite common in engineering, especially when designs are handed over to suppliers or contractors. Joint Designing. A group of people work on one problem together. Typically they work at the same time in the same room. Individuals might work on parts of the problems, but they have easy access to each other and discuss issues as they occur. Joint designing is typically done by groups of people with similar expertise, who are solving a problem that concerns all. The team members usually share a lot of background knowledge and awareness of context, and often get to know each other well. They can talk to each other spontaneously and get rapid feedback on their communication acts [see 8, 9, 10, 15]. For example knitwear designers work out colour schemes as a group, because they all use the same colour scheme. In engineering designers often work jointly during conceptual design when even a complex problem is addressed by a small group. Interface Negotiation. In concurrent design various people from different fields of expertise work on a design at the same time. Their tasks have mutually dependent inputs. To achieve full concurrency, they need to work with estimates of parameter values and negotiate to achieve mutually consistent solutions to their individual problems. In reality most processes give priority to some tasks and decisions, and stagger the beginning of the tasks. It is well recognised that concurrent design processes work best with colocated dedicated project teams. Communication occurs informally, through one-to-one conversations as well as in meetings.

Episodes of interaction can have a variety of purposes, even within a meeting with a different primary purpose. The types of discussion listed below can be about most of Minneman's nine classes of subject matter (see section 3.2).

ICED 01 - C586/518

477

Request for information. Designers frequently find they need more information, and usually their main source is their colleagues. Pure information request is more likely to occur in design handover or concurrent situations than in joint designing sessions. Negotiation for clarity and negotiation of constraints. The participants in a discussion must make sure that they understand each other's positions - that is, achieve compatible interpretations of the situation. This often requires understanding the constraints the others must meet, to understand what the constraints on their own activities should be. So negotiation for clarity often leads to a negotiation over constraints. This is particularly important when designs are handed over (not necessarily in a linear process) from one specialist to another who is doing an equally important task independently. Idea generation. In many design process that are essentially sequential, idea generation is undertaken as a joint activity in a meeting, because designers need each other's input before committing time and resources to any particular solution. Designers often reuse ideas from past designs or other sources; how much they refer to visual props depends on how much they need to explain ideas with reference to their sources. Conflict resolution. Meetings are often set up to resolve conflicts between elements of a design. This is typically done through real-time discussion. Conflict resolution situations vary according to whether there is an authority capable of arbitrating or imposing a decision on conflicting parties. Decision making. Much design comprises an exploration of possibilities followed by a decision on which avenue to follow. Decisions need to be made about what trade-offs to make, and often in conflict resolution, as well as about concepts. If individuals make decisions on their own, they have to justify them (see below). In meetings decision can be made jointly or by individuals higher up in the hierarchy. Justification. Designers must often justify their solutions or decisions, either orally in meetings or in reports. The recipient cannot be assumed to have the same knowledge as the person who has to justify the solution. Justifications may be made to equals, bosses or outsiders; and the explanations must be pitched to the recipients' understanding. Specific justifications are often necessary in handover activities.

Each individual engages in most of these communication situations as part of their normal work, possibly with the same people. Designers use different channels on different occasions to convey different kinds of design information. For example a designer might engage in joint problem solving with his boss in a face to face meeting involving conversation and sketches, when they are negotiating over the constraints on a particular problem. The designer then works on his own using a CAD system. When he has a question has sends an email message or picks up the telephone. Later he has to return to the boss to justify the design that he has come up with in another face to face meeting.

6 Implications for Engineering Groupware

No single approach to supporting communication is sufficient to handle the richness and variety of possible communication acts. Hence we should be suspicious of any assumptions that supporting formal meetings, or record management and transmission, or real-time interaction, is going to meet all the information transmission needs of a distributed organisation. However we can draw some lessons from studies of design communication.

478

ICED 01 -C586/518

As almost all design conversation refers to visual props, shared workspace systems are vital for distributed communication. Such systems should support sketching and gesturing as well as the use of formal documents and CAD models. Much communication centres on contextual information, especially about past designs and competitor products, and relies on all participants being familiar with this context. Support for rapid retrieval and display of archive information could make shared workspace systems much more effective. Here support for communication overlaps with long-term information management. Quick, casual, low-effort interactions are at least as important as organised meetings and formal information management - restricting them is potentially catastrophic. Hence it is essential for meeting support systems to support easy and rapid initiation of brief unscheduled interactions, especially if integrating informal interaction with information management activities is a desired objective. Graphic representations and models not only communicate information across divisions of expertise and responsibility, but also play an important role in structuring design processes [14]. Access to and control of representations through information management systems will affect the design process. If using a particular model or representation is essential, how can it be used in communication scenarios for which the system was not designed?

The range of alternative situations in which designers interact indicates that there is scope for computer support for cooperative designing that goes beyond efficient document retrieval or video conferencing technology and shared workspaces. Important issues include translation between alternative notations and graphic representations, enabling the less-informed members of a group to establish the context of the discussion quickly and efficiently, supporting awareness of other participants in remote interactions, and maintaining security. Acknowledgements The authors are grateful to the EPSRC, GKN Westland Helicopters Ltd and Lotus Engineering Ltd for their support of this project, and to the engineers who participated in it. References [1] [2] [3] Frost, R., "A Suggested Taxonomy for Engineering Design Problems", Journal of Engineering Design. Vol. 5 No. 4, pp. 399-410, 1994. Ullman, D., "A Taxonomy for Mechanical Design", Research in Engineering Design. Vol. 3, pp. 179-189, 1992. Ullman, D., "A Taxonomy for Classifying Engineering Design Decision Problems and Support Systems, Artificial Intelligence in Engineering Design. Analysis and Manufacturing. Vol. 9, pp. 427-438, 1995. Kaplan, S.M., Tolone, W.J., Bogia, D.P. and Bignoli, C., "Flexible, Active Support for Collaborative Work with ConversationBuilder", Proceedings of Computer Supported Cooperative Work '92. ACM Press, Toronto, Canada, 1992, pp. 378-385. Medland, A.J., "Forms of Communications Observed During the Study of Design Activities in Industry", Journal of Engineering Design. Vol. 5, pp. 243-253, 1992.

[4]

[5]

ICED 01 - C586/518

479

[6]

Minneman, S.L. and Harrison, S.R., "The DrawStream Station: a tool for distributed and asynchronous chats about sketches and artifacts", Proceedings of HCI'99, Munich, Germany, 1999.

[7] Bly, S.A. and Minneman, S.M., "Commune: a shared drawing surface", Proceedings of the Conference on Office Automation Systems, Boston, MA, 1990, pp. 184-192. [8] Bly, S.A., "A Use of Drawing Surfaces in Different Collaborative Settings", Proceedings of Computer Supported Cooperative Work '88, ACM Press, Portland, OR, 1988, pp. 250-256. [9] Tang, J.C., "Listing, Drawing and Gesturing in Design: A Study of the Use of Shared Workspaces by Design Teams", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1989. Xerox PARC report SSL-89-3.

[10] Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies of Group Engineering Design Practice", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1991. Xerox PARC report SSL-91-22. [11] Cross, N.G., Christiaans, H.H.C.M. and Dorst, K. (editors), Analysing Design Activity, John Wiley, Chichester, UK, 1996. [12] Eckert, C.M. and Stacey, M.K., "Sources of inspiration: a language of design", Design Studies. Vol. 21, 523-538, 2000. [13] Bucciarelli, L.L. "Designing Engineers", MIT Press, Cambridge, MA, 1994. [14] Henderson, K. "On line and on paper", MIT Press, Cambridge, MA, 1999. [15] Brereton, M.F., Cannon, D.M., Mabogunje, A. and Leifer, L.J., "Collaboration in Design Teams: Mediating Design Progress through Social Interaction", in [11], pp. 319341. [16] Huang, W. and Wei, K.K., "Task as a moderator for the effects of group support systems on group influence processes", European Journal of Information Systems. Vol. 6, pp. 208-217, 1997. [17] Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis and Computing Solutions", Computer Supported Cooperative Work. 2001. [18] Eckert, C.M., Zanker, W. and Clarkson, P.J., "Aspects of a better understanding of changes", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001. [19] Eckert, C.M., Clarkson, PJ. and Stacey, M.K., "Information Flow in Engineering Companies: Problems and their Causes", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001. Dr Claudia Eckert Engineering Design Centre Department of Engineering University of Cambridge Trumpington Street Cambridge, CB2 1PZ, UK Phone:+44 (0)1223 332 662 Fax:+44 (0)1223 332 662 Email: cme26@eng.cam.ac.uk IMechE 2001 Dr Martin Stacey Department of Computer and Information Sciences De Montfort University Kents Hill Milton Keynes, MK7 6HP, UK Phone: +44 1908 834936 Fax: +44 1908 834948 Email: mstacey@dmu.ac.uk

480

ICED 01 -C586/518

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21 -23, 2001

A STATISTICAL STUDY OF HOW DIFFERING LEVELS OF DIVERSITY AFFECT THE PERFORMANCE OF DESIGN TEAMS
A G Carrillo Keywords: Diversity, empirical study, design teams, design projects

Introduction

In recent years, diversity has become a popular area of interest. Today's business practices require multidisciplinary work groups in a constantly changing environment. The work force has also experienced a growth of ethnic diversity in its composition and that ethnic presence is expected to grow in the coming years. It is believed that the diversity of these groups will have positive affects on group creativity and performance [2]. Unfortunately, the effects on group process and performance are hard to measure and quantify. However, team diversity is considered a valuable resource [2] that has been under utilized and difficult to implement. Diversity can be defined as any attribute that can be used to differentiate one person from another [9]. Diversity includes demographic diversity, psychological diversity and organizational diversity [3]. Significant research in the last 40 years has explored how these differences affect the process and performance of work teams and how it affects those who manage these work teams. The majority of these studies are based on three basic theories. The theories are social categorization, similarity/attraction and informational diversity and decision making [9]. The results of this research have had mixed outcomes. Williams and O'Reilly have helped to summarize a large number of the findings in the area of demography differences within teams and its effects on team process and performance. In the paper's findings, group heterogeneity appears to have negative effects on group process while having mixed results on group performance. The effects on process include communication difficulties, task conflicts and group dissatisfaction. There has been no clear trend on its effects on group performance. Unfortunately, most of the work that supports diversity in performance has been conducted in the laboratory or classroom [9] Many diversity studies look at a single attribute of the team composition and investigate how that characteristic may have contributed to any differences in team performance. Additionally, studies look at the final results and may not look at how diversity may have influenced the performance of the team over time. Therefore, it is important to try to understand how diversity may influence the progress of the groups as well as the end effects on performance.

Purpose

The purpose of this study was to contribute to the research done in the study of diversity and its affects on team performance. It was also an attempt to explore multiple diversity

ICED 01 - C586/587

481

characteristics and see if these differences would have varying affects on the teams' performance and present those differences in a quantitative manner. Since engineering projects can last for such a varying length of time, how the teams progressed was also studied. It was important to try to understand the effects of time and if any trends could be uncovered that would not have be seen with a single measurement.

Method

Since the backgrounds of work team members are becoming more diverse, it is important to understand how varying diversity variables may in fact change the outcome of a team's performance. In an effort to understand these influences, a study was conducted to monitor a team's diversity and track the group's performance over time. For the academic years of 1994-95, 1995-96 and 1996-97, design teams in a Stanford University's mechanical engineering graduate design course were observed. The class studied is a three quarters long project based course with industry sponsorship. This format allowed for multiple performance checks with equitable time milestones and real life projects. Due to the duration of these projects, the team composition was team selected, allowing students to choose whom they worked with during the project. Team heterogeneity was encouraged but not enforced. Different criteria were established in order to provide a means in which to study the teams. The criteria were size of the team, the diversity of the team and grades as a measure of their performance. In an attempt to quantify a team's diversity, 6 different criteria were identified and the requirements to meet each criterion were established. The students were asked to take a brief sampling of the MBTI (Meyers-Briggs Type Indicator) questionnaire in an attempt to identify the student's "Preference Group [8]." The remainders of the group's diversity characteristics were identified using information provided by students at the time of project selection and from end of quarter documents written by the design teams. The teams' grades were recorded and kept throughout the year. The grades were used as the measure for team performance. An analysis was then performed to determine if the teams' performance was affected by the diversity of the group.

3.1 Team size

In an effort to limit variability amongst teams in this study, a team size criterion was established. The class had roughly 45 students per year, with teams averaging 3-4 members per team. Teams started off with 2, 3, 4 or even 5 members at the beginning of the fall quarter. Due to outside influences, teams sometimes lost members during the year and so these numbers changed. Sometimes people were added to teams and some groups combined with other groups. In order to ensure sufficient team dynamic influences and resources, a team had to finish the course with 3 team members at the conclusion of the spring quarter. Additionally, all members had to be a part of the team for at least 2 quarters, allowing for change but requiring sufficient team unity. There were on average 12 teams that met this criterion each year. Any team with 5 members was not included in this study.

3.2 Diversity points

In an effort to quantify the teams' diversity, each team was given a diversity point value/score. Six different diversity variables were identified. Each team was given a score of 0 or 1 depending on whether or not they met a variable's criterion. The team's total diversity

482

ICED 01 - C586/587

was then calculated by summing up the individual points. The minimum value was 0 and the maximum was 6. The variables and the criteria are as follows. Gender Due to the continually growing impact of women in engineering, it is important to understand how gender may affect the performance of work teams. This class had a limited number of women that participated in the class, so a team was considered to demonstrate gender diversity if at least one member of the team was a woman. However, at least 1 male must also be on the team in order for a team to receive this diversity point. In this study, it was rare for a team to have more than one woman. Ethnic Background The ethnic background criterion is a common demographic diversity factor. The students were categorized using the same ethnic categories that are used by the university's admission application. The main focus in this variable is that students have different backgrounds. Therefore, students from other countries were considered to be different from other ethnic backgrounds. For a team to meet this criterion, every member had to be from a different racial category or be from another country. Personality Preference In an attempt to address the psychology diversity influence, the personality preference questionnaire (brief sampling of the MBTI questionnaire) results were used to categorize the students into different preference groups. With Doug Wilde's direction and use of his personality preference scheme, the students were categorized into 4 distinct groups. They were labelled North (PG IV), South (PG III), East (PG II), and West (PG I) personality types [8]. The East and West styles are described as having almost polar working styles while the North and South styles are portrayed as having mediating qualities. In order for a team to receive the personality preference point, the team had to have an East and a West personality type on the team and a North and/or South group member. Distant Membership Stanford University has created a program, Stanford Instructional Television Network (SITN) (http://scpd.stanford.edu). that allows technical professionals to participate in Stanford classes while remaining offsite. This class has included several off campus/remote students from this program. Students from other universities have also been encouraged to participate in the class as fully functional teams, or team members. Distance can cause unique working difficulties for work groups [1]. To receive this diversity point, one member of the team must have been an SITN student or from another university for the duration of the project. Work Experience In order to address the differences in tenure/experience, work experience was included as an area of diversity. For the team to receive the work experience diversity point, at least half of the team must have had prior work experience. For a team member to claim prior work experience, the person must have worked full time for at least 1 full year. A person working 4 summers for the same company was not considered to have met the requirement. Although the experience is very valuable, it was not considered equal to a full year of work experience. School/Education Each team member must have attended a different college or university. If any two members attended the same college or university for their undergraduate schooling, the team did not

ICED 01 - C586/587

483

receive the school diversity point. It is assumed that by attending different schools, the team members will have different educational experiences and will bring different technical skills.

3.3 Grades
In academics, grades are a common measure of performance. Therefore it was important for this study to ensure that the grades received were indicative of a "team's" performance and that all students had a similar grade motivation. Students may participate in this course in a credit/no credit basis. For a team to be included in the study, all team members had to receive a grade in the course. This was to ensure that all members would be equally affected by the outcome of the project and the grade received by the team. In the first quarter, there are two parts to the course. The industry projects are introduced in the second half of the first quarter and only these grades were included in the study, so the fall quarter grades are indicative of 5 weeks of work by the teams. Grades are measured with a 5 point scale breaking down to:
Table 1. Breakdown of grade scoring

4.30 = B+ 3.30 = C+ 2.30 = D+

5.00 4.00 3.00 2.00

=A =B =C =D

4.70 3.70 2.70 1.70

= A= B= C= D-

The teams' final grades are weighted averages of grades on the physical hardware constructed by the teams, and the documentation of their design and the design process. The final step of the study was to gather all the information about the design teams and determine which criteria they met. The teams received a 0 or 1 for each criterion. The team was then given a diversity score by summing up the individual scores for each criterion. Each team's grades for the autumn quarter, winter quarter and spring quarter were calculated. The winter quarter's grade was not a major point for this study since the instructor used the winter quarter's grade as a progress report to the team. In fact, the instructor retroactively changed the winter grade to the same grade received by the team at the end of the project.

Results

Due to the small number of teams per year and the length of the projects, it is difficult to get a large sample size. However, some promising trends were identified. The teams were broken up into 3 categories: high, medium and low diversity. Groups with high diversity had diversity scores of 4-6 (14 teams). Low diversity groups had diversity scores of 0-2 (11 teams). The medium diversity group consisted of teams with a diversity score of 3 (5 teams). This group eventually had the most interesting outcome.

4.1 Fall Quarter Results

In just 5 weeks of work, there was an obvious difference between the performances of the teams. Table 2 shows the descriptive statistics for the groups' grades at the end of the fall quarter. Based on the mean scores, the high and low diversity groups were roughly equivalent in performance. However, the high and low diversity groups outperformed the middle

484

ICED 01 - C586/587

diversity group substantially. The results can be better displayed with box plots as is shown in Figure 1.
Table 2. Summary statistics of the diversity groups and the fall grades

Figure 1. Box plots of the diversity groups vs. fall grades

To look at the data more closely, the individual group scores were split into their respective 06 categories and new box plots were created. Figure 2 demonstrates an obvious trend. As the diversity scores approach the center of the diversity range, the average scores begin to drop. Only the groups with diversity scores of 4 do not follow this trend.

Figure 2. Box plot of individual diversity scores vs. fall grades

4.2 Spring Quarter Results

To see if time changes the results, the groups' spring grades were calculated and a new analysis was performed. The summary statistics for the categories are represented in Table 3.

ICED 01 - C586/587

485

For the spring, there was now a noticeable difference between all the groups. The high diversity groups showed the highest mean score, followed by the low diversity group, with the middle diversity group once again performing lower than the other two groups. Another interesting result is that the standard deviation of the high diversity groups was half the standard deviation of the other two categories by spring quarter. The middle and low diversity groups both showed an increase in standard deviation by the spring quarter while the high diversity groups actually decreased. The results can be better visualized in box plots shown in Figure 3.
Table 3. Spring Grades, descriptive statistics

Group High Medium

Low

n 14 5 11

Mean 4.41 4.06 4.22

SD
0.20 0.45 0.41

Figure 3. Box Plot of the diversity groups vs. spring grades

The distribution of the high diversity groups was much narrower in comparison to the other twocategories. The individual groups' scores were once again grouped into their respective 0-6 categories to see if there was a discernible pattern. For the spring results, there was no obvious pattern as seen in the fall. In order to present the progress of the teams in a more understandable form, a graph was created that plots the mean grades of the diversity categories and maps the grades over autumn, winter and spring quarter (Figure 4).

Figure 4. The progress of the groups from fall quarter to spring quarter.

486

ICED 01 - C586/587

As the graph shows, there was a definite improvement by the high diversity groups over the low diversity groups. Although the two categories started off at a similar performance level in the fall quarter, by spring quarter the high diversity groups outperformed the low diversity groups. Another interesting observation is how the middle and high diversity groups improved roughly the same amount. Unfortunately, the low diversity groups started off so much lower than the other two categories that they never caught up.

Discussion and conclusions

The first conclusion is that the degree of diversity may strongly influence a team's performance. For both the fall and spring quarters, the teams with middle diversity scores performed poorly with respect to high and low diversity groups. This may have strong implications on how diversity should be implemented. If there isn't a strong push towards high diversity at team formation, it may actually decrease the performance of the team. As Lau and Murnighan introduced, faultlines may be responsible for the differences in performance. Both low and high diverse groups may have a smaller number of faultlines within the group, reducing the existence of subgroups that lead to group conflicts [4]. This may be extremely important in ensuring that the benefits of diversity can be fully utilized. Another benefit of high diversity groups is the reduction in the standard deviation of that category. The high diversity groups not only outperformed the other two groups, but they demonstrated a smaller variation within the group. It is difficult to know exactly how diversity influences this outcome, but the benefits of this outcome can easily be seen. Time may also be a critical aspect of diversity studies. If the diversity study had ended after the fall quarter, it would have shown that there was no performance difference between the high and low diversity groups. However, after 2 and a half quarters, there was a noticeable difference between all three groups. This particular outcome may have much bigger implications. For shorter timed projects, team diversity may not be beneficial. In fact, if high diversity is not implemented, it may actually hinder teams. In summary, diversity influences the performance of a team. However, it may not always be positive or noticeable. It is important that high diversity be strongly encouraged and fully implemented and supported. Time may also be a factor in how effective that influence may be. Short term projects may benefit more homogeneous groups. Long term projects may benefit more from team diversity. Using these six variables to study work teams would be problematic in industry. These diversity factors are salient in a classroom setting, but difficult to identify in an organization. Additionally, the work environment is constantly changing, unlike the controlled environment of the classroom. Student team members did not work together throughout the day, limiting their interaction with one another. Finally, it is extremely difficult to measure team performance outside the classroom. This paper does not address motivation and group skills. These are important factors that have definite effects on team performance. These variables are difficult to measure and evaluate, but their influences should be considered in future work.

ICED 01 - C586/587

487

Acknowledgements

I would like to thank the students for their help in this study. Professor Larry Leifer's support of this study made it possible. I also thank Professor Doug Wilde for his help in determining the personality preferences for the students and in understanding his methodology.
References [1] Armstrong, D. J, and Cole, P. "Managing Distances and Differences in Geographically Distributed Work Groups". In S. E. Jackson and M. N. Ruderman (Eds.), "Diversity in Work Teams: Research Paradigms for a Changing Workplace" Washington, DC: American Psychological Association, 1995 pp. 187-215. Eigel, K. M., Kuhnert, K. W., "Personality Diversity and its Relationship to Managerial Team Productivity". In M. N Ruderman, M. W. Hughes-James & S. E. Jackson (Eds.), "Selected Research on Work Team Diversity". Greensboro, NC: Center for Creative Leadership 1996 pp. 75-98. Jackson, S. E. and Ruderman, M.N., "Diversity in Work Teams: Research Paradigms for a Changing Workplace". Washington, DC: American Psychological Association, 1995. Lau, D.C. and Murnighan, J.K., "Demographic Diversity and Faultlines: The Compositional Dynamics of Organizational Groups", Academy of Management Review. 23, 1998, pp. 325-340. Morrison, A. M., Ruderman, M. N. & Hughes-James, M., "Making Diversity Happen: Controversies and Solutions", Greensboro, NC: Center for Creative Leadership, 1993. O'Reilly, C. A., Williams, K. Y., & Barsade, S. G, "The Impact of Relational Demography on Teamwork: When Majorities Are in the Minority", Research Paper Series, Graduate School of Business, Stanford University, 1999. Ramsey, F.L. and Schafer, D.W., "The Statistical Sleuth: A course in Methods of Data Analysis". Duxbury Press, Belmont, 1997. Wilde, D. J. "Using student preferences to guide design team composition", Proc. DETC '97. Sacramento, 1997. Williams, K.Y. and O'Reilly, C.A. "Demography and Diversity in Organizations: A Review of 40 years of Research", Research in Organizational Behavior. 20, 1998, pp. 77-140.

[2]

[3]

[4]

[5] [6]

[7] [8] [9]

Mr Andrew G. Carrillo Mechanical Engineering Department, Center for Design Research, Stanford University, Bldg 560 Panama Mall, Stanford, CA 94305-2232, USA, Tel: 650 723 3795, Fax: 650 725 8475, email: andrewgc@stanford.edu IMechE 2001

488

ICED 01 - C586/587

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

REQUIREMENTS ENGINEERING - LAYING THE FOUNDATIONS FOR SUCCESSFUL DESIGN

G A Thomson

Keywords: Structure of requirements, customer satisfaction, concurrent engineering.

Introduction

The aim of this paper is to review Requirements Engineering techniques, which originate from the Systems Engineering domain, and describe their adoption within mechanical engineering design projects. The motivation for using these techniques is to provide improved recognition of customer and end user needs at the outset of a project and then to manage and control the use of requirements information throughout the project lifecycle. The techniques offer benefits particularly to projects with high levels of complexity and concurrency and can assist in supply chain management. The paper outlines the Requirements Engineering process, from the front-end requirement development activities through to the management and change control of requirements. A key benefit of these techniques is to establish traceability from the original customer need and system specification through the project lifecycle to the completed deliverables and acceptance criteria. This provides a method for rigorously assessing the impact of change to a project's requirements. The techniques have been successfully implemented in the design process for projects in the aerospace, defence and general equipment sectors.

The Importance of Requirements

The processes by which customer requirements are converted into a tangible outcome - the product - may not always be well defined, understood or managed. Development and agreement of requirements that properly reflect a customer's need is a skilled process that may be underestimated in terms of the degree of difficulty or investment required. In addition, problems often occur with the definition of adequate acceptance criteria, identification and control of change and the introduction of unnecessary or over-specified requirements. Failure to address any of these issues leads to degraded customer satisfaction and possible cost, schedule and performance penalties. Whilst there is considerable anecdotal evidence that this is true, published analyses of project under-performance related to requirements deficiencies are difficult to obtain. This is partly due, perhaps, to an historical under-recognition of the importance of this aspect of the engineering process or perhaps unwillingness by many organisations to reveal potentially sensitive commercial information. However, the following examples provide evidence of how poor requirements processes result in a detrimental impact on project performance.

ICED 01 - C586/177

489

The Standish Group's "Chaos" report [1] is oft quoted as an example of how badly captured and managed requirements in software projects lead to poor performance. The report contends that, during the early nineties in the US, a staggering 84% of software projects failed to achieve their budget or schedule and of this number more than a third were cancelled outright. The three most significant reasons determined for this by the research were lack of user input in developing requirements, incomplete requirements and changing requirements. Hooks [2] suggests that there is a correlation between the effort (or lack thereof) expended in developing a good project definition, including an adequately documented requirements set, and the likelihood of the project to suffer cost overrun. Moreover, the increased costs are directly attributable to the large number of requirement changes that occur late in the project lifecycle. Analysis of the history of a number of NASA programmes supports this assertion and is illustrated in Figure 1 which shows the relationship between poor requirement definition and likely project overrun.

Figure 1. Relationship Between Poor Requirements and Project Overrun

A corollary to the argument that late changes to requirements lead to project cost overruns (the worst case usually being post-production changes) is the potential to reduce programme risks and costs by developing a detailed a requirement specification as early as possible in the project or product life-cycle. Obviously, the ability to produce a refined requirement set is also dependent on the nature of the project and is bound to issues such as technical risk and other external factors. These problems are exacerbated in design projects involving high levels of complexity. However the best possible definition of requirements at the earliest stage and their subsequent refinement is a potent risk reduction process.

Requirements Engineering

3.1 Systems Heritage

Systems Engineering is a discipline that has emerged from the need to manage the development and integration of complex systems. In the 1960s, the design of increasingly sophisticated technological systems was plagued by difficulties in achieving cost, schedule and performance targets. This was particularly true of software projects, defence equipment and spacecraft design [3]. Systems Engineering provides a structure for managing and implementing complex technology programmes throughout their lifecycles [4]. It can be described as a structured approach to product development that recognises the importance of requirements, system integration, planning, organisation, testing and acceptance processes [5]. These principles are equally relevant in concept (if not in detail) to development projects from

490

ICED 01 - C586/177

the very large and complex down to a relatively small scale. The effective application of System Engineering is a skilled discipline and requires a committed organisational investment to achieve. A key process in system design is verification (i.e. confirmation of the user and system requirements and the detailed design by test). Verification (sometimes called validation) demonstrates that the system "does the right thing" as envisaged by the stakeholder requirements. Recognising that this must take into account the different levels of system design and integration gives rise to the system "V" diagram as shown in Figure 2.

Figure 2. Systems "V" Diagram - Matching Requirements to Test

A recent example of how a failure of the requirement process can have a serious impact is the ESA/NASA Cassini mission to Saturn [6]. The spacecraft was launched in October 1997 and is due to arrive in the Saturnian system in 2004. An important science element is the Huygens probe, which is designed to separate from the Cassini orbiter and then descend through the atmosphere and land on the surface of the moon Titan. Unfortunately, more than two years after launch, it was discovered that the communications link between the probe and the Cassini orbiter had insufficient bandwidth to return all of the mission data. This was due to an effect due to Doppler shift between the two spacecraft. The reasons for this error stem, to great extent, from a failure to assess the impact of a design change on subsystem requirements and to link these requirements to an appropriate test.

3.2 Definitions
The systems approach recognises the need to generate good quality requirements and the need to manage this information throughout the project lifecycle. This has given rise to Requirements Engineering which aims to develop a rational methodology for undertaking these processes. Note that there is confusion over the use of this term as some authors refer to the overarching requirement process as Requirements Management and Requirements Engineering has a different and more specific connotation. Wiegers [7] proposes a logical definition, which is adapted from IEEE conventions. This is that Requirements Engineering encompasses the entire domain of activities related to system requirements and it is divided into Requirements Development (the activities to create requirements) and Requirements Management (the activities to manage and control requirements). This is a useful distinction as it reflects the two broad ranges of activities that are required to establish an effective requirement process, see Figure 3.

ICED 01 - C586/177

491

Figure 3. Requirements Engineering Definition

3.3 Requirements Quality

Requirements Engineering is fundamentally a communications activity. Most of the difficulties in producing good requirements are related to getting this communications process right. This is bound to often very subjective issues related to interpretation, semantics, opinion and individual viewpoint. Resolving this requires the development of requirements data that is objective, well structured, concise and relevant to the level of detail of the system component being considered. Several key quality attributes of good requirements can be identified. These include: Lack of ambiguity - requirements must be understood in the same way by all project participants. Failure to achieve this leads to incorrect or wasted effort. Necessity - requirements must exist to ultimately fulfil the top-level user needs. If not, they are simply adding extra cost. Testability - fulfilment of requirements must be confirmable by some type of objective test otherwise it is impossible to demonstrate acceptance of the system. This implies that requirements must be reduced to single ("atomic"), testable statements of fact. Attainability - requirements must be attainable not only within the constraints of the laws of physics but also the business environment and time frame of the project. It is commonly stated that an important aspect of good requirements is solution independence. In other words, the requirement should not embody the design. This is not to say that preexisting design solutions shouldn't be taken into account (either as constraints or as templates for further requirements extraction) but they must not be built into the requirements set. As an aside to this, it is actually quite important to refer to candidate solutions during the requirement development process, as it is only possible to cost designs, not requirements. It is also possible to gather quality metrics (e.g. level of decomposition, linkage to test etc) during the requirements development activity to ascertain progress towards achieving a robust and high quality requirements definition.

3.4 Requirements Development

Producing quality requirements is a skilled process yet it is often the case that personnel involved in writing documentation such as a system specifications do not have any special skills or training to undertake such an activity. An effective Requirements Development process requires the extraction of requirements information from source documentation and domain knowledge experts using experienced facilitators. The raw requirements information

492

ICED 01 - C586/177

can then be analysed and structured into an effective requirements definition. Such a process is shown in Figure 4 and consists of the following phases: Capture - Sometimes called "elicitation", the collection of requirements information from the stakeholders (an important sub-set of which are the DKEs) and other relevant source data. Techniques such as brainstorming, interviews, questionnaires, scenario generation, QFD and Use Case can be used to assist the process. Analysis - The process by which the raw data captured in the first phase is converted into objective requirements statements. This involves reduction to atomic statements, assigning attributes, classification, sorting and determining priorities. This process requires further interaction with stakeholders and may use trade-off and technical studies to assist in refinement. Structuring - The final step is to structure and validate and the requirements. This can be supported by modelling techniques, for example Functional Modelling, to ascertain relationships and dependencies. Performance constraints can be added and quality metrics assessed.

Figure 4. Requirements Development Process

3.5 Requirements Management

Requirements Management is the complementary process to Development. As requirement information is developed, it becomes necessary to manage the resultant data to ensure that its integrity is maintained. The main Requirements Management processes are: Configuration Management - The process by which the current version status of the requirements data is identified and controlled. Usually each requirement is assigned a unique identifier (sometimes called the Project Unique Identifier or PUID). When the requirements data achieves an agreed level of maturity it is frozen or "baselined". Change Control - Requirements provide fundamental information by which a project will be ultimately accepted by its customer. Also change, particularly late in the project cycle, equals cost. It is therefore imperative that a Requirement Management system can prevent

ICED 01 - C586/177

493

uncontrolled change to baselined requirements data. It is also useful to be able to maintain a change history of the project. Traceability - A key requirement management activity whereby linkages are made between requirements at different levels (i.e. the high level need, user and system) to the emergent design requirements, standards and tests. This provides the capability to assess the impact of change. These activities can be implemented in different ways. For relatively simple projects, it is possible to use paper or word processor based systems and spreadsheet traceability matrices. However for many projects the evolving requirements data becomes too complex for these approaches and it is necessary to use a specialised database tool.

3.6 Tools
There are a large number of commercial tools available to support Requirements Engineering process. In fact Achrafi [8] identifies at least 35 different tools. They can be broadly classified into tools that support Requirements Development, Requirements Management or both. Development tools tend to provide process modelling capability (e.g. CRADLE, Rose and GMARC) whereas Management tools concentrate on maintenance of requirements data and are usually based on a database system (e.g. RTM, DOORS, Caliber, RequisitePro). It should be remembered that establishing a good requirements process is fundamental and should precede any decision regarding tool adoption.

Requirements in Mechanical System Design

4.1 Overview
The systems heritage of Requirements Engineering has been outlined above. Whilst the techniques are relatively generic, their promotion within mechanical engineering projects (with the exception of large defence hardware programmes) has thus far been limited. However, there is increasing recognition of the importance of systematic processes within the wider design community particularly through the adoption of Concurrent Engineering and modern Project Management techniques. A major user (and developer) of Requirements Engineering techniques is the Defence Procurement Agency via the Smart Procurement Initiative [9]. All new defence projects must have a properly managed requirements process. Another organisation adopting the techniques is Airbus which is adopting Requirements Engineering on its new aircraft projects including the A380 and A400M. The techniques are gaining recognition in other sectors including telecoms (e.g. mobile phone design) and consumer products. There are implementation issues that need to be considered for adoption within mechanical design environments. These include: gaining recognition for the up front requirements development work that must be done demystifying the jargon recognising the differences in the design processes between hardware and software systems.

494

ICED 01 - C586/177

4.2 Project Examples

The following examples are from the author's recent experience [10] and are provided to illustrate how requirements related techniques are being adopted. Aircraft Research Programme A European Commission funded fifth framework research programme to develop new construction techniques and technologies for future aircraft. The programme involves a relatively large number of partners and work packages from different organisations and European countries. One of the partners has used requirements management techniques to control the high number of requirements within their workpackage. This has improved project control and provided traceability between the project deliverable requirements, interfaces to other partners and verification tests. Safety Requirements Development A project involving the development of a nuclear site safety case at an existing defence facility [11]. The organisation responsible for developing the safety case introduced a requirements engineering process into their safety case development team. This was done via a seminar/workshop training programme and followed up by consultancy support. They elected to use a commercial requirements management tool to control the large number of safety requirements developed during the project. This approach established an audit trail through the safety case development activity, produced safety requirements that were testable and linked to regulatory acceptance, produced a systematic way of decomposing and evolving safety requirements and captured the thought process behind the safety case development. Technology De-risking Programme The conceptual design of a technology demonstrator to de-risk a proposed aircraft launch system that proposed the use of novel technologies. This project used a formal approach including Requirements Development activities to define User Requirements and System Requirements documentation linked to a proposed future development programme. This approach was designed to be compliant with the MoD Smart Procurement Initiative.

Conclusions

Requirements Engineering techniques offer significant advantages in terms of improving project performance and customer satisfaction. In fact, for the success of complex technology development activities, it is essential that an effective process to establish and manage requirements is established. Moreover, the use of requirements traceability offers the possibility of improved change control and impact analysis. This provides the design project manager with the ability to control cost and reduces the project lead-time. The techniques also allow improved communication within concurrent teams and design projects within complex supply chains. The techniques have been adapted from their software and systems heritage and are now being successfully used within general mechanical design projects.

ICED 01 - C586/177

495

References [1] [2] [3] [4] [5] Standish Group, The, "CHAOS Study", The Standish Group International Inc, January 1995. Hooks, I. F., "Managing Requirements", Issues in NASA Program and Project Management, 1991. MacDonald, J. S., "Systems Engineering: Art and Science in an International Context", INCOSE Symposium, 1998. Stevens, R et al, "Systems Engineering - Coping with Complexity", Prentice Hall, 1998. INCOSE and the AIAA Systems Engineering Technical Committee, "Systems Engineering - A Way of Thinking", International Council on Systems Engineering and the American Institute of Aeronautics and Astronautics, 1997. Link, D. C. R. et al, "Huygens Communications Link Enquiry Board Report", ESA/NASA, December 2000. Wiegers, K. E., "Software Requirements", Microsoft Press, 1999. Achrafi, R., "Requirements Engineering Tools", The Atlantic Systems Guild, 2000. Anon., "The Acquisition Handbook - A guide to Smart Procurement", Edition 3, Ministry of Defence, June 2000.

[6] [7] [8] [9]

[10] Thomson, G. A., "Requirements Engineering at INBIS", Requirements Focus, INBIS Technology Ltd and Integrated Chipware UK Ltd, 2000. [11] Cooper, D., "Safety Requirements Management Using a Database Technique", NNC Ltd, 2000.

G. Thomson INBIS Technology Limited 1 The Brooms Emersons Green Bristol BS16 7FD United Kingdom Telephone: +44 (0)117 987 4000 Fax: +44 (0)117 987 4040 Email: gthomson(5),inbis.com INBIS Technology Limited 2001

496

ICED 01 - C586/177

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

THE ORGANIZATION AND MANAGEMENT OF ENGINEERING TENDERS

G Barr, J H Sims Williams, S C Burgess, and P J Clarkson

Keywords: Competitiveness, Cost-estimation, Design reviews, Product planning, Risk analysis and management

Introduction

This paper outlines the current tendering practices of companies operating within the engineering industry and identifies potential areas where current methods can be improved. A tendering methodology is proposed which can potentially identify and evaluate the technical risks that engineering companies possessing stable product architectures are exposed to. As demonstrated by a case study, adopting the methodology will enable companies to re-use knowledge established during historical projects and employ that knowledge when evaluating risks inherent in tendering opportunities. The origins of many project risks can be traced back to defective decisions made during the tendering phase. Troublesome project issues can potentially be mitigated with improvements to the tendering process of engineering companies. There are many problematic issues that arise within the tendering phase, such issues are the scarcity of resources (either human or mechanical hardware), costing shortfalls, project over-runs, non-performances by in-house or sub-contracted resources or an inadequate detailing of the project scope. Models have been made of the tendering practices employed by engineering companies' [1][2]. Many of the methods proposed capture the specific tender process of a company and implement a rule-based method to capture the commercial decision-making activities. However, the study of capturing and evaluating technical data has not been widely covered. There are many approaches to evaluating the level of risk to which an engineering company is exposed during the preliminary stages of a project [3]. The two main questions that engineering companies are required to be confident of answering are: Can the project be delivered on time? Can the project be delivered within the cost budget? These two factors, time and cost, are inextricably linked. In general, the more resources that are assigned to a project the higher the project cost. However, assigning more resources to a project does not guarantee a project will be completed on time. The aim of evaluating the amount of uncertainty present in a project is to provide a method that aims to estimate and then deliver a project to budget and on time.

ICED 01 -C586/336

497

Current Tendering Practices

Interview Process The authors consulted with companies performing differing project roles (project managers, process consultants, design consultants) and operating in a range of engineering sectors (civil, mechanical, electro-mechanical). Detailed knowledge of each company's procedures was elicited from company representatives with extensive experience of their company's internal tendering practices through semi-structured interviews. Table 1' details the industrial sector and operational roles of the companies interviewed. By pursuing this evaluation process, the type of companies that would benefit most from employing a risk-based model incorporating the re-use of historical technical data for analysing tender uncertainty can be identified. It is intended that the method proposed can be adapted to suit the practices of many engineering sectors.
Table 1. Studied Engineering Companies

Company Elect-Mech-1 Elect-Mech-2 Elect-Mech-3 EngConsum ConPro ConDes-1 ConDes-2 ConDes-2

Industrial Sector Marine Power Systems Power Systems & Materials Mechanical Bulk Handling Engineering Consumables Construction Construction Construction Construction

Operational Role Electro-mechanical Designers & Contractors Electro-mechanical Designers & Contractors Electro-mechanical Designers & Contractors Mechanical / Electronic Design Consultants Civil Project Managers Civil & Structural Design Consultants Civil & Structural Design Consultants Civil & Structural Design Consultants

The studies were needed to understand not only the tendering practices of the companies but also to appreciate the market sector in which the companies work. By studying the operational role the company performs, the tendering operations and rationale of the company can be better understood. Modelling of the tendering mechanisms were made with respect to the company's: Operational Environment - Depicting the constraints of the engineering market in which the company operates. Tendering Practices - Depicting the operations of the company during the tender phase and subsequent project phase. The companies were assessed against ten subjective factors for each of the two models, on a scale2 of 1 to 5 with 1 = 'Very Low' and 5 = 'Very High'. The results of the evaluation process for each engineering company are relayed through presentation on two spider plots, displayed in Figures 1 to 4. The graphical plots demonstrate the tendering practices employed by the engineering companies balanced against their operational constraints. Similarities between engineering sectors and roles can also be identified through the use of the graphical representation.
1 The names of the companies involved have been disguised due to the commercial sensitivity of the subject matter. 2 The evaluation scale is further detailed with exact definitions attributed to 1-5 for each of the 20 factors however due to publishing constraints the exact definitions cannot be shown

498

1CED 01- C586/336

Figure 1. Operational Environment (Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 2. Tender Development (ConDes-1, ConDes-2, ConDes-3 & ConPro)

Figure 3. Tendering Practices (Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 4. Tendering Practices (ConDes-1, ConDes-2, ConDes-3 & ConPro)

Conclusions from Current Practices The graphical plots (Figures 1 to 4) highlight many similarities between the tendering practices of the companies based upon the nature and type of business environment in which they operate. We will focus on the issues related to the companies' technical bias and subsequent understanding of technical risk. All companies are shown to possess a comparatively unstructured base of historical technical data. It has also been observed that the reuse of this data is not particularly high during the tender phase. Similarly, the methods employed for evaluating the uncertainty associated with potential projects can be seen to be relatively unsophisticated. There is therefore scope for historical technical information to be used if a method can be suggested which is appropriate and delivers beneficial results. The companies that are required to undertake a high degree of technical detailing during their tender operations would be most likely to benefit as technical information can be collated during tender proposals and project with relative ease if an appropriate system is set in place. This would be easier to achieve within organisations that possess relatively stable product architectures. Solutions that such companies offer to clients typically contain relatively low amounts of original engineering content and high proportions of variant / adaptive design. Parallels between historical projects can thus be established with greater ease. The engineering companies can be classed according to their operational nature; illustrated graphically in Figure 5. The 'Solution Experience' scale indicates how familiar the company is with solutions they typically generate. For example, a design consultancy will typically take the client's original solution requirements and produce an original solution to meet their brief; the designs they generate are therefore unique. Due to the high amount of original working undertaken by these design consultancies and their limited experience in generating the product solutions requested of them, they do not possess a significant amount of historical data which could be utilised in future designs. Companies that undertake little original working in their projects tend to include small amounts of technical detail in their tender documentation. The practices displayed by organisations noted in Figure 5 as and CD are therefore unsuitable as the research is primarily aimed at reducing the technical risk exposure of engineering companies during the tender stage.

Figure 5. Classification of Engineering Roles

Industrial Case Study

The method of evaluating and documenting the technical risk present in the tendering practices of engineering companies is currently being tested with a large electro-mechanical company (previously noted as 'Elect-Mech-3') involved in the design and commissioning of large-scale bulk handling systems. As an approximation, the company typically tenders for about 10 projects per annum for its bulk handling system around the world. It will typically expect to win the contract to design and commission one or two of these projects. All systems of this nature consist of large sub-systems which must be designed and assembled to interact with each other. The sub-systems incorporated into the design of new tenders are mainly reused from previous projects. If a project contains an excessive number of elements which the company considers to be outside it's previous solution experience then the potential project will not be bid for. When tendering, the technical detail specified in the tendering submissions will be extensive. However, it has been noted that owing to tendering time and resource constraints there exists limited scope to fully assess the risks present within project bids.

A Risk-Based Tendering Methodology

Modelling cost and technical risk for engineering projects is complex and relies not only on explicit data but also on experience and judgement. Engineering companies must first decide whether to bid, and if so, then determine a suitable tender price. To proceed with a tender, an engineering company must have confidence that the uncertainties arising from the technical aspects of a project can be fulfilled. It is common practice within engineering companies to identify and evaluate the risks present within projects using a simple 'risk exposure' matrix. The probability of an event occurring and the impact of that event (should it occur) are used to highlight the 'acceptability' of a particular event. This method however can prove inadequate when modelling complex engineering projects. Firstly, project risks are separated from project tasks and objects making the correlation between risk and project models (e.g. work / product / organisational breakdown structures) difficult. Secondly, the similarities between project risks from one project to another can be hard to identify, thus reusing historical data can be troublesome. Crossland proposes a mechanism for the stochastic modelling of key design parameters during the conceptual stages of engineering design, particularly the modelling of project cost [3]. Historical technical data is used as the method inputs, however ensuring the accuracy of historical data is problematic. The method proposed here suggests that estimates used within the very earliest stages of design, in this case the tendering phase, should indeed be based upon historical data. The data should not however be used directly for input into an estimation tool, but as a recommendation to experienced designers as to the input values which should be used. In addition, the uncertainty associated with the estimate of cost for each task or object used in the estimation process should be based upon realistic evidence. A method is therefore proposed which identifies the tasks and objects (i.e. components, system assemblies, etc) that possess the greatest uncertainty. It is the aim of the methodology to facilitate the decision making process and ensure decisions are based on sound technical judgement. To accurately model technical information in a re-usable format, a system must be used which provides documentation of technical information in a form that compliments existing techniques and is applicable whether the project tasks or objects are related to design, manufacturing, assembly or construction, etc. Niwa states that the work in an engineering project can be broken down into 'work packages' [4]. A work package is defined in a two-

1CED 01 - C586/336

501

dimensional space which comprises standard project activities (i.e. procurement, installation, etc.) and standard objects (e.g. equipment or buildings, parts of the product model). It is proposed that the project modelling technique used by Niwa is modified and the concept of work package 'deliverables' introduced. Deliverables are a class of object which are produced when tasks are undertaken on objects to produce a product. Deliverables are not solely products that are deliverable to clients, they can also be internal deliverables and as such used again within the project model as objects belonging to a subsequent work package. During engineering projects, risk typically arises from the undertaking of project tasks in the physical creation or design of project tasks. A method has been developed which is effective in evaluating and ranking the complexity of each task and work package within a potential project. The method is centred on the work of Pahl and Beitz where work in engineering projects, in particular design work, can be said to consist of a combination of original, adaptive, variant or repeat content [5]. Project templates representing the company's range of solution configurations are used to create the initial project model. This model is then populated using information relating to common project tasks and interfaces from historical projects. The tasks from the model structure are studied and evaluated according to their original content and the strength of their interfaces with other project tasks. Risk profiles for each of the tasks within the project can therefore be produced in order to provide suitable preliminary information for the accurate stochastic modelling of project cost. The project tasks are ranked according to their effect on and sensitivity to other project tasks providing the technical team with an understanding of the risk of the proposed project. The difficulty in generating a solution for each individual task, described as the 'Solution Complexity', is evaluated during the tender by the technical team. The project tasks are assessed according to the originality of the task and classified according to the rating scale as follows: 1. Near 100% repeat working. 2. Low amount of adaptive / variant working. 3. Moderate amount of adaptive / variant working. 4. High amounts of adaptive / variant working. 5. Very high amount of adaptive / variant working. The interfaces between project tasks identified are initially modelled using a Design Structure Matrix (or DSM) [6]. The reason for using DSM's is the ability of the method to map complex relationships inherent in engineering projects. By using the method, the relationship between different project tasks can be seen to be defined as independent, dependent, interdependent parallel or interdependent coupled. The matrix is used to capture the task interfaces as demonstrated in the example detailed in Figure 6.

Figure 6. Example DSM of Elect-Mech-3 Hopper Design Tasks

502

ICED 01 - C586/336

Simply stating the interactions between tasks in the model is not enough. The interface between the tasks must be evaluated on two levels. These two criteria are the level of dependency that exists between tasks and the originality of the interaction. For example, when considering the case of interface originality assume that undertaking a design task, Task A, affects another design task, Task B, and both Tasks A and B have been performed many times before and essentially involve repeat working. The tasks are therefore linked (A-B). However, both tasks have never been undertaken together during the same project. Thus, there exists a potentially a high degree of risk associated with the interface between the tasks. The uncertainty concerning this interface must therefore be assessed in order that its affect on the project can be evaluated. The originality of the task interface is therefore evaluated on a scale of 1 - 5 with T equivalent to 'very low originality' and '5' to 'very high originality'. The strength of the dependency is essentially the measurement of reliance between the affected task and influencing task. The dependency which exists between the influencing and affected task is also evaluated on a scale of 1 - 5 with '1' equivalent to 'very low dependency' and '5' to 'very high dependency'. By using the evaluations given regarding the complexity of a task's predecessors and interface characteristics, the sensitivity of the task to its predecessors can be qualified. The task's sensitivity to previous solution derivations proving unsuccessful can be identified using Equation 1. This score is used to highlight how sensitive the particular task is compared to other tasks in the model. A list is established for all project tasks ranking their sensitivity in relation to the other project tasks. The location of uncertainty within the project can thus be identified. In a similar manner, the task's influence on other tasks in the project can be qualified using Equation 2 and a ranking of the influence of project tasks established. This list will highlight the tasks with the potential to generate risk within the project. Equation 1:
Where: T, = Sensitivity Rating of Task Tf = Influence Rating of Task T0 = Originality Evaluation of Task T'a= Originality Evaluation of Task Influencing the Task under consideration Td = Task Dependency Evaluation 10 = Interface Originality Evaluation T'd= Task Dependency Evaluation of Task Influenced by Task under consideration I'0 = Interface Originality Evaluation of Task Influenced by Task under consideration m - Number of Tasks Influencing Task under consideration n = Number of Tasks being Influenced by Task under consideration

Equation 2:

The levels of risk present within work packages can also be derived from studying the risk of each of the tasks within a work package. Comparisons can therefore be made with other work packages within the current project and also with the levels of risk noted in similar work packages from historical projects. The primary benefit of using the evaluation methods are realised when attempting to quantify the estimated project cost using stochastic methods. The methods of working and technical detailing employed by the studied company during tendering have been found to be consistent with the project modelling configurations proposed. The study of applying the methodology on a historical tender for a rail-based bulk handling design has been undertaken and their design process mapped onto the work package structure. In addition, the risk evaluation method is noted to provide considerable benefits in

ICED 01 -C586/336

503

generating a cost and risk profile for bulk handling projects without compromising the organisation's limited time and resources.

Conclusions

This research paper identified the key areas where engineering companies can improve tendering practices. It was observed that engineering companies which design systems with stable product architectures can be aided by employing a risk evaluation method as a basis for addressing the costing of their projects. By identifying the technical interfaces present within engineering projects when tendering, the risk exposure of a company can be reduced at an early stage. It has been noted that the primary means to reduce tendering uncertainty however requires organisations to store tendering information in a re-usable format. The developed methodology provides a valuable evaluation means for engineers to report their perception of the risk levels present in the tendering opportunity back to those making the commercial tendering judgements. It is anticipated that the research will enhance the risk management procedures employed by UK engineering companies and improve their relative competitiveness. Additionally, by improving the efficiency of the tendering process, the risk levels to which companies are exposed is reduced, thus aiding long term organisational competitiveness. References [1] Phythian, G.J. and King, M., "Developing an expert support system for tender enquiry evaluation: A case study", European Journal of Operational Research. Vol. 56, 15-29, 1991. Fayek, A., "Competitive Bidding Strategy Model and Software System for Bid Preparation". Journal of Construction Engineering and Management. Vol. 124, No. 1, 110,1998. Crossland, R., "Risk in the Development of Design", PhD Thesis. University of Bristol, 1997. Niwa, K., "Knowledge-Based Risk Management in Engineering: A Case Study in Human-Computer Co-operative Systems", John Wiley & Sons :New York. ISBN 0471-62893-X, 1989. Pahl, G. and Beitz, W., "Engineering Design: A Systematic Approach", The Design Council :London. ISBN 0-85072-239-X, 1988. Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D., "A Model-based Method for Organizing Tasks in Product Development", Research in Engineering Design. Vol. 6, No. l, pp. 1-13, 1994.

[2]

[3] [4]

[5] [6]

Gordon Barr Design Information Group, University of Bristol, 83 Woodland Road, Clifton, Bristol BS8 1US, Tel: +44 (0)117 9288914, Fax: +44 (0)117 9288912, E-mail: gordon.barr@bristol.ac.uk. IMechE 2001

504

1CED 01 - C586/336

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

MODIFICATION OF A METHODOLOGICAL DESIGN TOOL FOR THE DEVELOPING COUNTRY SCENARIO - A CASE STUDY IN PRODUCT DEFINITION
K M Donaldson and S D Sheppard

Keywords: Product definition, developing countries, sustainability, economic viability of new technologies, SMEs

Introduction

Product design for developing country markets sees additional and different constraints than the parallel process in an industrialized economy. This paper examines the donor-driven model of technology development by evaluating a DfX (Design for "X") product definition methodological tool, the Product Definition Assessment Checklist as implemented by an EastAfrican non-governmental organization (NGO). The modifications necessary to make the Product Definition Assessment Checklist applicable are discussed along with lessons that can be taken away for donors and product designers in both industrializing and developing countries.

Background

2.1 The Product Definition Phase

Product Definition, in this paper, will be defined as the first phase of the product development process based on the works of Ullman [4] and Ishii and Kmenta [3]. Wilson defines this phase as "the product development effort between the start of the project and the review meeting when the organization decides whether or not to invest in developing the product" [7]. At all stages of the design process methodological tools exist to assist designers. The standard output of the product definition phase is typically a list of specifications based on user needs. The product definition phase, however, can be academically reduced to subphases: need-finding, bench-marking, and priority setting; each with appropriate methodological tools that leads designers to the product definition statement. Wilson argues that a complete product definition should outline the product risks, the process development plan, the product channel plan, and the support plan of the company [6,7]. The product development organization must also recognize risks due to and constraints in the current market and in its own institutional structure. An effective product definition statement should then set forth the project priorities by identifying the goal(s) based on internal and external constraints, comprehensively defining the user need, and delineating the value to be delivered in the product [3].

ICED 01 - C586/410

505

2.2 Characterizations of a Developing Country

Manufactured household products sold in developing countries typically arrive at the market by one of the following four product development modes. The product is: 1. reverse-engineered and crudely reproduced by roadside artisans (the informal sector), 2. designed and produced in small quantities by medium- to large-sized manufacturing firms (the domestic formal sector), 3. imported (designed and produced outside of the country), or 4. designed by a donor-funded NGO (non-governmental organization) then passed off to local manufacturers to be produced. In the first two cases a full execution of the design process is impossible or unreasonable due to the dearth of capital and inadequate entrepreneurial and technical skills, resulting in a limited product variety that inadequately meets customers' needs. Locally-made products in countries like Kenya face stiff competition from and displacement by imported products from India and China (case 3) that subsidize their domestic manufacturing sectors to ensure competitive advantage in foreign markets. These cheaper imports are understandably less suitable at fulfilling needs, but nonetheless find a ready market in a society where comfort ranks far lower in terms of customer priorities. The abbreviation of the design process due to lack of resources most often occurs at the front end: the product definition and the conceptual design phases are skipped; imports are reproduced, typically without modification to address local consumer needs. The reason is comprehensible there are no resources to risk on an "unproven" or "original" product. In contrast, designers and engineers in industrialized economies, however, recognize the importance of the product definition stage where the voice of the customer, needs, and specifications are captured. Inappropriate decisions resulting from a poorly defined product significantly increases costs and risks the product's viability [4].

2.3 Donor/NGO Technology Development Model

The fourth case of product development is presently limited, but is the most encouraging path of product development because resources exist to permit the full design process necessary to produce a product that meets the local users' needs. The donor/NGO model of product development resembles the product development firm in an industrialized economy. Because small- to medium-sized manufacturers (SMMs) often lack the capital and skills to determine customer needs, northern1 aid or donor organizations provide resources to specific southern NGOs for market research and technology development. This parallels the heavy initial capital investment in market research that an industrialized firm makes at the start of the product development process. In past donors have also engaged in technology development themselves, but with highly-publicized dismal results, and the growth of locally-situated southern NGOs, the development efforts have been shifted from the donor to the NGO. This "corporate" product development model represents a fundamental shift in foreign aid thinking: for a product to sustainably improve the lives of the consumers, it must be marketdriven. Once a product is developed by the NGO, it is then passed off to local manufacturers,
"Northern" corresponds to industrialized societies; "southern" to developing countries or newly emerging economies.

506

ICED 01 -C586/410

distributors, and retailers. If the product is economically viable (i.e., affordable and offering value to the user), its production and market are sustained although the donor and NGO have exited the project. Although NGOs (with donor assistance) and donors have the resources to implement and are in the position to influence local manufacturers by proving the benefit of a market-driven product development process, this is infrequently effectively accomplished. NGOs typically lack technical personnel with formal product development and design process experience.

2.4 Definition of "product"

A product is defined as a physical artifact and/or a service, or no action. Following some need-finding scenarios, it may be determined that no action is the best solution at the current time given the possible ramifications from all other options.

2.5 Methodological Design tools and PDAC-1

Methodological tools to assist designers and encourage the success of manufacturing enterprises can be broadly categorized as DfX (Design for "X") tools. DfX tools2 such as those falling in to Design for Manufacturability (DfM), were developed (implicitly) for firms operating in industrialized economies, where success is increased profits by providing better value to the customer through increased economic efficiencies in production and design. Given the constraints of engineers and manufacturers in developing countries, why would it be desirable or useful to employ methodological tools? Considering that DfX tools are not without drawbacks, this is a particularly pertinent question. DfX tools are attractive to southern design situations for two reasons. First, DfX tools particularly assist designers who lack formal design experience, and are removed from the consumer (not just geographically, but also culturally, economically, and educationally). Second, the nature of the NGO and donor relations is such that the NGO must account for all resources to ensure continuity. The Product Definition phase of the design process is the appropriate phase to examine methodological tools for usefulness to the southern scenario as affordable products there poorly address consumer needs. Wilson mapped the processes that successful and unsuccessful project teams used to create and manage their product definitions. The Product Definition Assessment Checklist (PDAC-1) resulted with a list of fourteen3 critical factors [7] for design teams to consider and address in the product definition phase: 1. Strategic Alignment: the design team understands the objectives of the project. 2. Project Priorities: the feature set, retail cost, and time to market are determined to be constrained, optimized (given the constraint), and accepted. 3. Resources: Necessary staffing and funding is available. 4. Management Leadership: Management hierarchy is supportive and unified. 5. Dependencies: External and internal project dependencies are functional. 6. Competitive Analysis 7. Product Positioning: The product offers value to the intended market.
This paper considers only methodological tools The checklist items are reordered from Wilson's original listing.

ICED 01 -C586/410

507

8. Core Competencies'. Necessary core competencies are identified and accessible 9. Understanding Users' and Customers' Needs 10. Risk Management: the design team understands the risks being taken. 11. Localization: the design team understands variations in needs and compliances 12. Compliances: compliance standards are recognized 13. Business Model/Financial Analysis: The financial and project plan is complete. 14. Market Channels: Appropriate channels for distribution exist.

Hypotheses
Methodological design tools are applicable (with modifications) and potentially useful to the donor-driven product development process in developing economies. The modifications necessary to make a tool applicable will highlight considerations for design teams developing products working in both industrialized and developing scenarios.

This paper puts forward two hypotheses:

Application of PDAC-1 to a Developing Country Scenario

The Product Definition Assessment Checklist (PDAC-1) was evaluated for a developing country scenario by applying it in the product definition stage in the design of a product to assist rural farmers in central and Southwest Kenya access groundwater. The development organization is an East African NGO, headquartered in Nairobi, Kenya, with the purpose of promoting sustainable employment and economic growth by researching, developing, and promoting technologies appropriate for small-scale manufacturing enterprises in East Africa. Funding for the project is provided by a European bilateral aid organization. While this NGO is a forerunner in its field, this project is representative of the donor/NGO model where product research and development is donor-supported with the technology then passed off to the private sector for manufacture, distribution, and sale. The NGO design team4 was composed of four engineers: 3 expatriates and 1 Kenyan. All of the engineers hold advanced degrees in mechanical engineering with a range of experience (315 years) in product design and development in developing and industrialized countries. Team members were asked to rate the usefulness of the checklist items for applicability as is (no change to factor required), some applicability (minor change to factor or extended meaning required), non-applicability (factor may be ignored), and completeness (additional items required). A modified PDAC, PDAC-2, for the developing scenario resulted. The NGO design team evaluated the PDAC-1 individually then discussed it with the primary author and other members in a group setting. The exercise was structured in the context of
The NGO design team is not representative of most product development teams in the donor/NGO model. A typical team may have one engineer with limited to minor technical experience in a developing or industrialized country. Other team members may be "handy" individuals with vocational skills and/or social scientists.
4

508

ICED 01 -C586/410

the stated needs of the rural farmers. The team had previously completed the preliminary stages of the product definition phase. Each PDAC-1 item's level of usefulness was determined by informal group consensus intermixed with general discussion. The exercise lasted approximately 2-1/2 hours with roughly equal participation by all team members. The notes for each checklist item were then synthesized to create the modified PDAC-2.

PDAC-1 to PDAC-2

Although the discussion of PDAC-1 was framed within the context of a specific project, the design team's recommendations for modifications resulted primarily from their experiences working on past product development projects. Team members' responses differed based on their varying past professional experiences: whether they had worked primarily in a developing country, an industrialized country, or both. Engineers with the less overall experience tended to notice discrete differences (e.g. "the bolts are in English and everything else is in metric!"). The more experienced engineers noted larger-scale issues and differences (e.g. "it is impossible to predict the resources we need for a project before we do market research and we can't afford to market research before we get the resources...").

Figure 1. Constraint groupings of PDAC-2 checklist items

Following discussion and recommendations for modifications, checklist items were mapped to three constraint groups: institutional, design team, and/or local. Institutional constraints are those related to the design team's support structure and funding source(s); however, external to the team, but philosophically influencing their operations. Institutional constraints in an industrialized scenario may be production schedules set by management to be consistent with corporate goals. Design team constraints are those internal and inherent to the design team, such as lack of experience. Local constraints are those external to design team and institution, which include the customer, and the industrial, economic and cultural environment(s). As shown in Figure 1, most checklist items overlapped.

5.1 Three Checklist Items

For each checklist item item, the original PDAC-1 question [5] was first listed, followed by the synthesis of the NGO design team's discussion, then if necessary, the modified PDAC-2 checklist item [2]. For this paper, three checklist items (boldface in Figure 1) were selected from each of the groupings: project priorities, core competencies, and localization. 2. Project Priorities
PDAC-1: Does the team have an agreed upon hierarchy of measurable priorities based on the required positioning? 1 (None) 2 3 (List established) 4 5 (List used)

ICED 01 - C586/410

509

Wilson uses a priority matrix in Figure 2 for the design teams to set the project priorities. The product feature set, retail cost, and time to market are prioritized with the determination of which should be constrained, optimized (given the constraint), and accepted. In the industrialized scenario, the design team's project priorities are typically determined by the corporate strategy for developing and marketing the product. However, in the developing scenario, priorities dictated by the donor-approved project plan may not match those that best serve the end user. Two matrices are therefore necessary to recognize the possibility of differing priorities. In the southern customer scenario, cost is almost always the constraining factor, followed by features that are optimized, and accepted time to market (within reason, of course). Donors funding technology development will constrain time to market because of the project length specified in the project proposal. Cost and features are then optimized with cost often losing out to features that are set and met with user-based specifications. Figure 3 shows the inherent mismatch.

Figure 2. Priority matrix

Figure 3. Design team priority matrices

8. Core Competencies
PDAC-1: Are all the core competencies, required for successful deployment of your project, identified and accessible? 1 (Not at all) 2 3 (To some extent) 4 5 (To a great extent)

Core competancies required to successfully deploy a project in developing economies or countries may be inaccessible. Steel sections are a good example. Design team members know that the available (locally-made) mild steel sections may vary as much as 5% in any dimension. Internal and external diameters varied unpredictably. Angles assumed to be 90 were noticeably not. Local manufacturers could arguably produce sections to higher tolerance, but this would result in a prohibitively expensive product. The NGO then shifted their focus to the composition of their design team, recruiting members with the experience and skill to be able to design a robust product with expectations of supplier variance. 11. Localization
PDAC-1: Are the variations in user needs and compliances understood by geography? 1 (Not at all) 2 3 (To some extent) 4 5 (To a great extent)

The societies of industrialized countries tend to be far more homogenous than those of developing countries. The existence and development of technology, among other things, promotes a "melting pot" culture of assimilation, but countries with poor infrastructures and low technology usage maintain isolated pockets with "mosaic" cultures. The population of Kenya is composed of over sixty tribes, each with distinct languages and cultures. Traditional gender roles, for example, may vary over a small region resulting in vastly different user needs. Whereas number 2: "Understanding the User and Customer Needs" stresses the importance of understanding user needs, this question reminds designers that it is likely that there is a high degree of variance amongst the target population.
PDAC-2: Are the variations in user needs understood by geography and culture?

510

ICED 01 -C586/410

5.2 Overview of Main Findings

Implementation of the PDAC1 in the developing scenario resulted in findings in two different areas. First, (1) following the characterization of the donor-driven product development model; there is clearly an inherent conflict of goals as it presently exists. Secondly, (2) assumptions made during product development processes in industrialized scenarios do not necessarily hold true in developing scenarios, and additional considerations are necessary. (1) In mapping project priorities, donor resource allocation and timeframe are potentially in direct conflict with the product customer. Most donor organizations are allocated money by a government or governing body on a yearly basis. Projects then have set timeframes and budgets that dictate their activities to be completed within a fiscal year (or years) framework. (2) The PDAC-1, like most methodological design tools, makes the assumption that the design team has a high level of control over the eventual sustainability, and economic viability of a product. In a developing scenario, this is often not the case; the actions of the design team are only one of several factors influencing the product's success. External factors such as supplier reliability, skewed market forces, and government corruption will also influence the market success of a product.

Conclusion

Methodological design tools and techniques such as the PDAC-1 can be applicable with modifications. While tools such as PDAC-2 may also be useful, they are rarely used. The modifications necessary to make the PDAC-1 applicable to the Kenyan scenario highlighted considerations, constraints, and limitations for design teams developing products working in both industrialized and developing scenarios. Table 1 summarizes the modifications to and applicability of PDAC-1.
Table 1. Summary of PDAC-1 Modifications and Applicability
1
PDAC-1 Strategic Alignment: Does the team understand the strategic objectives, the boundary conditions within which they need to operate, and the target market for the product? Project Priorities: Does the team have an agreed upon hierarchy of measurable priorities based on the required positioning? Resources: Does the project have the staffing and funding needed to make the project success? Management Leadership: Does the management hierarchy collectively support the project and provide unified guidance for making decisions? Dependencies: For all functional areas, are both internal and external dependencies established and working well? Competitive Analysis: Has the team identified the product's top three competitors and projected what they will be offering at the time of your product's release? Product Positioning: Does this project have a clear and compelling benefit-based positioning based on user and customer needs and competitive advantages for each market segment? Core Competencies: Are all the core competencies, required for successful deployment of your project, identified and accessible PDAC-2 Philosophical and Action Alignment: Does The team 's strategy address and align the donor and customer objectives, their boundary conditions, and the target population of the product? (No change in wording.) Applicability HighMedium

Medium

3 4

(No change in wording.) (No change in wording.)

Low

High

5 6

(No change in wording.) "Competitive" Analysis: Has the team distinguished between and identified foreign competitors, indigenous producers, and traditional practices? Product Positioning: Does this project have a clear, compelling, and immediate benefit-based positioning based on user and customer needs and competitive advantages for each market segment? (No change in wording.)

Medium HighMedium Medium

High

ICED 01 -C586/410

511

10

Understanding User and Customer Needs: Has the team verified the target market segment, its attractiveness in terms of size and growth rates, and identified the fundamental needs of the market, e.g. productivity, cost effectiveness, ease of use...? Risk Management: Based on the business objectives and project priorities, does the team understand the level of risk it is taking?

Understanding User and Customer Needs: How has the project team identified the target populations? Are the fundamental needs and their respective drivers of the markets understood? Internal Risk Management: Based on the strategic objectives and project priorities, does the team understand the level of risk it is taking? External Risk Management: What are the potential (non-obvious) risks of introducing a new product to this market? Localization: Arc the variations in user needs and compliances understood by geography and culture? (No change in wording.) Exit Strategy: Is the project's exit strategy and plan realistic, complete and viable? Market Channels for Sustainability: Will the appropriate manufacturing, distribution, maintenance, and marketing channels be established prior to the completion of the product?

HighMedium

HighMedium

11 12 13

14

Localization: Are the variations in user needs and compliances understood by geography? Compliances: Has the team identified all relevant compliance standards? Business Model/Financial Analysis: Is the project's cradle to grave financial and project plan complete and accurate? Market Channels: Will the appropriate market channels of distribution be established prior to the market release?

High
Low

High

HighMedium

Acknowledgements

The authors would like to thank ApproTEC in Nairobi, Kenya. This work was supported by the 1999 New Century Scholars Program and the United States Engineering Research Program of the Office of Basic Energy Sciences at the Department of Energy. References [1] Atolagbe, S.O., 1989, "Product Design and Development: A Developing Country's Experience", Proceedings from the 6th International Conference on Engineering Design, Harrogate, UK Donaldson, K., 1999, "Product Definition Assessment for Developing Economies", unpublished full version of this paper. Ishii, K. and S. Kmenta, 1999, "Value Engineering Value Identification and Functional Analysis" in ME217A Course Reader, Design for Manufacturability: Product Definition, Stanford Bookstore. Ullman, D., 1992, The Mechanical Design Process. McGraw-Hill, Inc., NY, pp. 89-109 Wilson, Edith, 1997, "Addendum: Product Definition Assessment Checklist" in ME217A Course Reader, DfM: Product Definition, Stanford Bookstore, pp3.1A.l-2 Wilson, Edith, 1993, "Product Definition: Factors for Successful Design," Design Management Journal, Fall, pp.62-68 Wilson, Edith, 1990, "Product Definition Factors for Successful Design," M.E. Thesis, Stanford University, Stanford, CA

[2] [3]

[4] [5] [6] [7]

Krista M. Donaldson Center for Design Research, Stanford University, Stanford, CA, 94309 USA, Tel: (650) 723-7908, Fax: (650) 725-8475, E-mail: krista@donaldson.net IMechE 2001

512

ICED 01 -C5 86/410

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

AN APPROACH FOR STRUCTURING DESIGN SPECIFICATIONS FOR COMPLEX SYSTEMS BY OPTIMIZATION

C Grante, M Williander, P Krus, and J-O Palmberg

Keywords:

Product planing, complexity management, complex design task, costestimation, product design specification

Introduction

Today's products are becoming increasingly complex with more and more features and functions. This complexity makes it difficult to determine which features to include in the design specification and which to exclude. Late implementation of features during the design process can be fatal, if not impossible, with impact on quality, lead-time, and cost. Most products have one specific function: the "primary" function that they are designed for. Other features are often added. For instance, a car is designed for travelling on roads, in addition to this, it has features such as safety and entertainment systems. By introducing electronics and computers to control mechanical products (mechatronics), many additional features, such as active safety systems emerge. The products, and thereby their design, becomes more complex in comparison with traditional mechanical systems. These features can often use the same implementers in form of actuators and sensors which makes the selection of features to include extremely complex. Research has been done in the field of engineering design leading to design processes. Making use of the design process designers can structure their work and instead of facing a large disorganised complex problem they are able to break it down into sub-parts. In design methodologies, eg, Pahl and Beitz [1], and Suh [2], the design process starts with the requirements (product design specifications). With the increasing complexity of products, the complexity of design specifications also increases, often making it too complex for the human brain to deal with. See Backlund [3]. Consequently, there is a lack of methodology in design processes for structuring design specifications that can consider different features using the same implementers for complex systems. This paper fills the existing gap by helping the designer to structure design specifications for complex products by finding "one" optimal feature set: the one that provides maximum customer value in the given cost constraints (product cost and development cost). Features selection is influenced by customer value, complexity, and additional cost. This method is for specifying these features and functions set and not for describing other requirements, eg, environmental or legislative requirements for products that Schachinger and Johannesson [4] have described.

ICED 01 - C586/428

513

Method

The four-step approach to research: Criteria, Description I, Prescription, and Description II, Blessing, Chakrabrit and Wallace [5], is used in this paper. The problem is described in Criteria, in the introduction of this paper. Measuring an improvement is described in Description I, our solution to the problem is in Prescription, and evaluation of methods in Description II.

2.1 Parameters for measurement of success, Description I

Success of this method is achieved if the use of it improves the conditions for the company using it. Improved conditions are: increased profitability or decreased loss, increased market share, etc. Measures for these parameters are doomed to fail since the environment (all other parameters) does not remain constant. Instead the simplest and most effective measure is to compare selections previously done with the tools selection system and compare differences in cost and customer value with history and this selection method. We do not achieve any ultimate validation, but we can measure if the current method can select an improved combination of complex systems or not. To see if the method affects parameters that not are directly linked to profit, the number of design changes, time to market, and customer desire of features, were also investigated by interviews with several people who used the method in the Chassis department at Volvo Car Corporation (VCC). A simple scale containing negative effect, no effect, and positive effect was used.

2.2 Definitions
All products provide the customer with one primary function and in most cases several additional features. Technical functions are needed, ie, be electronically controlled to implement features/functions such as brakes, radar sensor, and airbags in an active car safety system. One technical function can be used by several customer functions and features. See Figure 1.

Figure 1. Each ellipse represents a customer feature and each dot a technical function. If a technical function is needed to realise a customer feature it is inside the ellipse. The shared technical functions inside the overlapping segments need only be implemented once to achieve customer features.

2.3 Prescription
In structuring design specifications, decisions concerning which function(s)/feature(s) to provide the customer with and how to implement them are made. The aim is to get as high a customer value as possible at a given cost. Design specifications should contain customer

514

ICED 01 - C586/428

features and technical functions that have the highest concept value in accordance with (I) and still keep within the limits stated. concept value = E(value of customer features) - (cost of technical function implementing the customer functions) (I) Mathematical model Where the value of concept customer functions = EM (Bk,i*Vj) i k M Bk,i Vi = integer representing a specific customer feature = integer representing a specific concept = the total number of customer features possible to implement in the product = one if the customer feature i is a part of the solution k and zero if it is not = the value of the benefit that the customer feature i will provide

and the cost of the technical function for implementing customer functions

j = integer representing a specific technical function Ai,J = the coupling matrix, see 2.4, is to the value of one if the customer feature i uses the technical function j and zero if its not Rj = the cost of the technical function j x = the value of a technical function N = the total number of technical functions U = union function [6] e = member of function [6] V = all function [6] The union function is used since the customer functions can share technical functions and thereby the cost. This means that if a technical function is used more than once in a solution it still does not cost more to implement. Different limitation factors are considered by using a utility factor a. Using a, the customer features scale varies in relation to the technical cost scale. Using this approach different cost budgets can be modelled. This gives the following function:

= the total number of different design concepts

2.4 Input parameters Coupling matrix Customer functions and technical functions are coupled in the coupling matrix Ai,j.It is coupling that makes this method unique. Choosing which customer features to implement depends on customer value, added product cost and if different customer features can be realised using the same technical functions and thus sharing the overall cost. In the Ai,j matrix a 1 represents a customer feature using a technical function and a 0 that its not, see the

ICED 01 -C586/428

515

example in Figure 3. Note that if a customer feature is chosen to be in the solution all technical functions using it must also be implemented. Customer Function We have used two different approaches, par comparison and customer price, to generate the value of customer functions Vj. Par comparison is a subjective comparison of the customer functions in a relative scale. It was found that the evaluation matrix, Figure 2, was the best tool for this comparison. Evaluation tools using data such as the Pugh matrix [7], and the Kesselring matrix [8], lead to inconsistencies between the numerical scale created and our perception. The evaluation matrix does not have this problem since each customer feature is compared with all other features. It is also easy to use since it requires less input then second approach. The disadvantage is that it is less accurate and that many comparisons have to be made, (n2-n)/2 where n is number of customer functions.

Figure 2. Evaluation matrix. The functions A, B, C, and D are compared. Minus one (-1) in a row means that the feature in the column is preferred and vice versa for 1. Zero (0) means that none of the features are preferred above the other. Each row is added up and a relative numeric scale describing the relative importance of the features is created.

The second approach is to compare a customer desire for a feature based on the amount the customers are prepared to pay. In this case, the numerical scale is the actual price. The major advantage with this approach is the absolute scale using zero, which is not used in the evaluation matrix. Using this approach the number of "decisions" only aspects increases in a linear manner with n and also provides the possibility to predict product earnings at an early stage. The disadvantage is the difficulty in making estimations when dealing with functions that are new and have never been on the market. It is significantly easier to say if a feature is desired more or less than another one is is, than to estimate how much a customer is willing to pay for it. Technical functions The creation of a numerical scale for the cost of the technical function uses two similar approaches to the ones used for customer features. The approach that was favoured is the estimation of the cost of each technical function. In the estimation the development cost of the technical function, part cost, and product volume is considered. The other approach is comparison evaluation. It is the same technique as for the evaluation of the customer features with different evaluation criteria in the form of the complexity of the technical functions. The complexity was chosen as it was considered to be the cost driver. This second approach is used in cases where cost of technical functions has been difficult to estimate.

516

ICED 01 -C586/428

2.5 Optimisation
Computations of formula (II): to find which combination of customer features is the best, increases in a linear manner with the number of technical functions and with C, see (III).

C n k

= the number of calculations for the value of concepts, ie, number of computations of (II) = the number of possible customer features - the number of customer features chosen

For small problems it is possible to calculate all combinations of customer functions but when the problem increases in size the number of computations increases rapidly, thus making it impossible for current computers to calculate within a reasonable time-frame. In order to solve these problems optimisation is used. In order to use effective optimisation techniques the problem is reformulated and is seen as continuous rather than a discrete optimisation problem. Fuzzy logic approach is used where technical functions and corresponding customer features can have values in the interval [0.1]. Since the system is linear between the optimum, the extremes are always within either 0 or 1. The COMPLEX algorithm The problem is to maximise the function: is subject to the constraints: Gi < xi < Hi where i = 1.2 .... M. The implicit variables XN+1 ... XM are dependent functions of x1 .... XN. The constraints Gi and Hi are either constants or functions of x1 .... XN. We have used the COMPLEX-RF [10] algorithm based on the COMPLEX optimisation algorithm by M. J. Box 1965, since it is suitable for this kind of problem. An initial complex of k points is generated, typically k = 2 N. The variables at each point are generated using random numbers. F(X1, x 2 ... XN)

j is an index that indicates a parameter set in the complex and i an index that indicates a variable, rij is a random number in the interval [0.1]. If the implicit constraints are not fulfilled, a new point is generated. The number of points k in the complex must be such that k > N + 1, where N is the number of independent variables. The object function is evaluated at each point. The point having the lowest value is replaced by a point reflected in the centroid of the remaining points by a factor: a.

Box (1965) recommends a= 1.3. If a point is repeated as the lowest value on consecutive trials, it is moved one half the distance to the centroid of the remaining points.

ICED 01 - C586/428

517

The COMPLEX-RF algorithm The main difference is: additional randomisation of new search points, this prevents the COMPLEX from collapsing prematurely. The second is: the introduction of a "forgetting factor" that gradually removes the influence of old parameter sets in the complex.

Example

This paper contains an example in order to understand the method more easily and it also contains an insight into a large industrial example conducted at Volvo Car Corporation. The example has four customer features and illustrates how the method works. The features and their technical functions are: Anti-lock Braking System (ABS), which prevents the wheels from locking during braking. ABS uses the technical functions Controlled Brake and Wheel Speed. Traction Control System (TCS), which interacts with the engine and brakes to prevent the wheels from spinning during acceleration. The TCS uses Controlled Brake, Wheel Speed, and Driveline Torque Estimation. Brake Assistant (BA) [11], which helps the driver to apply additional brake force in a critical situation. The BA uses Controlled Brake and Brake Pedal Position. Electronic Stability Control System (ESP) [11], which prevents the vehicle from skidding by interfering with the brakes. The TCS uses Controlled Brake, Driveline Torque Estimation, and Yaw Rate Sensor. The coupling matrix for the example, value and cost is shown in Figure 3. Note that this is an example and the values and cost are invented.

Figure 3.

Example of a coupling matrix.

In this case, using a budget of less than 2000, BA is chosen for implementation since it has the highest profit margin (2000-1000-500=500). If the budget is increased to 2500, ABS and TCS should be chosen to be implemented since they will be even more profitable (2000+2000-1000-1000-250=1750). With a budget of 3000 ABS, BA, and TCS will be most profitable with (2000+2000+2000-1000-1000-500-250=3250). The above is visualised in Figure 4. Of course all features can be implemented with a high enough budget and then this method does not serve any purpose. Unfortunately this is seldom the case. Using this example it is relatively easy to find the combinations of customer features that provide the highest profitability for limited development budgets. For a real project this is impossible because of all the combinations possible, then this method is useful. A project concerning active safety features for VCC can be seen in Figure 5, which uses the same kind

518

ICED 01 - C586/428

of visualisation as in Figure 4. The Volvo case has more than 9 x 1015 possible combinations of features that could be chosen.

Figure 4.

The optimal set of customer features using different budgets. The black marking indicates the use of the customer features. The same visualisation can be done for technical functions.

Figure 5.

Overview of an industrial application at Volvo Car Corporation. It is the same kind visualisation as Figure 4 but is for the more complex problem.

Result

The results of the example at VCC is shown in Figure 6 where active safety features for a car model have been selected using the current method and the method presented in this paper. The current method uses skilled people who make the best possible selection using the same criteria as this new method. The comparison above shows an average increase of 100% in customer value with sustained cost using the method presented. An interesting result is that the old method keeps selecting functions although the total profit decreases.

Figure 6.

Feature selection using current method at VCC compared with this method.

ICED 01 - C586/428

519

There are also other influences on the parameters. One positive aspect was the number of design changes. A reduced number of design changes were made in the project. There was no measurable effect on time to market and it had a positive effect on customer desire of features that were implemented in the product. Other results that could be seen: the designers found it positive to focus on the technical functions instead of the customer features/functions, which they do at present.

Conclusions

The method has shown to be successful. Customer value increases with an average of 100% with sustained costs in the test cases at VCC. The parameters, number of design changes, time to market, and customer desire of features, were also investigated with the aid of interviews. These were conducted to see if the method had an effect on other parameters that not are directly linked to profit. It was found to have a positive effect on a number of design changes and customer desire of features, but changes in time to market could be seen. By using this structure when making product design specifications for complex systems it is possible to choose an improved set of features and functions to be implemented in product design specifications. This will lead to a reduction in late changes, products of greater value for the customers, and higher profit margins for the manufacturers. References [1]. Pahl and Beitz (1996), Engineering Design, Springer-Verlag, London [2]. Suh (1990), The Principles of Design, Oxford University Press, New York [3]. Backlund (2000), The Effects of Modelling Requirements in Early Phases of BuyerSupplier Relations, Department of Mechanical Engineering, Linkoping University [4]. Schachinger P. and Johannesson H. (1999), A Method for Computer Based Specification of Products, Department of Machine- and Vehicle Design, Chalmers University, Goteborg [5]. Blessing , Chakrabarit, and Wallace (1998), Designers - the Key to Successful Development, pages 56-70 , Springer-Verlag, London [6]. Wordsworth (1996), Software engineering with B, ISBN: 0-201-40356-0, Addison Wesley, United Kingdom, [7]. Pugh,(1990), Total Design, Addison-Wesley, Workingham [8]. Ulrich and Eppinger (1995), Product design and development, McGraw-Hill, New York [91. Hayter 1996, Probability and Statistics, PWS Publishing Company, Boston [10]. Box (1965), A new method of constraint optimisation and a comparison with other methods, Computer Journal 8:42-52. [11]. Isermann (2000), Diagnosis Methods for Electronic Controlled Vehicles, AVEC'2000, Ann Arbor Christian Grante, Dept. 92410, PVH 31, Volvo Car Corporation, S-405 31 Goteborg, Sweden. IMechE 2001

520

ICED 01 - C586/428

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

AN ENGINEERING APPROACH FOR MATCHING TECHNOLOGY TO PRODUCT APPLICATIONS

J B Larsen, S P Magleby, and L L Howell

Keywords: Systematic product development, innovation methods, design management, economic viability of new technologies, product planning

Introduction

Most formalised product development processes are oriented towards an initial focus on the customer of the product. These processes are often categorised as "market-pull." This customer-orientation is generally justified as starting development from the customer side provides a basis throughout the process for evaluation of design alternatives and assessment of product performance. Common wisdom among marketers and product developers is that the market-pull approach yields more "successful" designs than alternatives. This singular view of product development processes neglects the strategies and needs of organisations that create and/or own technologies that they wish to capitalise on by making them an integral part of a product. Product development processes that are oriented towards an initial focus on the product embodiment of a technology are often categorised as "technology-push" [1]. Most companies do not pursue this type of development in a structured way because of the lack of defined processes and risks of missing market needs. Despite the market-related risks of executing this type of development, if well done it can present enormous benefits to an organisation. Besides helping ensure successful development of a technology, it also facilitates the creation of lucrative new markets and spreads research costs over a broader product base. While there has been much work done on topics that are related to development of new technologies and the associated need for innovation, there has been relatively little discussion on the technology-push product development process from an engineering point-of-view. Development of such an engineering design process is not trivial as it presents a number of challenges not inherent in the market-pull approaches [2]. The objective of this paper is to develop and present a practical process for accomplishing "technology-push" product development. The key aspect of the process that will be explored is how to find a focus for the viable product options that could embody the technology. This will be accomplished by first reviewing past research in relevant areas. Then the flow of information through the two types of product development processes discussed above will be decomposed. Based on this information flow, a generic technology application selection process is formulated. Finally, a method for evaluating the appropriateness of a given product application for a technology is presented.

ICED 01 -C586/643

521

Background and Literature

There are four major fields of study the authors have found that impact and provide a background for definition of a technology-push product development process. This section briefly addresses design processes in general, research directions in innovation, technology transfer as an activity, and a field called Technology Integration.

2.1 Design Processes

While there are a wide variety of design processes presented in literature, most all of them are initiated with customer/market data. Take for example the widely recognised process presented by Ulrich [3]. In their Concept Development stage, the first step they propose is to "Identify Customer Needs." All subsequent steps build on this foundation of customer needs, establishing a coherent development direction based on the voice of the customer. Despite the potential effectiveness of developing a product in this way, often companies have a technology they wish to embody in a product(s), without foreknowledge of the customers. A structured, engineering process for accomplishing this is not available in current literature.

2.2 Innovation
Innovation can be defined as the creation of a new concept and making it commercially viable. Technology-push product development can be considered a subset of this broad field of innovation. While much has been written about different methods for innovating, little has been written on this particular category of innovation. Other forms begin with a sensed need or target customer and look for a technological solution. This form begins with a specific technology and searches for customers who have a corresponding need.

2.3 Technology Transfer

Recognising the importance of technology as an input to the product development process, most companies seek to develop new technologies internally. Because the processes for technology development versus product development are so dissimilar, the two are usually organisationally separated from each other. To make the transition from technology development to product development, many have engaged in technology transfer, a method for taking the knowledge generated in the former stage and embedding it in a development team that can take it to market. The problem with this, however, lies in the fact that the development is usually targeted to one product, prematurely narrowing the application options and stimulating biased evaluation of the technology feasibility. Despite the applicability of technology transfer concepts, technology transfer does not preclude the need for a formalised application selection process prior to full-scale development for technology-push projects.

2.4 Technology Integration

Recent studies by Marco lansiti of the Harvard Business School [4] support the idea that a distinct process is needed to manage the integration of technology from research into development. lansiti even recommends the establishment of a separate organisation to hold responsibility for technology integration. This article supplements lansiti's strategic, organisational insights with a practical, executable engineering process.

522

ICED 01 -C586/643

Information

The product development process deals with a myriad of information. The "process" itself is simply a way of creating and arranging this information so it is available to facilitate decisions at appropriate times [5]. The technology-push process can best be understood through an analysis of the input information and how it is used throughout. This section decomposes the general information types, explains how information flows through the process, and contrasts this with market-pull development.

3.1 Information categories

An analysis of the development process shows that information involved in the process can be grouped into four basic categories associated with the following: 1. Customer - the intended purchaser or user of the product and other stakeholders 2. Needs - the specific objectives a customer(s) seeks to fulfil with a product and desired attributes of the product 3. Product - technology embodiment, intended to satisfy customer needs 4. Technology - the application of scientific knowledge Based on these designations, product development could be defined as "the realisation of a product through embodying technology in a manner meant to satisfy customer needs." Technology-push product development is "the realisation of a product through embodying a specific technology in a manner meant to satisfy customer needs." Market-pull is "the realisation of a product through embodying technology in a manner meant to satisfy needs of a specific customer set." The fundamental difference between market-pull and technologypush is not the type of information dealt with, but rather the informational starting point and thus how it is processed.

3.2 Information flow

Essential to understanding how this information is processed is the order in which it is encountered and utilised. While information from each of the categories shows up throughout the process, most of the major steps can be classified by the category of information primarily dealt with. Using the information categories, the flow of information is outlined below. A market-pull project begins with a set of target customers. From this customer set, developers ascertain the needs they intend to satisfy (step 1). Then using these needs they establish guidelines (specifications) and architectural concepts for the product (step 2). Technologies are identified to fulfil the concepts generated (step 3). Upon selection of the optimum architecture (technology integration), developers design the product and production processes (step 4), evaluate the product against customer needs (step 5), and deliver it to the customer (step 6). Figure 1 gives a graphical representation of the first three steps of this process, with the steps being numbered. For the sake of this article, we will focus only on these steps as this is where initial information in all four categories is obtained. Consider, on the other hand, how information should flow through the preliminary stages of the technology-push process. The order is significant primarily as it relates to the ease of progression. The end objective is to have sufficient knowledge about each information type to be able to decide whether or not to pursue full-scale development of an application. Below is

ICED 01 - C586/643

523

outlined the flow that seems the most executable and logical to obtain the information necessary for such a decision.

Figure 1. Information flow in a market-pull product development process

Rather than starting with a set of customers, technology-push begins with a given technology. From the functionality and characteristics of the technology, the developers can derive needs that it satisfies (step 1). They then are able to choose a product embodiment of the technology to meet the needs (step 2). Next they identify customers who possess the needs and thus would desire the product (step 3). Now that a suitable customer has been identified, development can continue much the same as if the project were market-pull. The project has transitioned from being technology-push to market-pull.

Figure 2. Information flow in a technology-push development process

3.3 Information management

As has been demonstrated, the two processes both deal with the same types of information. However, technology-push seems to be significantly more difficult to complete. This variation in difficulty level lies in the way information is evolved. The steps in market-pull are discrete and executable, while those in technology-push are comparatively vague and uncertain. Marketers have methods to find the needs of a given customer base, but lack repeatable ways to find potential customers given a certain set of needs. Given a product architecture, designers can find technologies that correspond to their needs, but identifying suitable product applications given a single technology is more difficult. Another way of saying this is that each of the "queries" in a market-pull process is more clearly bounded than in technology-push. Needs are bounded by the customer base and technologies are bounded by the product needs. For technology-push, on the other hand, product applications are bounded only by generic characteristics of the technology and potential customers are bounded only by generalised needs. Given a set of customers, it would

524

ICED 01 -C586/643

be relatively easy to determine their primary needs for a product. Taking the same set of needs, though, it would be quite difficult to determine the customers that possess them. Nonetheless, the greatest obstacle for technology-push, its open-ended nature, also creates the greatest opportunity for those who can successfully execute it. Rather than limiting, it opens up the field of potential customers, allowing an organisation to leverage its current resources and capabilities for much greater profits. It also leads to revolutionary, not just evolutionary, products. It facilitates using a technology investment for many projects, rather than just the initial one it may have been intended for. It motivates people to explore technological opportunities and exploit all possible applications. The challenge lies in finding ways to quickly identify and evaluate application opportunities with an open-ended project.

A Generalised Technology Application Selection Process

The information presented so far lends itself to the creation of a process for technology-push product development. Our focus will be on matching technologies to product applications. This will be accomplished by presenting a technology application selection process that takes place before full-scale development. Following are the general phases that each project should pass through. These phases are illustrated in figure 3.

Figure 3. Technology-push product development process Transfer from Technology Development, Transfer to Product Development

The initial transfer into and final transfer out of the process require special considerations. This process boundary will not be explored in detail, but is a potential area for future research. The principles of technology transfer would likely apply well to these transitions.
Technology characterisation

When an organisation has a technology to develop, they should begin by characterising it. This consists of not only understanding the basic scientific founding, but also translating the functionality and properties into needs the technology could satisfy. While this may start with generic descriptions of the technology, a development team should seek to evolve these into as specific categories as possible to ease the difficulties of being open-ended. Knowledge about the technology must be evolved into knowledge about the needs it can fulfil.
Application identification

Using needs generated in the first phase, a team generates product ideas (technology application concepts). This should be an open-ended phase with focus more on quantity than quality. This should be a creative stage, where structure is undesirable, as it inhibits the creative process. The creativity of this stage makes it inherently difficult to systematise. The needs derived in the characterisation stage should lead to products that fulfil them.

ICED 01 - C586/643

525

Application evaluation Next the application concepts must be evaluated for viability. Note that while the traditional development process focuses on narrowing down concepts to make only one final product, the multiple concepts generated by this process should be evaluated and pursued separately. This is why objectivity is particularly important, but difficult in technology-push product development. This "application evaluation" phase is a milestone determinant of product development success. If only suitable applications are allowed to pass, the projects are likely to prove successful. If too many applications are denied, the organisation has foregone attractive opportunities. In evaluating the feasibility of a project, it is particularly important to ensure that it can transition from technology-push into market-pull. To do so, suitable customers must be identified and the concept must be evaluated based on their tastes. This phase is discussed in more detail below.

Application Evaluation

As mentioned above, the application evaluation stage has a particularly strong influence on the eventual outcome of a project. This section assesses different approaches for evaluating a given application.

5.1 Scoring
A common way to simplify complex decisions based on various factors is by weighting and scoring. For design decisions, many people use concept scoring matrices to select the "best" concept. A designer would weight the various specifications or needs by importance and score each of the concepts for the different factors. These scores can then be compiled to give an overall rating for the product [3]. Scoring is particularly relevant to technology-push project evaluation because of the wide variety of considerations that come into play when assessing project viability. These issues include strategic, organisational, legal, market size/readiness, safety, environmental, competition, function, durability and many others [6]. While scoring is extremely useful for comparing a wide variety of alternatives using many criteria, technology-push projects should not necessarily be evaluated relative to other concepts, but rather for their independent viability. The purpose of application evaluation is not to select from multiple alternatives, but to assess the viability of each individual alternative. If ten concepts seem likely to prove profitable in the long-term, why should they be narrowed down to the top two or three?

5.2 Financial Viability

The fundamental motivation for most organisations to limit investment is scarcity of capital. For this reason, viability is primarily determined by financial considerations. The most common management method for ascertaining financial viability is the Net Present Value (NPV) method. This uses the concept of the time value of money to determine if an investment is more profitable over time than other possibilities. To compensate for the inability to evaluate all other possibilities for the sake of comparison, a context-specific

526

ICED 01 -C586/643

discount rate (usually a weighted average cost of capital) is chosen to evaluate each project individually. In this way, a general alternative is used to which all possibilities are compared. Recognisably, many of the factors mentioned in the scoring section above largely govern the expected financial performance. The method's comprehensiveness is also its greatest weakness. The calculated value of a project is wholly dependent on the underlying assumptions; the overarching calculations merely propagate or accentuate any inaccuracies. Additionally, generating the values usually requires significant time and energy. In order to minimise the time and energy used to evaluate a concept while still getting a reasonable estimate for the viability, we delve into the factors that seem to govern performance. Specifically, we want to look at the functionality of a given technology in a certain product application.

5.3 The Function Gate

Certainly, function would be a heavily weighted factor if we were to use a scoring matrix to select a potential application. An assessment of functionality would also determine many of the assumptions on which an NPV analysis would be based. These perspectives, however, lump functionality in as a slice of the overall pie, failing to recognise it as a prerequisite for the pie. If a technology does not have the desired functionality for a certain application, it will not satisfy the customer needs regardless of how it is embodied. Distinguishing functionality as a prerequisite rather than simply a contributory factor, establishes several major benefits. Most importantly, it filters down the aspects to be taken into consideration, greatly simplifying the decision-making process. Secondly, it clearly delineates the benchmark product, making competition and customers much more explicit and the subsequent assessment more accurate. Thus it accomplishes the purpose of application evaluation as explained in the process section of this paperit moves the team from product knowledge to customer knowledge. Finally, it builds on the information already developed in the technology-push process, which was founded on an understanding of the technology and how its functionality could satisfy customer needs. Recognising the function gate as the preferred method for initially evaluating a technology application, functional decomposition can be used to evaluate functional performance [7]. This can be done by first identifying the product "flows". Flows include energy, materials, or signals that go into and come out of the system. From these system-level flows, a function chain should be developed to represent the different transformations that take place within the system to accomplish the overall transfer function [8]. The precise functions accomplished by the technology should be mapped out to make the functional boundary explicit. It is also important to identify product constraints and distinguish them from flows. Constraints are holistic characteristics that apply to the whole productsuch as cost or weight. Each part within the system contributes to the overall constraint characteristic. By characterising both the flows and system constraints, we gain a clear understanding of how a given technology functionally compares to the incumbent technology in a specific application. Functional decomposition establishes a clear delineation of the benchmark a technology is meant to replace. The difficulty of potential development is reflected in the level of complexity of the benchmark. If the technology simply replaces an existing component, and meets all interface requirements in the current architecture, development should be relatively

ICED 01 - C586/643

527

simple. If it replaces a system within a product, effecting a change in the product architecture, development will be more difficult. Finally if the selected application is a replacement of an entire product or is a new product altogether, the development will be more difficult than either of the two prior scenarios.

Conclusion

Various processes have been developed to systematise product development. Most of these focus on market-pull development because customer demand is necessary for successful commercialisation. Technology-push development begins with a technology rather than the customer, but the same categories of information are dealt with as in market-pull development. While the open-ended nature of technology-push development makes it more difficult to successfully complete, its unrestricted nature also opens many opportunities for leveraging technology development to access new customers and new products. Based on the flow of information through the development process, a generic process for technology-push development was presented. One of the crucial steps in this process is application evaluation. Methods for effectively evaluating the viability of technology applications were assessed, with the functional gate being the most fitting.
References
[1] [2] LaZerte, J. D., Market-Pull/Technology-Push, Research Technology Management, Mar/Apr 1989, Vol. 32:2, Washington D. C. Schulz, Armin P., Clausing, Don P., Negele, Herbert, and Fricke, Ernst, Shifting the View in Systems Development - Technology Development at the Fuzzy Front End as a Key to Success, Proceedings, 1999 ASME Design Engineering Technical Conferences, Las Vegas, NV. Ulrich, Karl T. and Eppinger, Steven D., 2000, Product Design and Development, Second Edition, McGraw-Hill Publishers. lansiti, M., 1998, Technology Integration: Making Critical Choices in a Dynamic World, Harvard Business School Press Mistree, F., W. F. Smith, B. A. Bras, J. K. Allen and D. Muster (1990). Decision-Based Design: A Contemporary Paradigm for Ship Design. Transactions, Society of Naval Architects and Marine Engineers 98: 565-597 Udell, Gerald, Evaluating Potential New Products, Private Press, 1998. Koopman, P. J., A Taxonomy of Decomposition Strategies Based on Structures, Behaviors, and Goals, Proceedings, 1995 ASME Design Engineering Technical Conferences. Kurfman, Mark A., Stone, Robert B., Van Wie, Mike, Wood, Kristin L., and Otto, Kevin N., 2000, Theoretical Underpinnings of Functional Modeling: Preliminary Experimental Studies, Proceedings, 2000 ASME Design Engineering Technical Conferences, Baltimore, MD.

[3] [4] [5]

[6] [7]

[8]

Spencer P. Magleby Brigham Young University, Mechanical Eng. Dept, 435 CTB, Provo UT 84604 U.S.A., voice: (801) 378-3151, fax: (801) 378-5037, magleby@bvu.edu IMechE 2001

528

ICED 01 -C586/643

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

FINANCING INNOVATION IN CO-OPERATION PROJECTS

P Link and S Spiroudis

Keywords: Industrial co-operation - investment appraisal - virtual enterprises

1 Introduction
In Switzerland and Germany different Virtual Enterprises emerge. One of the main issue of such Virtual Enterprises is the production of goods one company alone is not able to produce. They are combining their competencies and capacities for production. One company acts as lead, makes the offer, negotiates with the customer and when it comes to the deal, takes all the risks. Sometimes certain development expenditure is necessary in order to be able to produce the product. There is of course a risk, mainly of technical nature, to exceed the agreed payment. Innovation projects are different. In innovation projects a company spends money before being sure how to sell the product at all or how to cover sufficiently the expenses. In collaborative new product development (CNPD) the costs and the gains, the risks and the reward need to be shared. CNPD therefore demands a high level of trust and familiarity with the partner and his skills. Existing Virtual Enterprises offer a highly interesting platform for collaborative new product development since there is a close personal relation and the partner's skills, capacities and competencies are well known. Combining the competences of the network, partners can create competitive advantages. Especially small and medium sized enterprises (SME) can benefit from chances which they could not realise alone, since really innovative projects require a lot of development work or even basic research. Bigger projects can be realised, when the partners can agree on the financing structure. There may still be a need for an external financing.

2 Financing innovations
From a general financial point of view innovation projects must be financed with proprietary capital [1]. Credits are given only against sufficient liabilities. The required capital can come from inside the company (self-financing) or from outside in form of a participation capital. In this case the financing partners expect an appropriate participation in the project reward. Equity investment in young private companies is generally known as venture capital [2]. Within this chapter the classical capital sources, venture capital, private equity and business angels, are shortly described.

ICED 01 - C586/315

529

The typical attributes of venture capital are the following: Participation: The investors participate significantly. He bears the full risks. Management-support by the venture capitalist: The investor actively supports the enterprise. Most of the time he is part of the board. Shareholder contract: The participation is secured with different contracts (pre-emptive right, the power of veto for important decisions, monthly reporting etc.). Exit-regulation: Already at the beginning of the project the exit of the investor is planned. Usually a venture capitalist seeks to sell his shares (e.g. IPO) The venture capital market is rapidly growing in Europe (see figure 1).

Figure 1: Private Equity und Venture Capital Investments in Europe [3]

On one side private equity stands for investment in more mature, not stock quoted enterprises. On the other side, venture capital means investments in fast growing, young and innovative companies in an early stage [4]. In order to receive venture capital the enterprise must have a detailed business plan, sometimes even a prototype and seriously interested lead users. It is getting increasingly uncommon that venture capital is given in an earlier stage. People who invest earlier (seed stage) are called "Business Angels". They always have experience in the specific branch, experience (e.g. from a former own entrepreneurship) and money to invest. Business angels sometimes do not need a written business plan and are able to take their decision on a fast and informal basis [5]. They often have also a high personal interest beside the financial gain. 75% of the business angels invest between 15'000 and 150'000 Euro [6]. The business angel market starts to get better organised in continental Europe. Great Britain has a competitive edge in this field. Different financing stages or investment stages can be distinguished in a company's life cycle (see figure 2). Thereby the seed stage consists of the financing of the elaboration of a concept up to the prototype. In the start-up stage usually the enterprise needs capital for the market launch.

530

ICED 01 - C586/315

Figure 2: Comparison of financing source, financing stage and innovation stage

3 Financing innovation projects

The classical project financing is only used for very large projects (investment > 10 Mio Euro). So-called "special purpose vehicles" are created [7]. All partners found a company together. It is not efficient founding companies for each project until it is not sure that the project will be realised. The classical characteristics of project financing are Cash Flow Related Lending and Risk Sharing [8]. These elements are also found in the financing of innovation projects. Figure 2 compares the financing sources both the financial and the innovation stages. The innovation process is based on the 5-stage-gate-process of R.G. Cooper [9]. The possibilities of financing innovation projects in early stages are limited. Business angels focus on new enterprises. In later stages there is a minimal investment. Below this the costs are higher than the possible revenues. There is a financial gap for small and medium sized projects (< 500'000 Euro) and for early stage financing of low-tech projects. 18% of the European manufacturers mentioned in a survey concerning innovation carried out by EUROSTAT that the lack of suitable financing sources lead to significant longer project duration [10]. The main issue is the 'chance/risk relation'. If this relation is unfavourable, there are not many possibilities of getting capital. Within low-tech fields the chances are often judged to be insufficient anyway. Early stage financing (pre-seed and seed money) is widely used for the fast growing industrial sectors biotechnology and health care. Even companies of the hightech and IT/Internet sector find it difficult to receive seed money. For the low-tech sector it is out of reach.

ICED 01 - C586/315

531

The finance institutes need to carry out some structural changes to be able to offer smaller venture investments. One way is of course the standardisation of the investment appraisal process, but these possibilities are rather limited. A second option is outsourcing. External partners execute the appraisement of the project. These partners may be paid only if the project succeeds. In this case they also participate in the project. These partners must bring in added value in form of branch experience, technical and/or market knowledge. In the following paragraph the idea of a financing network is presented. The industrial partners, different service providers, basically finance the investment [11]. The financial service provider coaches the financing process and of course participates in the investment (see figure 3).

4 Financing network 4.1 Basic idea

The financial service provider could be a bank, a venture capitalist or an insurance company. It can be very useful to integrate both, banks and insurance in the network, depending if more support on the financing or insurance side is required. Insurance companies often have strong risk management skills. A venture capitalist can be included for the financing of the expansion stage. The differences between classical banks and insurances are getting smaller.

Figure 3: Financing Network

Within the network a "special purpose vehicle" is created similar to BOT (build-operatetransfer) projects [12], [13]. The network has the following characteristics: Participation of all partners (initiator, primary partner, technical, marketing and financial service providers) in the up- and downside risks (losses and gains) of the project Fair and transparent risk sharing agreements Revenues are related to the cash-flow Optimal know-how combination and added value generation Networking in a bigger network of economically independent companies Commitment and major interests of all partners resulting from participation in the project performance

532

ICED 01 - C586/315

Formation of the collaboration according to the requirements of the projects (see figure 4) Informal agreements are possible, a strong culture of trust exists

Figure 4: Financial network as a virtual enterprise

4.2 Tasks and responsibilities of the involved partners in the early innovation process
In the idea filter (Gate 1 of the innovation process) the most interesting projects are chosen according to different criteria (e.g. success chances, strategical focus, feasibility, market attractiveness, competitive advantage). After a project has been chosen, the preliminary investigation begins. Different tasks have to be carried out by the partners in the network (see figure 5). Initiator Rough Capital Budgeting Estimation of the expected earnings Formulation of the project objectives and strategies Intuitive Risk analysis Operative project management Preparation of the presentation Financing SP Marketing-SP/ Technical SP Rough market analysis Rough competition analysis Characterisation of the market segments Evaluation of the technical feasibility Check the state of technical knowledge Preparation of the presentation Primary partner Determination of project-specific synergies Determination of complementary core competencies Preparation of the presentation

Figure 5: Checklist of the tasks in the first stage ("preliminary investigation") of an innovation process

The next stage according to Cooper's innovation process is the stage of building the business case. In this stage a detailed investigation takes place and the project is defined in detail. In

ICED 01 - C586/315

533

this stage a considerable amount of capital may be needed. The sharing of possible losses or gains is defined for the first time. From now on, at each gate, the risk and reward sharing agreement has to be reconsidered. Depending on the accumulated costs, the taken risks and the estimated further expenses the reward and risk sharing agreement may be adapted. It is important, that at any time of the innovation process the sharing agreement is clear. If a project needs to be stopped, the sharing of the accumulated costs are clear. Otherwise there will be discussions who has to cover which costs. Initiator Building detailed business case Specification of the project structure Detailed capital budgeting Creation of a risk factor list Operative project management Preparation of the presentation Financing SP Coaching the making of: - planned income statement planned balance sheet cash flow statement - determination of capital need Determination of useful contacts Determination of suitable financing concepts Determination of potential investors (business angel, venture capital) Marketing-SP/ Technical SP Detailed market analysis (size, growth, trends) Detailed analysis of competitors (market players, market share) Determination of appropriate marketing strategies Preparation of the presentation Primary partner Offering the core competencies Determination of potential customers Determination of useful contacts Preparation of the presentation

Figure 6: Checklist of the tasks in the "detailed investigation" stage of an innovation process

Similar to the different financing rounds in a venture capital project, the value of the work already done has to be calculated (=pre money-value). For the estimation if the pre moneyvalue not only the cumulated expenses but also the value of the elaborated know-how is considered. In a financing round the investor brings in a certain amount of capital. The sum of this capital and the pre money-value is named post money-value. The participation is calculated based on the ratio of the postmoney-value. Different sharing philosophies are possible. Each company carries its own risk (no risk transfer), the risks are beard solidary, and some risks are shared according to a defined sharing rate. The total amount of the risks may be considered for the reward sharing. Another option is an incentive agreement where only parts of the risks are considered. At least one can say that the risk and the reward sharing are interdependent and have to be set together. The sharing philosophy must be clear and fixed from the beginning.

534

ICED 01 - C586/315

4.3 Requirements
This concept can only be used in practice when the following requirements are fulfilled: High level of personal and system trust Collaboration experience of all partners Commitment of all partners Knowledge of the skills and capacities of the involved partners Participation in bearing the loss and sharing the reward Transparent and fair process

4.4 Advantages of virtual enterprises for the financial service provider

Virtual enterprises fulfil most of these requirements. Every partner is known very well from a technical and cultural point of view. There is sufficient trust and experience between the partners. Trust can easily build up when a new project is started. Virtual enterprises combine the strength of a stable network by offering member companies a stable environment, the close and trustworthy co-operative culture of an internal network, and the flexibility and competitiveness of a dynamic network [14]. Existing virtual enterprises, which focus on production at the moment, could move forward and make a higher added value by offering own products and combining their competencies. For a financial service provider there are some obvious advantages as well: Simplified access to innovative projects (information advantage) Participation in attractive business Configuration of the project in early stages Possibility of participation or credit financing in a later stage with less acquisition effort Correspondence to the pay-off structure of a call option - Investment (participation) corresponds to the option-price (limited downside) - Future opportunities (unlimited upside) The financial service provider could also take the role of the house bank of an existing virtual enterprise or offer a platform for other enterprise networks.

5 Conclusion
There are not only advantages of such a virtual enterprise including different service providers who participate in the gain and losses of innovative projects. The following difficulties remain: Complex contracts: The use of standardised contracts without a detailed specification. Definition of the project goals and risk sharing agreements: A transparent and clear process is required. Decision making with many partners involved: An independent co-operation manager or conflict mediator can help reaching an arrangement

ICED 01 - C586/315

535

Nevertheless such a financing concept allows to realise innovation projects, which are too big for a small or medium-sized enterprise (SME) and contributes therefore to economic wealth. Additionally, an interesting rate of return is offered for investors. At a later stage, a financial institute could even promote an investment fund, which invests in existing SME and their most innovative projects. At the moment there are efforts in integrating a bank in an existing virtual enterprise (consisting of only production companies) as a kind of a "house bank". References [1] [2] [3] [4] Boemle M.; ,,Unternehmensfinanzierung," 12. Auflage, Zurich, 1998 Brealey R. A. and Myers S. C.; ,,Principles of Corporate Finance," 5th ed., McGraw Hill, New York, 2000 European Private Equity & Venture Capital Association (EVCA); ,,Yearbook 2000," Vanden Broele Graphic Group, Bruges, 2000 European Council of Applied Sciences and Engineering; ,,Engineering and Venture Capital in Europe," Euro Case Venture Capital Steering Group, Paris, 1998 Lipman, Frederick D.; ,,Financing Your Business with Venture Capital," Prima Publishing, USA 1998. LIFT; ,,Financing Innovation - A guide. Linking Innovation, Finance and Technology," Luxembourg, 2000. Tytko D.; ,,Grundlagen der Projektfinanzierung," Schaffer-Poeschel, Stuttgart, 1999 Finnerty J. D.; ,,Project Financing," Asset-Based Financial Engineering, John Wiley & Sons, New York, 1996 Cooper, R. G.; Product Leadership. Cambridge, Perseus books, 2000

[5] [6] [7] [8] [9]

[10] Community Innovation Survey, "EUROSTAT: Theme 9 / Innovation," European Commission's Innovation Programme, Luxembourg 2000. [11] P. Letter and C. Luchetti; "Finanzierungscoaching fur KMU," Management & Qualitat, vol. 2, pp. 4-8, 1999. [12] F. Nicklisch; "BOT-Projekte: Vertragsstrukturen, Streitbeilegung," Betriebs-Berater, pp. 2-12, 1998. Risikoverteilung und

[13] M. Sosic, L. Albisser, W. Baumgartner and R. Baumgartner; "Project finance The added value of insurance," Swiss Reinsurance Company, Zurich, 11/99 1999. [14] U. J. Franke; "The virtual web as a new entrepreneurial approach to network organizations," Entrepreneurship & Regional Development, vol. 11, pp. 203-229, 1998. Patrick Link and Spyros Spiroudis Federal Institute of Technology Zurich (ETH Zurich) Department of Industrial Engineering and Management Zurichbergstrasse 18, 8028 Zurich, Switzerland Phone: ++41 1 632 05 47, Fax: ++41 1 632 10 45 E-mail: link@bwi.bepr.ethz.ch. URL: http://www.innovatik.ethz.ch C Patrick Link 2001

536

ICED 01 - C586/315

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

PERFORMANCE MANAGEMENT AT DESIGN ACTIVITY LEVEL

F J O'Donnell and A H B Duffy Keywords: Design Management; Design Development; Performance.

Introduction

The overriding aim of much of the engineering design research is to improve the performance of the design process, and consequently the product development process. Much has been written within the product development literature on the performance of the product development process [1]. This work has been largely focused on the analysis of performance at the project or program level. The ability to relate the different research and draw generic lessons from the results has been stifled by the lack of consistency on the meaning of performance both at a generic level [2] and more specifically in design/development [3]. For example, although product and process performance have been distinguished within existing work we are unclear on how these relate or may be managed effectively. This paper begins with a brief review of research in the area of performance, with particular emphasis on design/product development, highlighting the main weaknesses in work to date. A fundamental and generic model of performance, related to knowledge based activities in design, is then presented. The model describes performance in terms of its key elements, efficiency and effectiveness, and provides a basis for modelling performance across different process levels, i.e. project, program, etc.

Research in design performance

The research reviewed here forms part of the overall research in the area of performance of organisations. Some of the work is generic in terms of being applicable across all business processes while other work is aimed at more specific processes such as product development, design, manufacturing, etc. (Figure 1). Within such areas the type of research and focus may vary widely and include empirical studies aimed at determining relationships between performance in different processes, the design and implementation of approaches for measuring performance, the development of theoretical performance models, etc.

2.1 Trends in Performance Research

There has been considerable research published in the area of performance, e.g. Neely [2] identified that between 1994 and 1996 some 3,615 articles on performance measurement were published. He refers to the growth in membership of accountancy institutes, and number of conferences on performance, as indicators of the increased interest in this area. However, in comparison to areas such as manufacturing, measuring the performance in product design is relatively undeveloped. For example, at the recent PM2000 conference in the UK there were

ICED 01 - C586/442

537

no papers focused specifically on the analysis of design development performance from a list of over 90. Many authors have recognised the particular difficulties in measuring the performance in design/development activities [4-6]. These difficulties arise from the less tangible nature of outputs from design activities, i.e. knowledge, the often long duration and wide range of influences from design to market launch, the difficulty in defining/measuring design quality, etc.

Figure 1. Areas and Types of Performance Related Research

The decline of management accounting as the only way to measure business performance is an indication of the move toward measuring less tangible aspects of performance, e.g. those related to knowledge intensive activities in design. Johnson and Kaplan [7] suggest that traditional accounting methods are unsuited to organisations where the product life cycle is short and research and development assume increased importance. Within the scope of this paper two areas of existing research in performance are briefly reviewed, i.e. the definition/modelling of performance and the relationship between design and design activity performance.

2.2 Defining and Modelling Performance

The literature on performance is characterised by a lack of, and inconsistency in, definition of terms. Numerous works have been published which directly address the area of performance but do not explicitly define performance itself. Neely [8] in his review of performance literature suggests that "Performance measurement is a topic which is often discussed but rarely defined". Meyer [9] suggests that there is "massive disagreement as to what performance is" and that the proliferation of performance measures has led to the "paradox of performance", i.e. that "organisational control is maintained by not knowing exactly what performance is". That is, the lack of a comprehensive understanding of performance can often lead to ignorant acceptance of particular approaches, metrics, etc., proposed by senior management in an organisation. The authors defining performance in terms of its key dimensions (metrics) primarily describe those dimensions within the areas of Time, Cost and Quality. The dimensions of time and cost can be relatively easily understood and applied within performance measurement but the concept of quality is somewhat similar to performance itself in terms of its varied interpretation, and the alternative measures used in its evaluation. In some of the literature, dimensions such as Focus in Development, Adaptability and Flexibility have been used. These metrics do not measure performance itself, but rather act as influences on it. For example, flexibility is only appropriate within an environment where changes are required and

538

ICED 01 - C586/442

the capability for a process, such as design or manufacture, to change rapidly may add unnecessary cost/overhead in a stable environment. Flexibility will influence the performance, i.e. efficiency and/or effectiveness of an activity/process, but does not constitute a dimension of performance itself. In summary, the research in performance has been hindered by a lack of clarity on its meaning. In particular: The key elements of performance have not been consistently defined or agreed. Those defining performance as efficiency and effectiveness have not distinguished them clearly and/or related them within a formalism of performance. Many of the measures used in the research relate to influences on performance and not performance itself.

2.3 Design and design activity performance

Design activity modelling has received significant attention over the years aiming at the development of both descriptive and prescriptive models. This has resulted in the development of models offering different viewpoints of the design process such as the prescription of the activities/stages in design and their logical sequence, others focused on the cognitive nature of design and those relating design within an overall model of product development. These models are aimed at increasing our understanding of design (descriptive), and/or providing a framework (procedures, guidelines, etc.) in which to carry out design (prescriptive), so that the level of performance may be maintained or improved. However, performance in design requires continued attention to both the design (artefact) and the activities involved in producing that design. That is, both design (DG) and design activity goals (DAG) exist within design development and performance in relation to these goals must be distinguished yet related to overall performance. Design goals relate to aspects of the design (artefact) such as its dimensions, its form, etc. while design activity goals relate to the activities in design development and consider aspects such as the time taken and cost of resources. There is a reasonable consensus within existing models on the types of activities involved in design, their sequence, etc., and the evaluation of the output in relation to the design goals is a key component of the models discussed. However, the analysis of performance in relation to the activities carried out in design is restricted to literature addressing the management of design at the project level, e.g. [10]. It is proposed here that management activities are carried out at every level in design and therefore there is a requirement to analyse performance in relation to such activities at all levels.

A design performance model - E2

Although there is widespread use of efficiency and effectiveness to describe performance there are a variety of interpretations of these terms when applied in design and development. Efficiency (n) and effectiveness (II) are presented here as fundamental elements of performance which may be used to fully describe the phenomenon. That is:

ICED 01 - C586/442

539

Design Performance = Efficiency (n) and Effectiveness (II)

A new model, E2, is presented here as a novel and unique means to clearly formalise the phenomenon of design performance and allow efficiency and effectiveness to be distinguished and related. Efficiency is related to input, output and resources, while effectiveness is determined by the relationship between output and goal(s). These elements are presented within the E2 model providing a fundamental representation of activity performance.

3.1 Efficiency
In general, the efficiency of an activity is seen as the relationship (often expressed as a ratio) between what has been gained and the level of resource used. Assuming design as a knowledge processing activity (Ak) (Figure 2), the difference between the output (O) and the input (I) defines the knowledge gain from the activity (K + ). The cost* of the activity may be determined by measuring the amount of resource knowledge used (Ru). Therefore, the efficiency of this activity may be depicted as in Figure 2 and formulated as a ratio:

Where: n(Ak) I O K RU

: Efficiency (n) of an Activity (Ak) : Input (Knowledge) : Output (Knowledge) : Knowledge Gain : Resource (Knowledge) Used

Figure 2. Efficiency (TI)

This formalism assumes that a quantitative comparison of the input and output knowledge can be carried out that results in a description of the level of knowledge gained in the activity. Similarly, it is assumed that the level of knowledge used in the activity may be measured and that the relationship between both quantities may be expressed in a meaningful form. In practice a variety of metrics are used to determine efficiency, reflecting different aspects of the input, output or resource knowledge. For example the cost of using a designer within an activity may be measured to reflect the amount of financial resource used in utilising this knowledge source. Efficiency of an activity is considered here to exist irrespective of whether
Cost is used here as a general metric to describe the level of time, money, material, etc. used in the activity.

540

ICED 01 -C586/442

it is measured or not, i.e. it is an inherent property of the activity. The selection and application of metrics to determine efficiency allow particular views of efficiency to be created, e.g. cost or time based efficiency.

3.2

Effectiveness

Activities are generally performed in order to achieve a goal, i.e. have a desired effect. However, the result obtained from performing an activity may not always meet the goal. The degree to which the result (output) meets the goal may be described as the activity effectiveness. Therefore, activity effectiveness, as depicted in Figure 3, can be expressed as:

Where: n(Ak) rc O G

: Effectiveness (n) of Activity (At) : Relationship (Comparative) : Output (Knowledge) : Goal (Knowledge)

This formalism assumes that the output knowledge (O) and goal knowledge (G) may be described in a manner which allows a direct comparison between them, and a relationship to be determined which indicates how closely they match.

Figure 3. Effectiveness (n)

In design, multiple goals are likely to exist with different priorities. Therefore the activity effectiveness with respect to a single goal will often represent only a partial view of effectiveness measured using a particular metric. That is, effectiveness may be described in relation to particular type of goals, e.g. cost goals, in isolation of other goals such as time, artefact aesthetics, etc. The determination of overall effectiveness for the activity in Figure 4, n(A), presents a multiple criteria decision making problem. That is, to fully evaluate the design proposal some value of overall effectiveness must be established. There are a variety of techniques that may be adopted to support optimisation although the nature of the design activity is such that obtaining values with which to carry out optimisation is difficult, e.g. determining values for aesthetic elements. The weighting method [11] presents one of the simpler approaches to this type of problem. For example if we consider the priority (or weight) of the life in service goal (G1) to be W1 with respect to that of the dimensional accuracy goal (G2 of W2, then we could say:

ICED 01 - C586/442

541

Figure 4. Establishing overall effectiveness

3.3 Relating Efficiency and Effectiveness

Efficiency and effectiveness focus on related, yet contrasting performance elements. The efficiency is inherent in the behaviour of a particular activity/resource combination. It may be measured without any knowledge of the activity goals, although the goals may influence the behaviour of resources used in the activity and consequently the level of efficiency that results from their use. Effectiveness, in contrast, cannot be measured without specific knowledge of the activity goals. As is the case in measuring efficiency, the measurement of effectiveness involves the analysis of the activity output (O). However, effectiveness is obtained through analysing a specific element of the output knowledge, i.e. that which relates to the goal(s) of the activity. In certain cases there exists a direct relationship between effectiveness and efficiency. This relationship exists when the specific element of the output knowledge, which is evaluated to establish effectiveness, also describes an element of the resource used. For example, an activity may have a specific cost related goal of minimising the activity cost, i.e. Gj: C = Min. Therefore the element of the output knowledge (O) which must be evaluated is the cost knowledge (Oc). However, determining the cost based efficiency of the activity also involves the analysis of cost incurred (Ru-c) in carrying out the activity as part of the overall resources used (Ru). In this particular instance the element of output knowledge used to establish effectiveness is the same as that used to establish efficiency. Therefore, an increase in the cost based efficiency of the activity will also result in an increase in the cost based effectiveness of the activity, given an activity goal of minimising cost. In cases such as this one the efficiency of the activity can provide insight into why a particular level of effectiveness has been obtained.
This type of calculation is an over simplification and in many cases the elements cannot be easily defined.

542

ICED 01 -C586/442

In other cases a direct relationship between efficiency and effectiveness is not evident. Such cases exist where the specific element of the output knowledge that is evaluated to establish effectiveness has no relationship to the resource knowledge used in an activity. For example where the goal of a design activity may be to maximise the dimensional accuracy of the artefact, G(S) = Max(s), the element of the output knowledge (O) which must be evaluated is the knowledge of the dimensional accuracy (O(s)). It is clear that this knowledge provides no indication of the resource knowledge (R) used in the activity. Therefore an increase in dimensional accuracy will give increased effectiveness with respect to this goal but there is no direct relationship with efficiency in this case.

Evaluation

The research presented in this paper has been evaluated as part of an overall PhD project and is detailed in [12]. A number of approaches have been taken in evaluating the work: The development of a worked example using information from previously reported protocol studies to illustrate the application of the E2 formalism within a practical scenario. A large number of metrics existing within the literature have been reviewed and analysed in relation to the formalism to determine if the key principles were violated. Experts in design, performance measurement and management, and risk management from industry and academia have critically appraised the E2 formalism. The evaluation results illustrated that the E2 model could be used to describe performance using protocol data and measures of efficiency and effectiveness were defined using the formalism. The metrics reviewed from the literature could be distinguished within the area of efficiency or effectiveness and further insight into these metrics was gained, e.g. those metrics measuring influences on performance were distinguished from those measuring performance itself. The critical appraisal provided support for the comprehensiveness of the formalism and the key principles were seen to reflect and clarify industrial practice.

Discussion and Conclusion

The treatment of design performance within existing research lacks clarity on the nature of performance itself as a basic foundation for work in this area. The E2 model clearly distinguishes and relates the key elements of performance, efficiency (n) and effectiveness (n). Further, influences on performance may be clearly distinguished, e.g. flexibility may be viewed as the ability of a designer to adapt to changing goals. This influences the performance of the activity but is not in itself a measure of performance. The boundary of this model may be defined at the level of a specific activity or at other levels within design development such as project or program with the key principles remaining valid. The model has been used to further formalise the process of performance measurement and management, distinguishing and relating the performance of the design (artefact) to that of the activities involved in its development (product and process) [13].

ICED 01 - C586/442

543

References [1] Brown, S.L. and K.L. Eisenhardt, Product Development: Past Research, Present Findings, and Future Directions. Academy of Management Review, 1995. 20(2): p. 343-378. Neely, A., The performance measurement revolution: why now and what next? International Journal of Operations and Production Management, 1999. 19(2): p. 205228. Montoya-Weiss, M.M. and R. Calantone, Determinants of New Product Performance: A Review and Meta-Analysis. Journal of Product Innovation Management, 1994. 11: p. 397-417. Brookes, N.J. and C.J. Backhouse, Measuring the performance of product introduction. Journal of Engineering Manufacture, 1998. 212(1): p. 1-11. Chang, Z.Y. and K.C. Yong, Dimensions and indices for performance evaluation of a product development project. International Journal of Technology Management, 1991. 6(1/2): p. 155-167. McGrath, M.E., The R&D Effectiveness Index: Metric for Product Development Performance. Journal of Product Innovation Management. 1994. 11: p. 201-212. Johnson, H.T. and R.S. Kaplan, Relevance Lost - the Rise and Fall of Management Accounting. 1987, Boston, MA: Harvard Business School Press. Neely, A., M. Gregory, and K. Platts, Performance measurement system design: A literature review and research agenda. International Journal of Production and Operations Management, 1995.15(4): p. 80-116. Meyer, M.W. and V. Gupta, The Performance Paradox. Research in Organisational Behaviour, 1994. 16: p. 309-369. Cusumano, M.A. and K. Nobeoka, Strategy, Structure, and Performance in Product Development: Observations from the Auto Industry, in Managing Product Development, T. Nishiguchi, Editor. 1996, Oxford University Press, Inc. p. 75-120. Balachandran, M., Knowledge Based Optimum Design, ed. C.A. Brebbia and J.J. Connor. 1993: Computational Mechanics Publications. O'Donnell, F.J., A Methodology for Performance Modelling and Analysis in Design Development, in Design Manufacture and Engineering Management. 2000, University of Strathclyde: Glasgow. O'Donnell, F.J. and A.H.B. Duffy. Design Activity Modelling: A Performance Viewpoint, in International Conference on Engineering Design (ICED 01). 2001. Glasgow.

[2]

[3]

[4] [5]

[6] [7] [8]

[9] [10]

[11] [12]

[13]

Frank J O' Donnell E-business Group, Scottish Enterprise, 120 Bothwell St., Glasgow, G2 7JP, Scotland, Tel: +44 (0)141 228 2950, Fax: +44 (0)141 228 2882 , E-mail: Frank.Odonnell@scotent.co.uk , URL http://www.scottish-enterprise.com/ebusiness IMechE 2001

544

ICED 01 - C586/442

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A METRICS METHODOLOGY DEVELOPED IN CO-OPERATION WITH INDUSTRY

M W Lindley, M Muranami, and D G Ullman Keywords: Performance metrics, business process reengineering

1 Introduction
Process performance metrics (in contrast to product performance metrics) are not routinely used in physical product generation industries. Process information is often viewed as paperwork burden, without inherent value-added. However, research papers on product development have proposed that the product development process (PDP) used by a company has direct impact on the resulting quality of the finished product [1]. In order to realize improvements to the process, the company must be able to compare their original PDP with the proposed changes. Therefore, a method to measure the PDP is needed. Measuring the process is not a trivial task [2], since the tools required to measure the process in various industries need to be customizable, scalable, and usable in real-time, during execution of the PDP. The goal of the research presented in this paper is to develop a general, cross-industry methodology for developing process performance metrics for the purpose of assessing a company's PDP. The aim of metrics is to monitor measurements that directly affect the PDP in terms of process cost, process time, and information quality. With metrics, engineering management is able to make better decisions to keep the PDP on track. The target audience for the methodology described includes any product generation company concerned with improving its mechanical design process. Efforts were taken to make the methodology flexible and to tailor the metrics to the PDP that the company employs, regardless of process formalization or organizational structure. For this research, data collection and methodology verification were conducted at three industry partners over a period of nine to twelve months: Company X is a small, for-profit, off-road equipment manufacturer with in-house mechanical design and manufacturing capabilities, producing approximately 20 units per month. Company Y is a global, for-profit electronic product generation firm with contract product development and manufacturing, with production volume of 100,000 units per month. Company Z is a product generation organization within a non-profit government research body, with in-house design and manufacturing, which produces one-off research instrument systems on an annual schedule. A paper further detailing the application of this methodology at the partner companies is available [3].

ICED 01 -C5 86/468

545

2 Description of the metrics methodology

First, definitions for key terms used in the methodology are in order. A measure of a process is a quantified attribute of a process entity that characterizes the attribute. A measure has no inherent 'good' or 'poor' value. A metric for a process is a performance indicator relating a measure to a target value; a metric evaluates the process entity in that it indicates deviation of the process entity from its target value. An example of a measure is 'time to generate drawing', while an example of a metric is 'target time to generate drawing is 6 weeks'. The metrics methodology consists of four steps: Document the existing Product Development Process (PDP). Construct the Process Measurement Matrix (PMM). Identify the subprocesses with greatest impact on successful execution of the PDP. Create quantitative metrics by developing measurements of the critical subprocess attributes and relating the measurements to target values.

2.1 Step one: document the current design process

At the industry partners, the researchers documented the product development process as practiced in the most recently completed program. Existing product development process documents, if available, were collected at the companies. Where no documentation existed, product development practices were first written down and organized. Finally, interviews with practicing engineers were conducted to capture a complete picture of the PDP as practiced. The PDP date was then formatted into a flow diagram arrangement, showing process steps with inputs and outputs [4]. The flow diagram provides a graphical representation of the relationships among the steps of the design process. While predominant steps are common to most industries, each company and every project exhibits differences. The flow diagram includes project specific steps and is expandable to provide finer details of the design process.

2.2 Step two: construct the process measurement matrix (PMM)

The process measurement matrix (PMM) [5] is a PDP management tool, which relates process management to specific steps of the product development process. The PMM also provides relative weightings of how resources are utilized during a PDP. The PMM resembles a quality function deployment (QFD) House of Quality in structure [6]. It organizes process numerical measurements instead of the QFD product numerical engineering requirements. Constructing the PMM begins with modeling the resources and requirements as inputs, and the deliverables as outputs. These inputs and outputs serve as the framework for the PMM. A simplified PMM is shown in Figure 1, with matrix entries labeled Field A through Field I.

546

ICED 01 - C586/468

Figure 1. Process Measurement Matrix (PMM) [4]

Field A: Name of the target process within the PDP. This is the process for which the PMM is constructed. Example: 'mechanical design creation process'. Field B: Names of internal subprocesses of the target process. The names of all the subprocesses necessary to complete the target process are listed in columns. Example: 'drawing creation'. Field C: Numerical ranking of the internal subprocesses in Field B in order of most constrained to least constrained - highlights the most critical internal subprocesses. Example: 'drawing creation: rank 1'. Field D: Numerical measures for internal subprocess attributes and their actual values. Process metrics are created from these measures. Example: 'assembly drawing creation: 6 weeks'. Field E: Requirements, resources, and deliverables names. The names of all the inputs and outputs for the target process are listed in rows. Example: 'draftsman: 20 manweeks'. Field F: Benchmark target numerical values for requirements, resources, and deliverables. Example: 'target draftsman: 18 man-weeks'. Field G: Target numerical values for internal subprocess attributes. Example: 'assembly drawing creation: 4 weeks'. Field H: Indication of degree of dependency among internal subprocesses of the target process. Example: 'dependency between assembly drawing creation and production operator training: high'.

ICED 01 -C586/468

547

Field I: Indication of degree of dependency among requirements, resources, and deliverables of the target process. Example: dependency between draftsman man-hours and production operator man-hours: medium'. A key decision required prior to PMM construction is selection of the level or granularity for the PMM. The highest level PMM is constructed for the whole PDP, with the entire product generation enterprise as resource, product financial objectives as requirements, and sale of the finished product as the deliverable. Numerous internal subprocesses are required to accomplish this top process. A PMM can be constructed for every one of these subprocesses, with finer granularity requirements, resources, and deliverables. Each of the subprocesses in turn consists of smaller internal subprocesses with finer granularity inputs and outputs. The PMM, created in Step Two allows visualization of relations among subprocesses and their inputs and outputs. By filling in entries along a row, the matrix format clearly reveals the significance of an input (a requirement, a resource, or a deliverable) to each of the internal subprocesses. Likewise, by filling in entries down a column, the matrix format highlights essential inputs to a subprocess. Since the entries are numerical measures, the PMM drives the conversion of qualitative attributes into numerical quantities, allowing visibility of control at the engineering level. Another contribution of the PMM is that it makes visible non-obvious relationships among PDP portions, especially chronologically separated subprocess steps. Interviews with engineers during Step One revealed dependencies between subprocesses and between PDP inputs that are entered in Field H and Field I. Recognition of these dependencies assists the next step of the methodology, in which PDP constraints are identified.

2.3 Step three: identify critical process areas that need improvement
With the target process organized by the PMM into subprocesses, inputs, and outputs, critical components of the process now need to be highlighted. Various methods can be used to identify critical process portions. The interviews with engineers revealed areas of process constraints at each of the companies. The Theory of Constraints (TOC) [7] was used to augment the PDP flow diagram to identify constraints in the system. Targeting the constraining portions of the design process maximizes improvements to the system. The portions of constraint identified in the target process are now entered into the PMM. The subprocesses in Field B of the PMM are ranked from most critical to least critical using a general ranking process (such as [8]). Alternatively, this ranking is accomplished through prioritization methods unique to each company's business (see [10] for an example). The numerical rank for each subprocess is entered in Field C of the PMM, and gives ready visibility to constrained portions of the PDP. The subprocess that most constrains the target process is the best candidate for assessment using metrics. This highest-ranking subprocess is called the critical subprocess, and is used for metrics creation in the next step of the methodology. The PMM facilitates visualization and organization of inputs, outputs, dependencies, and targets for this critical subprocess. The first three steps identify where to develop process metrics. The last step - Step Four generates what the metrics are.

548

ICED 01 - C586/468

2.4 Step four: create metrics for each critical subprocess

The purpose of the process metrics developed in this methodology is to compare the actual (measured) value of numerical attributes of the PDP to the desirable target (benchmark) numerical value. Using the metrics, engineering management then makes decisions that move measured values closer to benchmark values. PDP metrics measure attributes specific to design process steps and compare them to benchmark information about the steps. A metric is the numerical relationship of the measure of the consumption of resources and the completion of deliverables versus the benchmark usage developed from the PMM. In this methodology, six tasks are required for metrics creation. Task 1: List the internal subprocesses of the critical subprocess as PMM column entries. These internal subprocesses are monitored using appropriate measures, which are used in generating further measures and metrics for this critical subprocess. Task 2: List all the numerical measures and target values for attributes of requirements, resources, and deliverables that flow into and out of the critical subprocess. These attributes were specified in the row entries of the PMM. Note that during actual execution of the overall PDP, these target values may need to be adjusted before execution of the target process portion begins. Given these target values, the PDP team members responsible for this PMM target process formulate internal targets for each of the internal subprocesses (Field G). One of these internal subprocesses is the critical subprocess. Using these target values, a metric for the critical subprocess is constructed. Task 3: Find the relationships among measures for monitoring through metrics. Develop formulae that capture the deviation or delta between target value and actual value for the numerical attributes of requirements, resources, and deliverables. The target value, is obtained from the PMM, while the actual value will be captured when the subprocess is actually executed during the PDP. Task 4: Create a metric by combining these delta values in formulae that show how the subprocess is actually consuming inputs and delivering outputs, compared to target values for inputs and outputs. Once this methodology is applied repeatedly at the same company, requirements, resources, and deliverables from previous programs become known, and allocations that resulted in successful program execution serve as benchmarks for future program metrics development. These new benchmarks are then applied to Tasks 3 and 4. Task 5: Again, for the critical subprocess, repeat Tasks 2 through 4 for the next measure for which a metric is desirable. A significant critical subprocess with multiple deliverables requires additional metrics for complete monitoring. Task 6: Repeat Tasks 1 through 5 for the second most critical subprocess, as identified by the PMM for the target process. Repeat for subprocesses further down in importance until a thorough but manageable list of metrics is generated. With these six tasks under Step Four of the methodology, the company is guided to construct the most critical metrics that indicate success of the PDP. By developing these metrics before starting a product generation project, engineering management becomes focused on measuring subprocesses attributes that have the most influence on successful outcome. The Tasks 1 through 6 described above outline the most thorough and rigorous application of this process metrics methodology. An advantage of this methodology is its scalability, depending on the organizational and operational characteristics of the enterprise. As noted in the introduction, the three industry partner companies with diverse endeavors serve as good

ICED 01 -C586/468

549

examples of this scalability of the metrics methodology. Case study highlights from the three companies are presented next to illustrate the above tasks.

3 Verification of the metrics methodology at the industry partners

The methodology was verified by application at companies that differ in industry type, size, and PDP maturity level. The researchers selected projects at the respective companies and conducted the four step metrics methodology. Details of implementation of the methodology at companies X, Y, and Z, and descriptions of the actual metrics developed can be found in references [9], [10], and [11] respectively. In addition to process metrics generation, the case studies show a cross-industry benefit from application of this metrics methodology: the rigor required in documenting the PDP in preparation for PMM construction led to new techniques of process analysis. In Company X, process information sheets, which rigorously gave the purpose, inputs, and outputs for each PDP stage were created. In Company Y, dependencies among subprocesses were discovered through process defect tracking, which is a new method of analyzing the process flow diagram. In Company Z, minimum PDP requirements were documented for creating meaningful process metrics at companies that employ an informal process. In all three instances, the industry partners gained tangible process tools and techniques usable by engineers and managers, independent of PMM and metrics construction. Highlights of process metrics benefits realized at each of the partner companies are summarized. Company X: The top level PMM generated for the company PDP showed that the time and funds spent in executing the critical subprocesses had the greatest impact on successful fulfillment of top-level requirements. Due to the fairly small company size, management and the researcher agreed that long-term payoff from application of this metrics methodology will result from focusing only on these critical subprocesses. Company Y: The results from PDP analysis revealed weak engineering input during early program phases. This lack of engineering input resulted in most process defects being generated in these early phases. Frequently, in past product generation programs, these defects would manifest symptoms much later in the PDP in the form of schedule slips from unplanned tooling modifications, product material cost increases, increased field service costs, and reduced customer utility derived from the released product. The process flow diagram and PMM derived metrics generated through application of the methodology presented in this paper forced engineering based scrutiny of tasks and deliverables within these early program phases. The Company gained the insight required to 'pay early' by allowing engineers to take the time and resources to improve the quality of early PDP deliverables. This initial consumption of resources reduces the risk of having to 'pay later' in schedule delays, cost increases, and product quality reduction. The metrics quantified and helped company management visualize the tradeoffs required for overall process improvement Company Z: The metrics for time and cost revealed how the resources were being affected by time constraints. The metrics for deliverables showed the degree of completion along each step of the design process. By comparing the resource usage against the completion of each project step, decisions were made to ensure project progress. By comparing the resources required for completion of one step to resources required for completion of

550

ICED 01 - C586/468

another concurrent engineering step, the methodology guided appropriate resource balancing.

4 Conclusion
The metrics methodology created by the authors and generated the following benefits at the industry partners: Rigorous documentation of the product development process. Creation and utilization of the Process Measurement Matrix to organize and prioritize target process requirements, resources, and deliverables. Identification of constraints in the PDP that lead to deficiencies during execution. The constrained portions are critical subprocesses. Creation of measures and metrics for the most critical subprocesses. Verification of usefulness of the metrics methodology through application to current product generation programs. The methodology developed here was shown to work in three companies with diversity in industry, size, and PDP maturity. The methodology is scalable to adjust to specific needs of individual companies.

5 Acknowledgement
This research is sponsored by the National Science Foundation under Grant DMI-9634768. References [1] Hauser, J. R., "Research, Development, and Engineering Metrics", working paper, International Center for Research on the Management of Technology, MIT Sloan School of Management, 1996. Smith, D., The Measurement Nightmare. The St. Lucie Press, 2000. Lindley, M.W., Muranami, M., & Ullman, D. G., "A Metrics Methodology Developed in Cooperation with Industry: Method and Case Study", submitted to Research in Engineering Design. 2001. Ullman, D.G., The Mechanical Design Process. 2nd ed., McGraw-Hill, 1997. Wright, A. L., "A Theory of Product Design Process Management", Ph.D. dissertation, Department of Mechanical Engineering, Oregon State University, 1999. Clausing, D., Total Quality Development: A Step-By-Step Guide to World-Class Concurrent Engineering. ASME Press, 1994. Dettmer, H. W., Breaking the Constraints to World-Class Performance. ASQ Quality Press, 1998. Saaty, T. L., Decision Making for Leaders. Wadsworth, Inc., 1982.

[2] [3]

[4] [5] [6] [7] [8]

ICED 01 - C586/468

551

[9]

Schlegel, S., "A Product Development Methodology Based on Concurrent Engineering Theory for Use in Small Manufacturing Companies", thesis, Department of Mechanical Engineering. Oregon State University, 2000.

[10] Muranami, M., "A Metrics Methodology developed for High Volume Product Generation Organizations", project, Department of Mechanical Engineering, Oregon State University, 2001. [11] Lindley, M.W., "A Metrics Methodology developed for Non-Profit Research Organizations", project, Department of Mechanical Engineering, Oregon State University, 2001. Prof. David G. Ullman Department of Mechanical Engineering, Oregon State University, Corvallis, Oregon 97331, USA, Tel: (541) 754-3609, E-mail: ullman@engr.orst.edu, URL: http://www.engr.orst.edu/~ullman/. IMechE 2001

552

ICED 01 - C586/468

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

IMPROVEMENT OF ENGINEERING PROCESSES

S Vajna, D Freisleben, and M Schabacker

Keywords: Knowledge-based Engineering Process Model, General Process Elements. Evaluating Engineering Processes

Introduction

Processes form the kernel of engineering (i.e. marketing, development, design, and production planning [1]). Process models can be used to improve engineering processes. A holistic engineering process model allows a comprehensive and general representation (i.e. description, formalisation, and structure) as well as the support of all activities in product development. A large range of different procedures and methods supports engineering processes. For their application, appropriate manual and/or computer-aided tools are required. Although most investments are made into these methods and tools including their handling, the resulting benefits occur mostly on the procedure and process level. In this paper a knowledge-based engineering process model (KBEPM) will be described.

Definitions

For a common understanding frequently used terms in this contribution are defined as follows (figure 1): A process is a set of activities or subprocesses for solving a task. Its length and duration do not limit the set of activities. A subprocess is a subset of a process and is also a set of activities or other subprocesses. A process element describes an activity respectively of one or several working steps. It is started by one or several events and ends in one or several events. The single process elements (activities) are self-contained in content, and they are in a logical context to each other [2J. Their description is based on a defined structure so that they are suitable also for the application in a computer-aided system. A working step is the smallest subset of an activity in product development. A process model is the sum of process elements together with the rules of relations between the process elements. A procedure is a certain sequence of activities (working steps) respectively processes which leads to the fulfilment of one or several aims of a process by the application of methods and/or tools.

ICED 01 - C586/663

553

A method is an organised collection of rules, which allows a methodical fulfilment of one or several aims of a process. Rules are of immaterial nature. A tool is a resource, which supports the achievement of one or several aims of a subprocess.

Figure 1. : Relations between process, subprocess, and process element

Knowledge-based Engineering Process Model (KBEPM)

One serious potential way of improving engineering is to rearrange and to optimise processes, their structure, and their appropriate activities. For an effective improvement it is necessary to know well, to monitor, and to control all processes and activities. Process models can be applied for formalisation, structuring, and description of any processes and objects treated in these activities. Main goal of the KBEPM presented here is the provision of proven activities or working steps (either in a sequence or in parallel), procedures, methods, tools, and application modules (all together with the appropriate knowledge) in form of a computer-based navigation tool. This tool assures that a user doesn't "forget" any of the necessary activities in the development of a product. The KBEPM is based on process elements. Process elements offer the possibility to define processes in a formalised way. They can adapt very flexibly to different requirements. Due to their coherent description they can also be represented graphically. One of the advantages of using process elements for the description of the design process in the KBEPM is the possibility to reuse a process element for similar processes.

554

ICED 01 - C586/663

Existing literature and references include a large number of proposals that describe how to pass through the phases of product development using a lot of different activities. For the definition of the general process elements of the KBEPM various models and procedures from the following authors were analysed and compared: The work of Pahl and Beitz [3] was used because their design process procedures are well known and because these procedures are taught in the majority of universities in Germanyoffering design education. The VDl-Guideline 2221 [4] was created as a broadly accepted guideline for companies (and normally should be well known there. Hansen [5] was one of the first authors who investigated methodical procedures for the design process. A lot of the later approaches are based on Hansen's work. Hubka [6] describes a general process model of design for the new design of technical systems, e.g. machines and installations. Dietrych and Rugenstein [7] take into consideration early in the process the aspect of production preparation. Eversheim [8] describes the activities of production preparation in much detail but without a link to the previous design process. Blessing [9] defines matrices that describe activities with an assignment to product components. This is a quintessence of many theories above all from the English speaking area. By using these models and procedures, about 50 process elements were designed to cover all activities from the first idea or the identification of needs (either of a customer or of the market) until the release to manufacturing. To get these general process elements, the content of every model from the list above was compared to each other: New process elements were added, if an activity was missing, e.g. for applying a new technology like rapid prototyping in the early phases of the design process. Process elements were cleared, if in another process element the same activity was alreadytreated or the same information was created. Extensive process elements were divided up if too many different working steps were included in one activity. Similar working steps were combined to one process element, if they created either equal output information and/or documents of the appropriate activities. To support the design process by the intensified use of methods and tools, more than 100 possible or necessary methods and tools applied in the design process were registered and formalised. Subsequently, a method base was set up in which every process element is associated to its potential/ possible methods, tools, and applications [1], By this way the KBEPM provides the user only those methods and tools which are the most appropriate to support the activity of a specific process element. The method base also is open for adding and modifying general and company specific methods and tools at any time.

ICED 01 - C586/663

555

Each process element operates like a module. By a variable combination of the general process elements and the special use of methods and tools the process model can be adapted easily to a lot of different requirements of company specific product development processes. The KBEPM is being implemented using standard software tools. This makes it possible to improve existing engineering processes, to navigate users along the product development process, to react dynamically to disturbances along the ongoing development of the product (e.g. when a customer changes the requirements of the product during order processing), to monitor processes and their improvement, and to capture the design intent.

Predicting and Measuring Costs and Benefits

Additionally, an evaluating tool based on [10] was included for predicting and measuring costs and benefits of process improvements. In a first step, this evaluating tool is intended to measure benefits of processes and tools (e.g. CAD, EDM), in a second step benefits of methods will be included. In business theory there are no suitable benefit evaluation procedures. Another problem is the missing process orientation as well as an inadmissible mix of quantifiable and qualitative benefits (if they are not be even neglected). Hence, the results are difficult to comprehend [11]. Because the benefits of processes and tools can be found in the whole product development, two views, the process view and the tool view, have to be regarded. The economic proof of the (optimised) processes can be measured rather easily using process throughput time, process costs, and process quality (the necessary formula and procedures are described in [10]). Compared to the process view, the economic proof of the application of tools is very difficult (and even worse for computer-aided tools). Hence, a method for benefits recording is necessary. There are two ways: the classical approach of costs, quality and time, and a Controlling approach. The drive to record benefits of tools is the classical requirements like less costs, quality improvement and reduced throughput time. However, these requirements have different meanings in context with processes, procedures, methods, and tools in product development, as well in co-operation with the customers. There are overlappings because e.g. time reduction can be transferred to cost reduction. Several interpretations are possible because e.g. quality can be product quality, service quality, or staff quality (to be achieved by qualification). Also it has to be regarded that companies are structured in projects for the implementations of temporary plans. Hence, six benefit categories were defined in [10]: staff environment, tool application, product quality, service quality, process performance, and project performance. Exemplary benefits were related equally to the single benefit categories. In the single benefit categories for benefit evaluation, the benefits that can be quantified completely by monetary means and benefits (where the quantification is possible but with difficulties). These benefits are classified in so-called benefit classes based on the VDI guideline 2216 [12]. The benefit class "synergy effects" extended the benefit classes, which covers company internal and external synergies. These five benefit classes can be arranged as a portfolio. This portfolio is called the Benefit Asset Pricing Model (BAPM) portfolio. It is shown in [10] that this portfolio is similar to a portfolio in the capital market containing shares, bonds, and zerobonds. Hence the portfolio theory of Markowitz [13] as well as methods and

556

ICED 01 -C586/663

procedures for yield and risk evaluation of capital market investments can be applied on the benefit evaluation. The result of these similarities is shown in figure 2.

Figure 2. : Similarities of benefit classes and capital market investments

An additional way to get the benefit categories was based on the resulting difficulties that appeared not only during benefit recording and evaluation but also mostly in classical Controlling [10]. Therefore, new controlling methods had to be found. One of these was the Balanced Scorecard [14], which was created originally for manufacturing. The Balanced Scorecard is able to give a financial value to product development, processes in the company, staff know how, staff motivation as well as staff flexibility, and customers loyalty, and new technologies, even then if these topics are not listed in a company balance. The Balanced Scorecard was the unique new controlling instrument that focusses on customers, staff, and processes. All other instruments focus only on one of these aspects like e.g. Total Quality Management on quality. Moreover, the Balanced Scorecard applied in product development, offers the same six benefit categories (figure 3) which can be derived by the interpretation of the original four Balanced Scorecard perspectives [14]: 1. learning and development perspective 2. staff perspective 3. process perspective 4. financial perspective. To summarise, the results of both approaches, the classical approach of the benefit categories costs, quality and time as well as the classical Balanced Scorecard approach, are shown in figure 3. The benefits in the different benefit categories of both approaches can be related to benefit classes. In KBEPM the tools which were applied during processes and activities and further information of costs and throughput time are available. In order to apply the BAPM in context with KBEPM the following procedure is recommended (figure 4): The information of applied methods and tools, the used time and costs altogether are transferred into the BAPM module. In BAPM benefits are classified in benefit categories and in benefit classes. To get the individual yield of each benefit class, each benefit in each class has to be evaluated. The application of the portfolio theory of Markowitz results in the respective yield-and-risk-portfolio of each benefit class. Applied for the sec-

ICED 01 - C586/663

557

ond time, the portfolio theory of Markowitz now delivers the yield-and-risk-portfolio of the whole benefit portfolio. The output of the benefit evaluation is placed in an Internet Browser window (details shown in figure 4).

Figure 3. : Derivation of the benefit categories in product development and Balanced Scoreeard

Figure 4. : Software approach of BAPM

558

ICED 01 - C586/663

Figure 5 shows the output of the results of benefit evaluation in a spreadsheet format.

Figure 5. : Monetary evaluation of benefit classes

Conclusion

Based both on the research work on engineering process improvement by using general process elements in a holistic engineering process model and on the evaluation of these improvements, this contribution should motivate the discussion with other groups dealing with similar approaches. The next step is the application of these research results in industry to get more experiences. References [1] [2] Vajna. S., Freisleben. D., Scheibler, M, "Knowledge Based Engineering Process Model". Proc. ICED '97. Tampere. 1997, pp. 181-184 VDl-Guideline 2219, "Datenverarbeitung in der Konstruktion, Einfuhrung und Wirtschaftlichkeit von EDM/PDM-Systemen", VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf l999 Pahl, G.; Beitz, W.: Konstruktionslehre: Methoden und Anwendung, Springer-Verlag, Berlin Heidelberg New York London Paris Tokyo Hong Kong Barcelona Budapest 1997

[3]

ICED 01 - C586/663

559

[4]

VDI: VDl-Richtlinie 2221 Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf 1993 Hansen, F.: Konstruktionswissenschaft: Grundlagen und Methoden, VEB Verlag der Technik, Berlin 1974 Hubka. V.: Allgemeines Vorgehensmodell des Konstruierens, Fachpresse Goldach. Zurich 1980 Dietrych. J.; Rugenstein, J.: Einfuhrung in die Konstruktionswissenschaft, Technische Hochschulc Otto von Gucricke Magdeburg, Politechnika Slaska im. W. Pstrowskiego Gliwice 1982 Eversheim, W.: Organisation in der Produktionstechnik, VDI-Verlag, Dusseldorf 1989 Blessing. L. T. M.: A Process-Based Approach to Computer-Supported Engineering Design, Black Bear Press Ltd, Cambridge 1994

[5] [6] [7]

[8] [9]

[10] Schabacker, M.: "Benefit Asset Pricing Model - Ein Modell zur Nutzenbewertung neuer Technologien in der Produktentwicklung'", am 22.02.2001 verteidigte Dissertation an der Fakultat fur Maschinenbau der Otto-von-Guericke-Universitat Magdeburg [11] Bauer, F.: "ProzeBorientierte Wirtschaftlichkeitsbetrachtung von CA-Technologien", Europaische Hochschulschriften Reihe V Volks- und Betriebswirtschaft Vol. 1813, Europaischer Verlag der Wissenschaften. Frankfurt am Main, 1995 [12] VDI-Guideline 2216. "Datenverarbeitung in der Konstruktion: Einfuhrungsstrategien und Wirtschaftlichkeit von CAD-Systemen", VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf 1990 [13] Markowitz, H.M.: "Portfolio Selection", Journal of Finance. March 1952, pp.77 - 91 [14] Kaplan, R. S., Norton. D. P.: "Balanced Scorecard - Strategien erfolgreich umsetzen", Schaffer-Poeschcl Verlag Stuttgart, 1997 Prof. Dr.-Ing. S. Vajna Otto-von-Guericke-University of Magdeburg, Computer Applications in Mechanical Engineering, Universitatsplatz 2, D-39106 Magdeburg. Germany, Tel: +49-391-67-18794. Fax: +49-391-67-11167. E-mail: vajna@mb.uni-magdeburg.de. URL - http://imk.uni-magdeburg.de/LMI/lmi.html Dr.-Ing. D. Freisleben. Dr.-Ing. M. Schabacker EPI-K AG, Listemannstr.l0b. D-39104 Magdeburg, Germany, Tel: +49 -391-53558-0, E-mail: doerte.ireisleben@epikag.de. michael.schabacker@epikag.de. URL - http://www.epikag.de IMechE 2001

560

ICED 01 -C586/663

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

PROCESS PERFORMANCE MEASUREMENT SUPPORT - A CRITICAL ANALYSIS

M K D Haffey and A H B Duffy Keywords: Design Management, Performance Management, Performance Metrics.

Introduction

Design development processes, within engineering disciplines, lack the necessary mechanisms to identify the specific areas where improved design development performance may be obtained. In addition, they lack the means to consider and align the goals and respective performance levels of related development activities within the consideration of an organisation's overall goals and its required performance dimensions and levels. Current research in organisational performance behaviour, formalised through performance frameworks and methodologies, has attempted to identify and focus upon those critical factors which impinge upon a wealth creation system while attempting to, simultaneously, remain representative of organisational functions, processes, people, decisions and goals. Effective process improvements remain conditional upon: the ability to identify potential areas for improvement and to define the goals and subsequent measures which will support the realisation of such goals; the ability to measure the potential performance gains which may result from an improvement initiative; and, the ability to understand existing process dynamics and the subsequent impact of some change to a system/process. The objective of this paper is to discuss some of the management techniques, which are purported to support various process performance issues and perspectives, and identify the major factors that remain unsupported in identifying, measuring and understanding design process performance.

Process Performance

Engineering design development processes involve designers developing product designs that possess the potential to meet the requirements of both prospective customers, and the specific standards delineated through internal and external influences. In addition, designers must be guided and controlled by the needs and strategic intentions of an organisation placed in a local context through the directives and focus of middle management. Design development processes are responsible for producing an output or product design that has the potential to be delivered to the customer in the form of a product, through subsequent development stages by considering various internal and external perspectives and requirements. For example, the design development process, considering both the design activity and its management, must realise the potential to deliver a product to the market place: at an efficient cost when placed in the context of market price; at an optimum point of market entry to satisfy customers delivery requirements and ahead of market competition; at a level of quality that the customer is at least expectant of while superior to market competitors in the aspects that a market will base its decisions upon to purchase; and, that will support the long term survival of an

ICED 01 - C586/653

561

organisation and the financial health expected by shareholders [1]. Thus, designers and design development managers must acquire, modify and/or generate the information that enables them to manage design processes/activities and design products that: firstly, align with, and satisfy, the required dimensions of organisational performance and that are congruent with the goals and objectives of the associated product development process functions such as manufacturing; and secondly, that will perform in the market place from such dimensions as return on investment. Design development activities are therefore forced to consider not only their own output or deliverable, from within the alignment of both internal organisational perspectives - from strategic level objectives (macro) to general design development goals (micro) - and the objectives and standards associated with the external organisational environment, but must, in addition, produce a design deliverable that will remain congruent with the objectives and goals of subsequent, and indeed previous, development activities. The statement that an organisation's core competencies are the building blocks of competitive advantage [2] brings to the fore the second, high level, concern of performance measurement, namely, that of how organisational strategies may be developed based on the strengths and weaknesses of lower level functions and processes [3]. Thus, the formulation of a strategy necessitates the need to understand the many relationships and interactions that may exist internally and externally to an organisation's environment i.e. identifying where major strengths and weaknesses, and opportunities/threats, are likely to arise. From the discussion certain factors need to be addressed in order to support an organisation in determining the areas that it or its processes should be utilising or improving upon (bottom up) and in measuring the levels of performance required to develop and deploy organisational strategies (top down). The following points explicate the fundamental components that would support organisations in formulating strategies, based on performance levels obtained at a design development process level, and in guiding development activities by placing process specific goals in the context of realising high-level organisational strategies. Thus, the aspects presented refer to the means of getting high-level concerns and objectives down to a process level, and within their context, to feedback the information to an overall organisation level. Definition of Goals: Design Development processes are, for the most part, subject to product requirements in terms of functional and behavioural considerations but lack support in placing these specific requirements or goals in context with organisational strategies and goals. From an improvement point of view the development and definition of goals infers that gaps or suboptimal results have been identified. Thus, measurements relating to a process's level of performance are required to support in identifying what must be protected or improved upon to satisfy organisational objectives and customer expectations and requirements. High-level strategic goals or objectives need to be decomposed into process specific objectives, providing the ability to relate and align process specific performance measures with the needs and strategic direction or focus of the organisation, and in turn providing the ability to link company objectives to daily activities and decision making activities [4]. The following points outline why the setting of realistic and informed strategic objectives is required to succeed in satisfying those objectives, and to an organisation's overall level of performance. Alignment: Consideration must be given to how high-level organisational objectives will be viewed at the process level and how they will effect (i.e. contribute or constrain) upon the specific goals and objectives of development functions and visa versa [5]. Congruency. Objectives bring a focus to activities and processes and the sub-optimisation of activities, processes and products may occur as a result of project teams optimising solutions or process outputs to fit with their functionally specific objectives while being

562

ICED 01 - C586/653

counter-productive to the outputs of other departments [6]. Therefore, outlining the goals for one design development activity should be placed in a wider organisational context to assess its contribution or constraint on other functions achieving their goals. Constraints and Contributors to Success: The provision of objectives and the determination of how they may be realised aids in highlighting and distinguishing between obstacles that may restrain, or opportunities that may promote, the level of performance obtainable from within the focus of an objective [7] and provide the means to control the number of measures being required. It therefore remains pertinent to the success of outlining and satisfying goals that distinctions are made between constraints and contributors of the levels of performance and the specific dimensions of success. Learning'. Objectives may be detailed that are ambitious, while yet achievable, in terms of their satisfaction but such ambitious 'stretched' objectives force personnel to think and analyse the sequence and structure of the process and the way work is carried out. The setting of goals requires that, firstly, the ability to determine what state an organisation, process, etc. is in (i.e. an 'as is' understanding) from which goals can be derived and, secondly that the organisation recognises where it wants to go or what aspects it wants to improve upon (developing a 'to be' understanding). Consideration should be given, therefore, to ensure that goals outlined are ambitious but that remain within the realms of feasible in terms of process, technology and personnel capabilities. Composition of Metrics: In order to support the realisation of organisational goals, at various levels and considering the alignment, congruency, constraints and contributors of success, the identification and determination of the measures (metrics) that will help in checking the progress being made toward such goals and in determining whether such goals support higher organisational goals must be supported to determine how close you are to a target and how quickly you are moving toward a target [5]. The aim of controlling and defining the measures used at a process level, and maintaining the existence of a cascading effect is to promote a common direction, in terms of obtaining the best return on effort and work, toward common, higher level, objectives while considering the often functionally specific goals which may be beneficial to the function but not to the overall process performance level [8]. Current research within the area advocates the need to balance the mix of measures between highlevel organisational dimensions while the identification, and application of appropriate metrics within such balanced dimensions remains to be conducted erratically and intuitively. Overall and Sub-level Index: Providing management and process level personnel with an inter-related and flexible method to specialise and generalise measures throughout an organisation, while maintaining the congruency and alignment of measures, provides the ability to obtain an overall sense of improvement or detriment at various organisational levels and the means to specialise their focus to identify (sub) optimal performance. The ability to generalise from lower levels of an organisation to drive an overall performance index enables: the identification of contributors and retractors of performance; the ability to compare the performance of distinct departments, functions etc.; and, allows management to generalise and specialise their focus or concerns providing the means to control the range of measures in reflecting and supporting organisational strategic viewpoints. Relational structures: The preceding points have all discussed the need to enable the relations between goals, metrics, organisational functions to be identified, quantified and structured. There is thus a need to: firstly, understand how the satisfaction of one goal will impinge upon other organisational goals identifying any conflict between goals; secondly, detail the structure of metrics throughout relevant functions of the organisation to provide

ICED 01 - C586/653

563

focus and to identify the level of progress being made; and lastly, enable performance measurements to reflect the structure of an organisation and the hierarchy of goals within. In addition, any person involved in an organisation has a perspective on the organisational system and therefore their goals may be different, or refer to distinct but affected or affecting goals. Thus, an organisational wide performance measurement system should relate between measures/metrics, goals/objectives and perspectives/viewpoints. While the identification of the relationships between related entities enables more informative decisions to be made, the need to identify their effects, i.e. positive or negative, relative to the perspectives, and the density of interactions are also important in determining the stability of a process and how changes made to improve performance will be received by other organisational functions [9]. The existence today of a plethora of various performance measurement systems has indeed pushed our understanding of the constituent factors of organisational performance and given practitioners a multitude of issues and dimensions of performance to consider. However, at a fundamental level of performance, in determining organisational down to process levels of performance, we need to understand how do such performance measurement approaches, frameworks, formalisms and methodologies perform.

Performance Measurement Systems

The design and application of performance measurement systems has been, primarily, focussed on providing a means of controlling the development and deployment of strategic directions taken by organisations but in addition provides the means to identify the improvement requirements and the drive behind improvement initiatives [10]. Based on the requirements raised in the preceding section a sample of performance measurement systems have been reviewed (as summarised in Table 1) to determine the depth of support that is provided to those involved in such multiple consideration processes as design development. For a more comprehensive analysis, including a detailed list of references, see Haffey [11].
Table 1. Performance Measurement Systems Evaluation Matrix

Requirements & Evaluation Criteria

Balanced Scorecard BEM (EFQM) Cambridge Model Integrated P.M. Performance Pyramid

Intuitive Intuitive Intuitive Intuitive

-

Intuitive Intuitive Intuitive Intuitive Intuitive Intuitive Related High level

-

Intuitive Intuitive

Intuitive High level

The Balanced Scorecard is a framework that considers four organisational perspectives (Financial, Customer, Internal, and Innovation & Learning as shown in Figure 1) that are

564

ICED 01 - C586/653

purported to provide both a balanced representation of, and the perspectives upon which to analyse, an organisation. Within each perspective a list of objectives, and in turn metrics, are defined and clustered allowing an organisation to develop its own specific "Balanced Scorecard". The framework advocates a balance between financial and non-financial measures and it is purported that the analysis of the measures used will detail the strategy being deployed within an organisation. However, these measures and objectives are derived intuitively, and at user's discretion, and at such specific and complex levels of consideration concern as to the most appropriate mix or balance of measures being used to support strategic objectives must be expressed. Thus, it lacks the necessary means to determine the right things are considered with the rationale associated with the measures used, such as time based, or recognising when a measure becomes obsolete and is no longer required. Based on the requirements outlined previously in Section 2 the Balanced Scorecard provides no support in defining either organisation or process level goals and are therefore restrained in: maintaining the alignment and congruency of measures; identifying constraints to or contributors of success; and, providing the basis upon which to learn, identify and utilise competencies. The lack of support to identify applicable metrics in the context of organisational strategies provides no means of deriving process level sub indices from within its four perspectives. The Business Excellence Model (BEM), developed by the European Foundation for Quality Management (EFQM) provides practitioners with a framework that considers that the processes used to deliver people satisfaction, customer satisfaction and impact on society are attributable through leadership, controlling and defining organisational policies and strategies, managing people and allocating resources in order to produce excellence in its business results. Figure 2 shows the model, consisting of five enablers (what an organisation does i.e. Processes) and four results (what an organisation achieves i.e. Outputs or Goals), which is reported to provide the generic criteria that are deemed to assess an organisation's progress toward excellence. Again, the model provides a generic framework from which to intuitively derive the most appropriate goals and measures but lacks the depth to consider the alignment and congruency of goals and metrics and the potential to gain insights and learn from the constraints and contributors of success. The high level generic structure may provide overall indexes within results and enablers but relies on the intuitive extraction of measures to reflect operations at a process level and therefore provides no support in identifying what enablers are concerned with the achievement of results at lower more specific levels.

Figure 1. The Balanced Scorecard

Figure 2. Business Excellence Model

A process which supports organisations in developing a performance measurement system, the Cambridge Model as shown in Figure 3, comprises of two, five part, phases that provide the skeletal framework upon which high level measures and concerns are used to derive lower

ICED 01 - C586/653

565

level process measures. Phase one supports the identification, design and implementation of high level, strategy orientated, performance measures where organisational objectives and their associated or related measures are agreed upon, based on specific product strategies, and embedded into high level organisational decision making activities. Phase two aids in cascading high-level objectives and measures down to the process level based upon the key performance indicators and drivers. The model supports users in navigating through the process of developing and relating goals and measures but again relies on the intuitive extraction of goals and measures and the recognition of how they relate across and through an organisational structure. The model does acknowledge the need to support in identifying the interactions between measures, within isolated organisational levels, but relies upon a relational matrix to intuitively explicate their existence.

Figure 3. Performance Measurement System - Cambridge Model

A framework put forward by Nanni et al., Integrated Performance Measurement, emphasises the explication of relationships between an organisation's strategy, its actions and the utility of performance measures as shown in Figure 4. The framework refers to integrated as strategic-driven performance management through the congruency of actions across functional boundaries while in the context of strategic objectives. Their work argues the need for identifying process level goals and measures as derived from organisational strategies while they support the need to structure the goals and measures to align and be congruent within an organisational structure. However, the framework proposed falls short of supporting the identification of appropriate goals, measures and their inter-relationships. In addition, Nanni et al. recognise the need to identify the constraints and contributors to success and thus learn from the strengths and weaknesses of process capabilities yet the approach lacks the ability to explicate such information. The Performance Pyramid provides a means of deriving operational measures from organisational strategies. The approach outlines four levels within an organisation from the corporate vision, business units and business operating systems down to departments and identifies key, generic, dimensions within each level as outlined in Figure 5. The key objectives reflect key concerns at each level and are related and broken down to lower level, more specific, objectives with the recognition for the measures, related to objectives, to be aggregated back up through an organisation to support the recognition of effort being focused on working toward the satisfaction of objectives. While the approach identifies the key dimensions (high level and related low level), which should be addressed and measured at a process level, it provides little support on how to identify and integrate the relevant goals and measures. The approach does begin to address the need for the alignment of dimension goals/measures but lacks any depth in understanding their structure, interactions and cause and effect relationships and therefore restrains the potential opportunities to learn. In summary, system approaches and discussions on performance measurement have all concentrated on strategic objectives and the generic dimensions but lack the contribution in

566

ICED 01 - C586/653

supporting how such performance dimensions can be deployed to/from a process level while relegating the modelling of processes in terms of 'as is' to a secondary requirement.

Figure 4. Business Management Cycle

Figure 5. The Performance Pyramid

Even at such high level considerations the information required to manage the concentration or reduction in the degree of effort along the dimensions factored in strategic foci is not generated and in some cases equal weightings and considerations within relevant dimensions is prescribed. The utility of performance measurement approaches have been focused upon, at a general level, one of determining the dimensions of performance that will support the focus of effort in realising strategic objectives and in determining organisational health. However, none support, explicitly or based on factual feedback, the mapping of organisational goals which is needed to analyse and control processes in the context of organisational and process level objectives and thus lack the opportunities to stimulate learning, improve communication and affect behaviour. O'Donnell and Duffy provide a means to enable the alignment and congruency of objectives and measures in addition to providing the basis upon which to explore the relationships between the components of process performance [12, 13]. Through the ability to cascade process level performance measures throughout the corporation the existing reliance upon identifying the measures that support the satisfaction of performance goals through intuitive means may be overcome.

Conclusion

The ability of organisations to objectively set strategic goals, identifying the path along which such goals may be realised, requires a considerable degree of knowledge of the organisation, the environment within which it operates and the potential source from which major threats and opportunities are likely to arise. The complex nature of a design process requires consideration of the performance required from subsequent process activities in addition to its own and therefore requires prescriptive information on the levels of performance both required and attainable. This indeed contributes to the complexity of the design process and emphasises the need to provide prescriptive decision-making information. In order to provide such prescriptive information the need to support understanding and learning what has happened, by understanding goal and metric structures and their interactions, and predicting what is about to happen must be recognised. However, based on an evaluation of existing performance measurement approaches a substantial lack of support exists that brings organisational objectives down to a process level and that aids the identification of measures to support the focus of effort toward the satisfaction of such high-level objectives. Thus, the

ICED 01 - C586/653

567

opportunities to learn from past experiences and to map out and utilise the concept of causality is severely restricted. The authors are currently developing a methodology which will enable organisations to model and understand process performance behaviour. The research will focus upon overcoming the inherent weaknesses identified in existing approaches by providing a methodology to identify, structure and manipulate the key performance dimensions through machine learning techniques and performance modelling. References [1] Griffin, A. and Page, A. L., "PDMA Success Measurement Project: Recommended Measures for Product Development Success and Failure", Journal of Product Innovation Management, Volume 13(6), 1996, 478-496. Shay, J.P. and Rothaermel, F.T., "Dynamic Competitive Strategy: Towards a Multiperspective Conceptual Framework", Long Range Planning, Volume 32 (6), 1999. Prichard, R.D., "Measuring and Improving Organizational Productivity: a Practical Guide, Praeger Publishers, New York, 1990. Loch, C., Stein, L. and Terwiesch, C., "Measuring Development Performance in the Electronics Industry", Journal of Product Innovation Management, Volume 13, 1996. Kerssens-van Drongelen, I.C. and Cook, A., "Design principles for the development of measurement systems for research and development processes", R&D Management, Volume 27(4), 1997, 345-357. Englund, R.L. and Graham, R.J., "From Experience: Linking Projects to Strategy", J. Prod Innov Management, Volume 16, 1999, 52-64. King, B., "Hoshin Planning - The Developmental Approach" Goal/QPC, 1989. Hall, R.W., Johnson, H.T. and Turneym, P.B.B., "Measuring Up:Charting Pathways to Manufacturing Excellence", Business One Irwin, Illinois, USA, 1991. Kennerley, M. and Neely, A., "Performance Measurement Frameworks - A Review", Performance Measurement 2000, Second Intl Conf on Performance Measurement, University of Cambridge, 19-21 July 2000.

[2] [3] [4] [5]

[6] [7] [8] [9]

[10] Suwignjo, P., Bititci, U.S., Carrie, A.S. and Turner, T.J., " Performance Measurement System: Auditing and Prioritisation of Performance Measures", First Intl Conf on Performance Measurement, University of Cambridge, 14-17 July 1998. [11] Haffey, M.K.D., "Process Performance Measurement: Mapping the Requirements to the Support", Internal Report, CAD Centre, University of Strathclyde, February 2001. [12] O'Donnell, F.J. and Duffy, A.H.B., "Modelling product development performance", International Conference on Engineering Design, Germany, 24-26 August, 1999. [13] O'Donnell, F.J., "A Methodology for Performance Modelling and Analysis in Design Development", Doctoral Thesis, University of Strathclyde, March 2001. Mark K. D. Haffey: CAD Centre, DMEM, University of Strathclyde, 75 Montrose Street, Glasgow, Scotland, United Kingdom, Gl 1XJ. Tel: +44 (0) 141 548 2374, Fax: +44 (0) 141 552 0557, E-mail: mark@cad.strath.ac.uk, URL: http://www.cad.strath.ac.uk. M K D Haffey 2001

568

ICED 01 - C586/653

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

THE METHODOLOGY FOR SYSTEM INTEGRITY IN DESIGN

J K Raine, D Pons, and K Whybrew Keywords: Design process, knowledge-based systems, probabilistic design, system integrity

1 Introduction
This paper introduces a methodology for designing for system integrity [1] in multicomponent systems and minimising risk from early in the conceptual phase, where uncertainty is high. The process involves probabilistic reasoning in propagating both qualitative and quantitative effects of changes, or uncertainty in component or sub-system specifications, through system models, and determining the integrity of the design from multiple viewpoints. The methodology is very versatile and the software that has been developed not only handles Design for System Integrity (DSI), but has also been demonstrated for a number of other tasks, such as evaluating system reliability, investment appraisal for engineering and other projects, and risk assessment in project management. The software has particular value in assisting the design manager to evaluate the robustness of design alternatives at the conceptual stage when there is a high level of uncertainty. The use of the software as an aid to design management is described in detail by Pons [1].

2 The Design Process and Knowledge-Based Systems in Design

A systems approach to design involves the identification of a functional model for the engineering system and the creation of a number of sub-systems and components, between which there are defined interfaces and transfers of material, energy and information. As the design is refined, sub-system concepts, embodiments and details are altered to a more final state. At each level, the designer needs to understand how the relationships between subsystems or components affect the overall integration of the design, and ultimately the cost, performance, robustness, reliability and other important characteristics of the system. Research at the University of Canterbury into the management of design and new product development in New Zealand [2] indicates that few engineering designers in industry follow systematic design processes such as proposed, for example, by Pugh [3] and Pahl & Beitz [4]. This research [5] has also shown that communication is often lacking between product development team members working on different sub-systems. This results in recurring cycles of task clarification, conceptual, embodiment and detail design, often late in a project. Raine et al [6] have proposed diagrams to better represent concurrent activity between customer-focused design, manufacturing and marketing functions in the design process, and to illustrate the recursive process of exploring sub-system and component interrelationships. These relationships, which will be numerous in a multi-component system, are examined from various viewpoints, such as in Pugh's Elements of Design Specification [3]. The

1CED 01 - C586/024

569

objective of the research described in this paper was to develop a methodology and software to operate as an aid to design managers in determining the integrity of a design from multiple viewpoints, for example whole life cycle cost, performance, noise level, appearance, manufacturability, maintainability, or reliability. It was desired to be able to evaluate rapidly, using analytical or qualitative design rules, the effect of specification uncertainty or changes (design alternatives) in one component or sub-system on other components and on the whole system, from the different viewpoints, and, importantly, at the early conceptual design stage when there is a high level of uncertainty. Antonsson et al [for example, reference 7] have presented notable work on methods for incorporating imprecision in engineering design decision-making. Antonsson's Method of Imprecision allows for uncertainty at early design stages using fuzzy calculus but does not appear to propagate qualitative effects through the design model. Pons [1] has compared the features of Antonsson's method with the DSI methodology described below. The research of Pons [1] highlighted a need for design models or methodologies that can explore how the design behaves [8] handle non-numeric parameters and evaluation of tolerances evaluate a configuration without being forced to assign values to the attributes use a symbolic representation in preliminary design when embodiment and geometry may be uncertain [8] measure and quantify lifetime performance of designs. Knowledge-based software packages to assist the designer in exploring conceptual alternatives or in the analysis and optimisation of a given design are now common, for example in software models of complete motor vehicles. However, such methods have generally only been successful in specific domains, as they require relatively complete problem definition [9], which is often unavailable in early design where uncertainty is high. In this problem domain, artificial intelligence methods have generally only been successful in well-defined applications that have fixed design strategies [10]. Bartsch-Sporl and Bakhtari [11] set out the requirements of artificial intelligence implementations as: Completeness of knowledge in the domain model Consistent logic within the domain Closed domain, not vulnerable to outside effects Problems that can be decomposed and recomposed Solution spaces that can be formally defined. They point out that real life design domains seldom meet these requirements precisely, and their strategy has been to use artificial intelligence to assist the human designer rather than to solve design problems on its own. An example of a more successful implementation has been the "Schemebuilder" model of Bracewell et al [12], which helps the designer assess a design scheme from a functional viewpoint, principally by functional simulation. Rather than automating design using the expert system approach, this system provides decision support and allows the human designer to apply judgement and quickly evaluate alternative design solutions.

570

ICED 01 - C586/024

Design for System Integrity Methodology

The DSI methodology and software belongs to the family of knowledge-based systems that help the designer assess a design scheme from a functional viewpoint. The DSI methodology propagates (at concept, embodiment or detail design stage) both quantitative and qualitative knowledge about design parameters through a tree structure not dissimilar to a fault tree or decision tree. The process is outlined in the flow diagram of Figure 1.

Figure 1. Flow chart illustrating core process of the Design for System Integrity (DSI) method

Space does not permit a comprehensive explanation and illustration of the methodology, which has been fully described by Pons [1], and which will be published elsewhere in more detail. However a brief example is presented below.

1CED 01 - C586/024

571

The research used as a key example the design of automatic dishwashers. The designer identifies key devices in the model. In the case of the dishwasher the DSI process system is defined typically with physical devices, eg "wash pump", "sprayer", etc. Each of these is attributed properties that relate to one or more of the viewpoints from which system integrity is to be evaluated, such as "wash pump cost", "wash pump pressure". The designer then establishes the relationships between the devices. These relationships are different for each of the viewpoints under scrutiny, and can be either quantitative (numerical, e.g. fluid power = pressure x volume flow rate), or qualitative (textual). Wash performance of the dishwasher is modelled as 100% less the soil demerit points. The overall effectiveness of soil removal is represented by a substantial and complex DSI tree structure that has been fully described by Pons [1]. Space here only allows for brief examples of quantitative and qualitative DSI processes. Quantitative links give rise to numerical relationships, and are defined in terms of basic mathematical operators (addition, subtraction, multiplication, and division), or more complex mathematical functions (eg reliability functions such as the Weibull distribution) or even by logical functions (maximum, minimum). The elemental process in the DSI methodology involves taking two discretised input probability distributions, applying a quantitative operator (such as +, -, x, /, maximum, minimum) or qualitative map (using decision theory) to determine an output distribution. In the wash performance model one of the elemental quantitative combinations in the subsystem computation for soil particle demerits evaluates the water retained in the machine at the end of the wash cycle as the sum of the water retained in the sump and the water retained as a film on the wash cavity. The fragment of the DSI tree containing this operation is shown in Figure 2. The inputs in this case are represented respectively by normal and Weibull probability distributions. The addition of the two discretised probability distributions, represented as histograms, is illustrated in Figure 3. The process can be computationally demanding. In this example, if the two probability distributions were each approximated by 100 discrete values, there will be 10,000 calculations to form the combined distribution, and there may be many such combinations in the overall DSI analysis tree just for the wash

Figure 2. Fragment of DSI computation for soil particle demerits within wash performance DSI tree Figure 3. Sum of sump (normal) and cavity (Weibull) retained water probability distributions to give an output as the bold line. The horizontal axis is volume in litres and the vertical scale probability density.

performance. In the retained water computation each of the 10,000 additions has an associated joint probability being the product of the probabilities of the component water volumes. The overall joint probability for a specific value of retained water volume is the sum

572

ICED 01 - C586/024

of the various joint probabilities associated with the occurrences of that specific retained water volume as an outcome. Qualitative parameters are defined in textual terms. These could be pseudo-scalar values such as a temperature scale ("hot, warm, cool, cold"), or more abstract terms such as the type of soil present on dishware (e.g."sauce, mashed potato, breakfast cereal") and soil thermal treatment ("fresh, dried, reheated, baked, burned"), where no scale of precedence exists. A mapping process similar to that used in decision tables describes textual relationships and enables qualitative information to be propagated through the DSI tree. The expert defines this map at initial configuration of the system. For example, if wash performance (''bad, marginal, acceptable, good, excellent") of the dishwasher is dependent on soil thermal treatment and soil type, in a way which cannot be quantified, then the expert sets up a decision table which gives the resulting wash performance for every combination of the inputs soil thermal treatment and soil type. However, the expert does not give a single point deterministic estimate of the result, but gives the probability of each of the outputs. A fragment of a wash performance map relationship is shown in Figure 4, in which the map takes soil thermal treatment and soil type, and combines them to produce the output. A soil thermal treatment model is shown in Figure 5. It ranges from fresh to burned soil and, in the example shown, all the soil is taken as dried, which therefore has a probability of 1. A soil type profile is shown in Figure 6, where the proportions have been determined from the relative masses of the soils.

Figure 4. Representation of a map Relationship in the Design Integrity Software

Figure 5. The profile for soil thermal treatment.

Figure 6: Soil type shown as a histogram based on mass of various soils used in standard dishwasher performance tests.

1CED 01 - C586/024

573

In the example illustrated here, soil state is computed by applying a subjective map to soil type and soil thermal treatment. A fragment of this map is shown in Figure 7. For example, in Figure 7, in the case of fresh egg, the likelihood would be 50% as soluble film and 50% as sticky paste. The output of the map process is soil state as shown in Figure 8.

Figure 7.

Map to convert soil type and soil thermal treatment into soil state. Numbers are probabilities where any one column will sum to unity.

Figure 8.

Soil state is a combination of soil type and soil thermal Treatment. It describes the important wash characteristics of the soil.

Once the system has been defined by appropriate quantitative and qualitative relationships, the end user (who may be different from the expert designer) determines the input attributes. For example, the user might assert that water temperature is warm. This can then be propagated through the system to determine the resulting wash performance and other outputs. A more realistic assertion at early design stages might be to give a probability distribution e.g. 30% hot, 50% warm, 20% cool, 0% cold, to encompass the uncertainty that exists at this stage. That is, the designer is leaning towards using a hot-warm set point on the thermostat, but wants to include the smaller possibility of a cool running option. After distributions are specified for all the inputs, the system outputs are computed as probability distributions for each parameter. If necessary, alarms (acceptance limits) can be

574

ICED 01 -C586/024

defined by the user for any parameter, and these can be checked during computation. The end result is a set of distributions for each of the viewpoints defined. For each viewpoint from which the designer wishes to evaluate the integrity of the system, knowledge about all of the contributing parameters feeds in at the outer most branches of the tree and the DSI software then computes an outcome probability distribution for the viewpoint concerned, e.g. overall wash performance, product cost or product reliability. Effects from various viewpoints may also be studied concurrently. For example, in evaluating wash performance of the dishwasher, selection of a different circulation pump to reduce cost may alter water pressure and trigger responses from component properties relating to seal performance, system energy consumption, and water flow rates. The DSI software engine applies probabilistic computation in a combinatorial fashion and allows both numerical and textual relationships in the same model. This is a departure from established techniques, where the effect of variability in multiple parameters affecting an overall outcome, and the associated numerical relationships, have commonly been handled using Monte Carlo methods [13]. The DSI numerical method avoids Monte Carlo simulation altogether, although it has similar functionality and computational power. It also provides the functionality of decision theory. The ability of the DSI methodology to propagate the effects of a change in a design parameter means mat the "risk" in the result (e.g. total product cost) may be identified, quantifying how good or bad the outcome may be. Unlike expert system tools where the software seeks to make a decision using artificial intelligence method, the DSI method does not make decisions itself. The method is an analytical assessment tool that supports the human decision-making and design management process. The DSI software was developed in the Delphi programming language and contains approximately 40,000 lines of code. It is a comprehensive package that can handle both quantitative and qualitative system integrity computation from multiple viewpoints.

Conclusions

Designers can have difficulty grasping the multiple relationships between systems, subsystems and components. The Design for System Integrity (DSI) methodology has been developed as a software tool to assist in faster evaluation of system integrity from multiple viewpoints. It therefore offers a rapid means of comparing design alternatives. The methodology fuses quantitative and qualitative assessment, and incorporates probabilistic reasoning. The ability to propagate both qualitative and quantitative information, and process variability, through the system model means that: 1. The DSI methodology can be applied to a number of different domains, and in particular, may be used in the early conceptual design stages when data are typically sparse. 2. System integrity may be assessed in a way that is impossible using conventional deterministic methods. References [1] Pons, D., "A methodology for system integrity in design", PhD thesis, University of Canterbury, Christchurch, NZ, March 2001.

1CED 01 - C586/024

575

[2]

Shaw A., Aitchison, D.R., Raine, J.K., Whybrew, K., "Summary of results of the survey 'Rapid Product Development for World Class Manufacturing'", Technical Report No. 58, Department of Mechanical Engineering, University of Canterbury, May 2000, 23pp. Pugh, S., "Total Design. Integrated Methods for Successful Product Engineering". Addison Wesley, 1991. Pahl, G. and Beitz W., "Engineering Design". London: The Design Council, and Berlin/Heidelberg, Springer-Verlag, 1984. Whybrew K., Raine J.K. and Dallas T.P., "The Application of Design Phase Diagrams in the Management of Design of Telecommunications Products", Proc. 12th International Conference on Engineering Design. Munich 24-26 August 1999, 3, pp1519-1524. Raine, J.K., Pons, D., and Whybrew, K., "The design process and a methodology for system integrity", Short Communications in Manufacture and Design. Proc. IMechE PartB. 2001 (to appear) Antonsson, E.K. & Otto, K.N., "Imprecision in Engineering Design", Journal of Mechanical Design. Transactions of the ASME. 117B, 1995, pp25-32. Finger, S. and Dixon, J., "A review of research in mechanical engineering design". Part 2: Representations, analysis and design for the life cycle, Research in Engineering Design. 1.1989. pp121-137. Candy, L., Edmonds, E. and Patrick, D., "Interactive knowledge support to conceptual design", in Sharpe J. (ed), "Artificial intelligence system support for concept design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp260-278.

[3] [4] [5]

[6]

[7] [8]

[9]

[10] Tang M., "Development of an integrated AI system for conceptual design support", in Sharpe. J (ed), "Artificial intelligence system support for conceptual design", Proc. 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp153-169. [11] Bartsch-Sporl, B. and Bakhtari, S., "A support system for building design - experiences and convictions from the FABEL project", in Sharpe J (ed), "Artificial intelligence system support for conceptual design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp279-297. [12] Bracewell, R.H, Chaplin R.V., Langdon P.M., Li M., Oh V.K., Sharpe J.E.E., and Yan X.T., "Integrated platform for AI support of complex design (Part 2): Supporting the embodiment process", in Sharpe J. (ed), "Artificial intelligence system support for conceptual design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, ppl 89-207. [13] Kleijnen, J.P.C., "Verification and validation of simulation models", European Journal of Operational Research. Elsevier Science B.V. 82(1), 1995, pp145-162. Professor John K. Raine Department of Mechanical Engineering University of Canterbury Private Bag 4800 Christchurch New Zealand Telephone: +64 3-364-2571 Fax: +64 3-364-2078 E-mail: J.Raine@mech.canterbury.ac.nz IMechE 2001

576

ICED 01 -C586/024

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

CHANGE PREDICTION FOR PRODUCT REDESIGN

P J Clarkson, C Simons, and C M Eckert

Keywords: change processes, design management, risk analysis and management

Introduction

Product redesign is common in many industry sectors, for example in automotive and aerospace, where 'new' products are derived from earlier designs as a means to maintaining product quality whilst reducing design and production lead time. However, the redesign of such complex products is seldom straightforward and can be effected by the propagation of changes - a small initial change can instigate numerous other changes, possibly having serious cost implications. Despite this risk, industry currently lacks a clear approach for predicting and representing change propagation [1] and is dependent on the past experience of product experts to minimise its effect. The aim of this research is to reduce unexpected change propagation in product design. The objectives of the work reported in this paper were to explore the scale of change propagation in aerospace design and to develop an approach for predicting the effects of change propagation in redesign. A computer tool has been developed to support this approach accompanied by an efficient format for representing such information.

Background

GKN Westland Helicopters are world leaders in rotorcraft design. They produce the EH101, in a number of design variants to suit the differing requirements of the search and rescue, civil and military markets. Within these markets customers have different requirements for equipment, radar, weapons and load-space. It is therefore particularly important that the impact of these differing requirements are fully understood before the contract for a new craft is signed. Hence, the model presented in this paper is intended for use during tendering and for assembling design teams in early conceptual design for customisation. The research began with an extensive series of interviews with chief designers and a manager responsible for producing tendering estimates for new projects within GKN to explore the nature of change in helicopter redesign. Several key points emerged from these interviews: designers frequently fail to realise how their design decisions will affect others; knock-on changes (change flows) occur, resulting in changes typically no more than 4 steps (components / systems) removed from the initial change; estimates of unexpected changes ranged from 5% to 50% of those actually encountered.

ICED 01 -C586/070

577

In addition, design changes resulting from a number of specific redesign requirements were identified, for example the introduction of two additional countermeasure dispenser pods.

A model for change prediction

Earlier research suggested that a product model, based on Design Structure Matrices [2], combined with a propagation model could produce predictions of change in complex products [3]. However, whilst such a model provided good predictive results it needed to be further developed and incorporated into an executable method usable by industry. It is this development, along with some of the insights gained from the interviews, which are presented in this paper.

3.1 The change propagation model

The Change Propagation Model is derived from a Product Model, itself the result of the decomposition of the product into a set of systems and sub-systems, and their related dependencies (Figure 1). These dependencies, obtained from an analysis of the product architecture, are defined in terms of the likelihood that the redesign of a component will force the redesign of another and the impact, or extent, of that redesign. A matrix entry represents the dependence of the component identified by the row on that identified by the column.

Figure 1. The Change Propagation Model

The Product Model is constructed in two stages. First, a number of product components are identified, which together represent the whole of the product. These define the row and column headings in the product model matrixes. Second, the direct likelihood and impact relationships between the components are determined. To date this latter activity has been undertaken by interviewing people with experience of designing the product in question and through workshops that are used to elicit a consensus view.

578

ICED 01 -C586/070

The characterisation of component relationships by their likelihood and impact allows changes to be considered in terms of risk, i.e. the product of likelihood and impact [4], throughout the analysis. Once the component dependencies have been captured, the possible paths of change propagation can be determined. The change propagation algorithms, based on probability and Venn diagram arguments, can then be used to identify the overall likelihood and impact of a change propagating to other components. The risk, or likely impact, can be expressed in a number of ways, but perhaps the most useful is as the likely cost of the changes predicted. This cost can then be measured directly, in monetary terms, or indirectly, as an expression of the time required for redesign. Further details of the algorithms used are to be found in another paper [3]. There are many issues regarding the appropriate choice and number of components, the definition and quantification of likelihood and impact, and the specification of the initiating change. These are the subject of ongoing research. However, a number of these issues, in particular the sensitivity of the change predictions to variations in the input data, will be discussed later in the paper.

3.2 A change prediction method

The Change Propagation Model has been incorporated into a change prediction method, as illustrated in Figure 2. This comprises three stages: an initial analysis; a case by case analysis; and the actual redesign. The initial analysis stage involves the definition of the product model and computation of the change propagation model. This provides a summary of the change propagation characteristics for the whole product. The results of this analysis can be presented in a 'graphical' product risk matrix (Figure 2 and in more detail in Figure 3), where the size and shape of each element indicates the likelihood (width) and impact (height) of change between any two systems. This allows easy assessment of the potential for change propagation. Indeed systems which are susceptible to change, or initiate change are easily identified.

Figure 2. The Change Prediction Method

ICED 01 -C586/070

579

In order to assess the potential change resulting from a particular change request, an analysis of the specific case is required. The change request is first associated with the systems that it immediately effects. The product change propagation model can then be used to reveal other systems that may be affected. A case risk plot (Figure 2) represents the predicted likelihood and impact of these effects (a subset of the data shown in the product risk matrix). Points in the upper right corner of the plot are the most important, as they represent both the most probable and most expensive changes. When presented with a particular new product requirement, the case risk plot allows managers and designers to see and compare the risk of change to different components. This information enables better estimation during tendering and acts as a checklist during design. Finally, the last stage represents the actual redesign of the product, hopefully achieved in a more informed manner at a lower cost. The following case-study will serve to illustrate the construction of the Change Propagation Model and its use in the Change Prediction Method.

An example of change prediction

The change propagation model and prediction method have been tested using case studies from GKN Westland Helicopters, based on known changes made to variants of the EH 101 helicopter. In all three cases studied, the method predicted all the changes observed, including those not present in the original product model. In fact, in most cases, the changes observed were those representing the highest change risk and highest likelihood of occurrence.

4.1 TheEHlOl change propagation model

A change propagation model was derived for the EH101 after individual discussions with four chief engineers and a team meeting. There was much debate regarding the 'appropriate' number of components to be identified, with estimates ranging from 19 to several hundred. There is a trade off between using a large number of components, making it easier to identify and cost particular dependencies, and a smaller number, requiring an averaged view of dependency with the advantage of reducing the scale of the model. Small matrixes for complex products are inherently ambiguous, because the components can be linked through many dependencies (see [5] for a discussion of the connectivity). Two solutions were pursued. The first addressed over 200 components, resulting in a sparsely populated matrix documenting specific historical changes, aimed at helping designer during redesign. The second, reported here, addressed 19 components (still over 350 dependencies), where each dependency represented the consensus view of the team present and related to the likely changes that could be expected to propagate. Likelihoods ranged from 0 (no change propagation) through 0.05 (very unlikely propagation) to 1 (certain propagation) and impacts ranged from 0.001 (minor change) to 1 (major change). In this particular case actual costs were not used to preserve confidentiality and the impacts are a measure of the degree of change predicted. The product risk matrix for the 19 components derived using a three-step propagation analysis is shown in Figure 3. The rows and columns of the matrix have been reordered to highlight those components most likely to initiate change (right-most columns) and those most susceptible to change (upper-most rows).

580

ICED 01 - C586/070

Therefore changes that would demand a change to the main rotor are not tolerated and must be reconsidered.

4.2 Change prediction for the EH101

A particular customer requirement involved the introduction of two additional countermeasure dispenser pods, a part of the weapons and defensive systems. This initial change resulted in local structural reinforcements (bare fuselage), addition of a deflector plate to protect the inflight refueling system (fuel and fuselage additional items), repositioning of the UHF antenna (fuselage additional items), nose cap adjustments (bare fuselage), forward looking infra-red radar system modifications (fuselage additional items), Cabling and Piping revisions, Avionics changes and flotation system adjustments (equipment and furnishings).

ICED 01 -C586/070

581

The case risk plot for an initiating change to the weapons and defensive systems is shown in Figure 4. This comprises all the data point from the weapons and defensive systems column of the product risk matrix. Note that the risk plot shows data normalised onto 0 to 1 log scales.

Figure 4. An EH101 case risk plot

A comparison with the changes known to have taken place revealed 6 out of a possible 18 changes were observed, where these represented 2/3 of all the predicted changes found in the upper third of the likelihood scale. In addition, half of the observed changes were not predicted by direct dependencies and only came to light following the application of the change prediction method. This latter point illustrates the power of the method in highlighting all areas of potential design change in response to new product requirements. Two further case studies showed similar results with many of the higher likelihood changes predicted being the same as those observed.

Discussion of the results

The preliminary results presented above suggest that the change prediction method has promise in identifying and rank ordering potential changes as a response to modified design requirements. However, further research is necessary to validate these claims. In particular: the prediction algorithm needs to be verified for its suitability for use with larger matrices; related to this, the most effective granularity of the model needs to be established; the sensitivity of the predictions to variations in input data needs to be investigated; and finally, the usefulness of the method needs to be tested with further case studies.

582

ICED 01 -C586/070

The first of these points is the subject of current research. In principle, there is no reason why the current algorithm, based on an investigation of all possible propagation routes [3], cannot be expanded to larger problems. In practice, however, the computational cost associated with such problems is likely to be unacceptable. As a result the use of Monte Carlo simulation, which uses a sample of the propagations to estimate potential change, is being investigated. The sensitivity of the change prediction method to variations in the input data is an important consideration. If the sensitivity is too low, the method will be unable to provide distinct solutions for varying versions of a product. If the model is too sensitive, slight inaccuracies in the initial data may result in misleading results. A preliminary investigation into the sensitivity of the method has been conducted. The effect of varying each likelihood and impact value by 20% of full-scale (i.e. 0.2) was calculated for the example case presented in the previous section. Variations causing maximum changes in the predictions were then noted. The order of the predicted changes, from highest to lowest risk, are compared in Figure 5 for the original and maximally changed data.

Figure 5. An investigation of change prediction sensitivity

Although the order of a number of components changes, the top five components do not move. In addition, the components that do just shuffle do so within small groups. Thus, although the data may be quite sensitive to changes, the rank ordering by risk of the predicted changes is largely insensitive to changes in the input data, at least for the case studied. Further case studies are also underway. These will look at the design of hydraulic valves, automotive powertrain systems, special purpose vehicles and lifting gear.

ICED 01 -C586/070

583

Conclusions

A method for predicting change propagation in product design has been developed along with an efficient format for representing the results. Initial case study evaluations have been promising, with good correlation between predicted and observed changes. The change prediction method suggests the possibility of a number of benefits to industry, including: better cost predictions in the tendering process; assistance in (human) resource management; support for less experienced designers; identification of potential for increasing product modularity. In summary, the change prediction method offers a potential tool for identifying and managing change in product redesign. Further work is in progress to develop and validate the method with other case studies from different industry sectors. Acknowledgements The authors are grateful to the UK Engineering and Physical Sciences Research Council (EPSRC) and GKN Westland Helicopters Ltd for their support of this project. References [1] [2] [3] Lindemann, U and Reichwald, R (1998), Integriertes Anderungsmanagement. SpringerVerlag, Berlin. Steward, D V (1981), "The Design Structure System: A method for managing the design of complex systems," IEEE Transactions on Engineering Management, 28(3), pp71-74. Clarkson, P J, Simons, C S and Eckert, C M (2001), "Predicting Change Propagation in Complex Design," Proceedings of DETC: 13th International Conference on Design Theory and Methodology. Pittsburgh, Pennsylvania, 9-12 September. Coppendale, J (1995), "Manage risk in product and process development and avoid unpleasant surprises," Engineering Management Journal. February 1995, pp35-38. Eckert, C M, Zanker, W and Clarkson, P J (2001), "A better understanding of change in the development process", Proceedings of ICED 2001.

[4] [5]

Dr P John Clarkson Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0)1223 332 742 Fax: +44 (0)1223 332 662 E-mail: pjclO@eng.cam.ac.uk Cambridge Engineering Design Centre 2001

584

ICED 01 -C586/070

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

SURVEY OF CURRENT UK PRACTICE IN MANAGING TECHNICAL DESIGN RISK

R Crossland, C A McMahon, and J H Sims Williams Keywords: risk analysis and management, survey

1 Introduction
Risk management is essential to the success of any engineering design project because design is, by its very nature, an activity that involves risk. The only way to eliminate the risk that a designed artefact will fail to meet its requirements would be to forgo the design process, and instead reuse an existing artefact of precisely known performance characteristics. With increasing product and project complexity the use of formal risk management processes during design, supported by suitable tools and techniques, has become more prevalent [1]. The importance of managing risk has led to the recent development of a number of risk management approaches [2][3], and to risk management becoming a contractual requirement for many projects in the public and private domains, in particular in military procurement [4]. Interest in risk is international: the US Project Management Institute has established a Risk Management Special Interest Group [5], as has the UK Risk Specific Interest Group of the Association for Project Management [6]. However, the importance of risk management varies significantly with industry, and the emphasis in risk management has been more strongly on project risk - the likelihood of a project failing to deliver on time and budget - rather than technical risk - the likelihood of a designed artefact performing as designed and to cost. As the emphasis on risk management has grown, a number of studies have been carried out to identify the extent to which risk management has penetrated industrial practice, and the nature of the techniques that have been most widely applied. Examples of these studies are Baker et al's survey [7] examining the dependency between industry sector and risk management practices (construction and oil & gas sectors are compared) and Raz and Michael's study [8] of the use of project risk management tools in software and high-tech industrial sectors in Israel. Raz and Michael found that simple easy-to-apply tools were the most successful, along with simulation, whereas Baker et al suggest that personal/corporate experience and engineering judgement are the most successful techniques, with expected monetary / net present value, sensitivity analysis and decision analysis as the principal quantitative techniques, and prevention (e.g. staff training) as the favoured risk reduction method. This present paper also reports some of the results of a study of current industrial practice [9] in managing risk aimed at exploring where future efforts to improve technical risk management practice should most productively be concentrated. In the case of the present work we have however emphasised in particular the different approaches taken by companies in the design process to project risk and technical risk. The study was carried out by a combination of questionnaire and case study.

ICED 01 -C586/435

585

2 Methodology
2.1 Questionnaire Development
The questionnaire was initially developed by considering the tools and techniques that might be used at each stage in the risk management process, and by giving the respondents an opportunity to specify those used in their projects. Questions were then added which aimed to determine the nature of the risks faced, the barriers to effective risk management and the degree of integration between project and technical risk management. The questionnaire was divided into three sections; the first contained questions to determine the nature of the participating companies and the size and general nature of their design projects. The second and third sections contained questions about tools and techniques for project risk management and technical risk management respectively. The results reported here concern the first and last sections. Most of the questions were "multiple choice" and could be answered by ticking one or more boxes - sometimes with an optional opportunity to explicitly name another choice which had not been included. The structure of the questionnaire is shown in Figure 1 below, along with an indication of how the presentation of a selected subset of the results is organised within this paper:
Figure 1. Organisation of presentation of results

2.2 Sample Construction

In total 124 questionnaires were distributed of which 63 were returned. Respondents for the questionnaire were obtained by: letters to industrial contacts of the research team and secondary contacts from wider University work (23 responses); telephone calls to companies obtained from an engineering directory (18 responses); letters to the editors of professional

586

ICED 01 -C586/435

engineering and project publications (14 responses) and a presentation made to the Risk SIG of the APM (8 responses). It is clear that such a mechanism for obtaining the sample cannot lead to statistically valid conclusions about the population as a whole: the respondents must all be assumed to have had a strong interest in risk management (in order to spend the time required to complete the questionnaire) and many of them were personal contacts of the research team. It should be noted therefore that the respondents probably already had an above average level interest in risk management, and hence may have been employed by companies with a more sophisticated risk management approach than is typical. The sample was therefore certainly biased, the results can only be regarded as indicative, not statistically valid, and any conclusions drawn are necessarily subjective. The authors believe that this is a factor in much design research: unbiased survey samples are difficult to obtain since the population of most interest is that of commercially practising engineering companies and the design engineers who work within them, who often do not have time available to participate in research. As such engineering design research surveys (e.g. [8]) can only point towards necessarily subjective conclusions, rather than providing statistically valid proof of hypotheses, but nevertheless useful insights may be obtained.

3 Results
Of the 63 questionnaires returned, three were omitted because they were not from UK design companies and a further three respondents (two construction companies and one software company) were omitted because they did not complete the section relating to technical risk.

3.1 Scope of Design Projects

The industry sectors of the participant companies are shown in Table 1 below.
Table 1. Questionnaire respondents identified by industry sector

Industry sector Construction Aerospace Oil/petrochemical Technology/engineering consultant Manufacturing Utility supply/generation Coastal/environmental engineering Software Risk/management consultants Process Automotive TOTAL

Number of respondents 18 11 8 5 4 4 3 3 3 2 2 63

A wide range of engineering disciplines was involved in the projects; respondents were asked to select the three main disciplines involved, and the most popular responses were mechanical (67%), civil (47%), electrical (43%), software (28%), electronic (23%) and aerospace engineering (13%). The sizes of the projects varied very widely; the average number of technical personnel for a project was 47, but responses varied from two to 500. Similarly, the average number of personnel was 29, but responses varied from 1 to 500.

ICED 01 -C586/435

587

All phases of the design process were represented in the responses: requirements (87% of respondents), cost/time budget setting (92%), conceptual design (92%), embodiment design (75%), and detail design (87%). All phases of the product lifecycle were also represented: pre-bid (65% of respondents), new product introduction (58%), manufacturing (53%), product maintenance (37%) and product disposal (18%). Respondents were asked to specify whether the main kind of design work involved in their projects was original, adaptive or variant design [9]. Fifty three percent of respondents specified that their main work was original design, 28% chose adaptive design and 18% specified variant design. However, previous research [8] in which this question was addressed to designers suggests that it is likely that many people would classify what is in fact adaptive design under the "original" category.

3.2 Problematic Risks

To address the frequency with which risk arises in particular areas respondents were asked "How often does technical risk arise in each of the following areas?". The areas were defined as follows: Materials: uncertainty concerning the behaviour or properties of materials; Manufacturing processes', uncertainty introduced during the manufacturing process; Usage/loads/environment: uncertainty concerning how the designed product will be used, or concerning its environment or the loads which will be placed upon it; Bought-in sub-systems: uncertainty concerning the behaviour or properties of a component or sub-system purchased from a third-party; Sub-system interactions: uncertainty concerning how components or subsystems will interact with each other; Design error within sub-system: uncertainty concerning properties or behaviour of an in-house designed component or sub-system; Aggregate budget overruns: uncertainty which cannot be assigned to a single cause, but is due to an aggregation of many uncertain design variables which must not exceed a budgeted limit. An example would be the total weight budget for an automotive design, or total power-consumption for an electrical design. The results are shown in Table 2.
Table 2. Percentage of respondents who stated that technical risk arose with a given frequency for each area

Often Almost always Materials 13% 40% Manufacturing processes 12% 33% Usage/loads/environment 28% 36% 14% 32% Bought-in sub-systems 23% Sub-system interactions Design error within sub-system 12% 26% Aggregate budget overruns 18% 36%

Occasionally 36%

35%

43%'. . 32% 40%

31%

52%
32%

Almost never 11% 12% 4% 14% 10% 10% 14%

Note that in the presentation of results in the tables the percentages of respondents shown for a given risk area are calculated as a percentage of those respondents who stated that the area applied to them - i.e. the percentage of those who ticked one of the four boxes "almost always", "often", "occasionally" or "almost never" for that area. In addressing the difficulty of dealing with risk in particular areas respondents were asked "How difficult is uncertainty (and hence risk) to deal with in each of the following areas?" The responses given are shown in Table 3.

588

ICED01-C586/435

Table 3. Percentage of respondents who stated that technical risk had a given level of difficulty in each area

Materials Manufacturing processes Usage/loads/environment Bought-in sub-systems Sub-system interactions Design error within sub-system Aggregate budget overruns

Extremely difficult Difficult Quite difficult Not difficult 29% 24% 8% 39% 29% 18% 4% 49% 15% 26% 17% 43% 23% 31% 4% 42% 16% 31% 18% 35% 4% 30% 49% 17% 11% 21% 34% 34%

3.3 Which Tools and Techniques are Currently Used? Company Procedures:
Respondents were asked "Does your company have any formal operating procedures for your design projects or design guidelines which explicitly include risk or reliability assessments for the product/process?" and were asked to tick all applicable boxes. Of those that replied, 80% stated that design analysis procedures were specified, 46% stated that product/process reliability test procedures were specified and 54% stated that Factors of Safety were specified. For 39% of respondents formal risk/reliability assessment was mandatory because of legal requirements, and for 52% it was demanded by their clients. Identification of Technical Risks Respondents were asked to specify which techniques, in addition to those used for project risk identification, were used to identify risks that may affect technical risk factors. Brainstorming (79% of respondents), checklists (72%) and interviews (46%) were the most widely used techniques for identifying technical risks (along with personal experience (91%) and common sense (86%)). Risk response analysis (where the secondary risks which may arise from the planned or anticipated responses to those originally identified are analysed) was used by 25% of respondents and questionnaires were used by 23%. Of those who used checklists, 78% used lists developed within the company, 44% used lists developed personally and 15% used those developed within the industry. The most widely used tools to support these identification techniques were computer-based checklists (used by 44% of respondents). Fourteen percent of respondents stated that they used published material - examples given by respondents included Ministry of Defence material, the PRINCE checklist [12], case histories, technical journals, guides, manuals and research papers. Nine percent stated that they used a knowledge-based system to support risk identification. Other tools named by respondents included Failure Mode and Effect Analysis, Hazard and Operability studies, trained facilitators, spreadsheets and paper-based methods. Risk Impact and Probability Evaluation The most widely used models for the modelling of uncertainty when estimating the values of technical risk factors were qualitative representations (e.g. "major'V'minor"), which were used by 70% of respondents. This was followed by safety factors (54%), Failure Mode and Effect Analysis (48%), interval representations (38%) and then probability distributions (34%). Event trees were used by 14% of respondents, as were fault trees. Level 1, 2 or 3

ICED 01 -C586/435

589

reliability techniques were only used by 11% of respondents, and only nine percent of respondents used decision trees. Respondents were asked to specify which software tools they used to model uncertainty in technical risk factors and whether the tools were commercially available or were developed in-house. The most widely used tool was Monte Carlo simulation software, which was used by 37% of respondents, followed by reliability software (23%) and more specific simulation software (5%). Other software tools named by respondents included spreadsheets, HAZOP software, virtual reality software and dynamic models. Fifty one percent of respondents ticked "None", indicating that they did not use software tools at all in this context. Sixty nine percent of the reliability software in use had been developed in-house, as had 38% of the Monte Carlo software. When asked "How often do you use the following methods to obtain data on technical risk factors?" the respondents gave the results are shown in Table 4 below. The greyed areas of the table indicate the most popular techniques.
Table 4. Percentage of respondents using specified method to obtain data on technical risk factors

Experiment Service feedback Third-party documentation Design analysis Simulation Probabilistic models Fuzzy models Specialist reports

Always 6% 11% 4% 30% 9% 6% 0% 2%

Often

40%
47%

42%
45%
33% 12% 0% 42%

47%

Occasionally 30% 42%

17%

37% 41%
4%

Never 25% 6% 2% 8% 20%

41% 96%
10%

46%

Integration of Technical Risk Management with Design and Project Risk Management When questioned on the extent to which consideration of technical risk was incorporated into the project risk identification process, 48% percent of respondents stated that the project risk identification process "very much" included identification of risks which affect the technical risk factors, 41% said that it did so only "to a limited extent" and 11% said that project time and cost considerations were separated from technical risks. Respondents were asked "During the design project, if it transpires that a technical risk factor may have an impact on project time-scales or costs, how is this information communicated to the project manager?" and were asked to tick all mechanisms which applied and to specify any other mechanisms used. Respondents overwhelmingly (98%) used verbal communication in project meetings, but formal paper-based procedures were also popular (46%), with software and other mechanisms being infrequently used.

3.4 Barriers to Effective Risk Management

The perceived effectiveness of current technical risk management practice was explored by asking "When faced with technical design decisions under uncertainty do you feel that you have sufficient information available to you to make a rational decision?". In response to this question only 7% were able to answer "Always". Fifty five percent indicated that they often have the appropriate data, but 36% indicated that they only occasionally and 2% never have

590

ICED01-C586/435

the required data. Respondents were asked to expand on the reasons for difficulty in dealing with risk by indicating the main reason for difficulty. The options offered and results obtained are given in Table 5 below.
Table 5. Main reason for difficulty in dealing with risk

Materials Manufacturing Processes Usage Bought-In Sub Systems Sub-System Interactions Design Error in Sub-System Aggregate Budget Overuns

Collecting data... In principle In practice 9% 54%

Modelling im pact of data. . . In principle In practice

6% 15% 10% 14% 10% 7%

49% 49%

65%
44% 58%

50%

13% 16% 11% 17% 26% 16% 13%

25% 28% 26% 9% 16% 16% 30%

4 Conclusions
The results obtained concerned a wide spectrum of type and size of engineering design project, and can be considered representative of practice in "risk-aware" engineering design companies, though they do not provide a statistically unbiased sample. The survey suggests that technical risk management is not well integrated with design and project management processes. For nearly half the respondents, consideration of technical risk was not well incorporated into the project risk identification process - i.e. the process of identifying cost and timescale risks. Also, nearly half the respondents had no formal paperbased or software mechanism to communicate the impact of technical risks on project timescales and costs. The use of probabilistic modelling techniques was not found to be widespread, with qualitative techniques being more widely used. Software tools, when used, are often developed in-house or, if commercial, are low-level modelling tools (e.g. Monte Carlo add-ins for spreadsheets) rather than risk management packages. Over half the respondents did not use any software tools at all to model uncertainty in technical risk factors. Sixty nine percent of the reliability software in use had been developed in-house, as had 38% of the Monte Carlo software. This last figure is particularly surprising considering the relative complexity of such software, when compared for example with development of a simple custom database application. In contrast, only 18% of the Monte Carlo software used to model project risk was developed in-house; maybe reflecting the more domain-specific, or even problem-specific, nature of technical risk models compared with cost-risk and time-risk models. The areas where technical risk most often arose were usage (64% stated it "almost always" or "often" arose here), followed by sub-system interactions (58%), followed by aggregate budget overruns (54%). The areas where it was seen as most difficult to deal with were aggregate budget overruns (55% stated this was "extremely difficult" or "difficult"), followed by subsystem interactions (53%), followed by design errors in sub-systems (47%). Hence the two most problematic areas are aggregate budget overruns and sub-system interactions, which are both clearly related to product complexity. In every single area, the main reason given for difficulty in dealing with risk was difficulty in collecting data in practice.

ICED 01 -C586/435

591

Improvements in risk management practice are needed: 38% of respondents said they "occasionally" or "never" have sufficient information available to make rational technical design decisions. The findings of this survey suggest that efforts should be concentrated on developing systems to help manage complex risk data - for example computer systems to help collect the data needed to model aggregate budgets and sub-system interactions. Research is needed into methods which can be incorporated into such systems, to facilitate rapid development of complex risk models during design. References [I] [2] [3] [4] Cooper. D. F. and Chapman. C. B.. "Risk Analysis for Large Projects: Models. Methods and Cases". Chichester: John Wiley and Sons, 1987. Chapman, C. B. and Ward S., "Project Risk Management: Processes. Techniques and Insights". Chichester: John Wiley & Sons Ltd., 1997. Williams, T., "A Classified Bibliography of Recent Research Relating to Project Risk Management", European Journal of Operational Research, vol. 85, pp. 18-38, 1995. MoD(PE)-DPP(PM) "Risk Management in Defence Procurement", reference D 1 DPP(PM) /2/1/12, available from Ministry of Defence Executive, Directorate of Policy (Project Management), Room 6302, Main Building, Whitehall, London., 1991. http://www.risksig.com/, Project Management Institute Risk Management Group, 2000 http://www.eurolog.demon.co.uk/index.htm, Association for Project Management Risk Management Specific Interest Group, 2000 Baker, S., Ponniah, D., and Smith, S., "Survey of Risk Management in Major UK Companies", Journal of Professional Issues in Engineering Education and Practice, vol. 125, no. 3, pp. 94-102, July. 1999. Raz, T and Michael, E, "Benchmarking the Use of Project Management Tools", Proc.30th Project Management Institute Symposium. Pennsylvania. Pa. 1999 Grassland, R., McMahon, C. A. and Sims Williams, J. H., "Survey of Current Practice in Managing Design Risk". Bristol: University of Bristol. ISBN 0-86292-474-X, 1998.

[5] [6] [7]

[8] [9]

[10] Court, A. W., Culley, S. J. and McMahon, C. A., "A Survey of Information Access and Storage Amongst Engineering Designers". Bath: The University of Bath, ISBN 1 85790 004 9, 1993. [II] Pahl, G. and Beitz, W., "Engineering Design: A Systematic Approach". Second Edition. Berlin and Heidelberg: Springer-Verlag, 1996. [12] PRINCE is a project management method developed for IT projects, by the Central Computer and Telecommunications Agency, a UK government procurement agency. For further information contact the CCTA at Rosebery Court, St. Andrews Business Park, Norwich, NR7 OHS Chris McMahon University of Bristol, Department of Mechanical Engineering, University of Bristol, Queens' Building, University Walk, Bristol BS8 1TR, UK, Tel: +44 (0)117 9288100, Fax: 444 (0)117 9294423, E-mail: chris.mcmahon@bristol.ac.uk, http://www.dig.bris.ac.uk/staff/chris/chrisnew.html IMechE2001

592

ICED01-C586/435

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DEVELOPMENT OF AN 'IDEA' FOR SAFETY

D Vassalos, I Oestvik, and D Konovessis Keywords: Safety, competitiveness, product-life-cycles, risk analysis and management, probabilistic design.

Introduction

By all accounts, ship safety is in a transitional state reflecting the shift from design periphery to a core design factor and from a post-design consideration to a through-life design imperative. Conventional approaches are under scrutiny and potential new approaches come under the microscope as the shipping industry is forced into responding positively. The traditional inertia has been overcome by a new stronger resurgence of safety as a key issue that cannot be considered in isolation any longer nor fixed by add-ons, bringing home the long overdue realisation that lack of safety or ineffective approaches to safety can drive shippers out of business. On the other hand, current ship design practice is not an efficient process, mainly due to lacking of a framework capable of accommodating scientific advances and emerging computer technologies, and the consequent benefits derived therefrom. Attempts to improve the situation in the past were mainly related to enhanced versions of the ship design spiral, which was introduced prior to the computer age. In this respect, computers have done nothing more than increasing the speed of the design process and, in some cases, improving the quality of separate design tasks. Deriving from this, there is clear need for a formalised ship design framework that accommodates and provides for ship design tasks in a way that allows for interaction and iteration in an integrated design environment. To this end, the paper describes the development of an Integrated Design Environment Architecture ("IDEA") for Safety. Following the identification of requirements for the development, the specific elements of the integrated design environment are detailed, with particular emphasis given to the suitability of Blackboard Systems (BBS), the core of the development, to ship design.

Background

2.1 The ship design process

Ship design is uniquely characterised by the fact that some of the most important decisions regarding the vessel are taken at the early stages of the process, allowing all later design actions, which are inevitably bound within the set frame prescribed by the early decisions, little possibility to positively affect cost and performance. Figure 1 illustrates this situation. As the design process proceeds, the knowledge about the design increases, while at the same time the freedom to make changes decreases due to the large costs associated with these

ICED 01 -C586/639

593

changes. There is evidently a need for knowledge feedback at the early stages of the design process where the assigned costs are lower and the freedom to make changes are greater.

Figure 1: Elements of the Design Process

Ship design is a complex engineering decision-making process involving the integration of many subsystems into a final solution. There are many ship design methods in existence, reflecting the ingenuity and experience of designers around the world. The basic constituent, which is of central importance to all methods, is the ship design spiral. This was introduced decades ago by Evans [1], with attempts in recent years focused on enhancements through the introduction of computer technology and modelling techniques [2, 3, 4, 5]. The ship design spiral advocates an iterative, step-wise solution procedure that is time-consuming and produces results, which may be acceptable but not necessarily optimal. It certainly does not take into account whole life cycle issues and is not capable of accommodating effectively and efficiently contemporary and future ship design tools and concepts. There are two major trends evident in ship design research and development today: the pursuit of a definite theory of ship design; the development and application of computer-based tools in design.

Regarding the latter, a great deal of work has been undertaken by industry and academia world-wide resulting in quality software packages, advances in technology and scientific understanding, which combined have shortened considerably the time required during the ship design process. Regarding the former, ship design is still in need of a formalised framework to control and manage the design process in an efficient way with the potential to take advantage of new emerging computer technologies.

2.2 Design for safety

Design for Safety constitutes an integrated approach that links safety performance prediction, risk assessment and design in a way that allows for interface, interaction and iteration. In this process, safety assessment is the "back-bone" that provides a two-way dynamic link between technological developments and design. On the one hand, it gathers and assimilates technical information, prioritises safety issues, identifies practical and cost-effective safety-enhancing solutions and sets the requirements and constraints for the design process. On the other hand, it provides feedback from the design process to the technologists to stimulate refinement and re-appraisal of the "tools", in the light of the experience gained from implementation and

594

ICED01-C586/639

practical applications. This dynamic interplay is demonstrated in Figure 2. This way, it would facilitate implementation of technological innovation and hence development of safe innovative designs to meet the demands of current and emerging markets. A thorough review of the Design for Safety philosophy is given in [6].

Figure 2: Safe Ship Design Iterative Process

A chief concern in integrating safety in the design process, particularly when claiming that this must be done in a way that safety "drives" design relates to the presumption that any investment on safety does not compromise returns. This concept is ill-based. Figure 3 illustrates the relationship between economic and technical issues in a safe ship design process. The outer boundary corresponds to a design solution that achieves a perfect balance among all safety and cost criteria and constraints, which is presently unattainable. Today's practice is represented by the inner boundary, whilst it is argued that a safety-effective and cost-effective solution could be achieved by adopting first-principles-based design. The enhanced awareness on safety-related issues and the improved appreciation of how safety and cost interrelate and interact is slowly beginning to drive home the simple fact that scientific approaches to dealing with safety are the key to increasing competitiveness.

Figure 3: Relationship between Safety, Costs, and Design Constraints

ICED 01 -C586/639

595

An "IDEA" for safety

An Integrated Design Environment Architecture ("IDEA") provides the designer with a means to assess the technical and analytical characteristics of the design using relevant tools. The "IDEA" must be formalised indicating that entities, attributes and relationships for the relevant issues are generic. This allows information to dynamically change, for altering design input and innovations can be readily implemented. The design information is stored in object-oriented knowledge bases, which are updated independently as required. A control and management function is needed to accommodate these issues. Blackboard Systems (BBS) have been identified to have such a potential and are being utilised as the platform to overcome the stated deficiencies. The development of a formalised ship design framework, particularly one addressing "Design for Safety", must adopt an integrated approach, accommodated in a providing environment, which links the ship design tasks and allows for interaction and iteration between them. In this process, a blackboard system supports a dynamic interface between tools and methodologies applied to the various design tasks and it stores/retrieves, as necessary, information about ship design in a knowledge base. An "IDEA" for Safety is illustrated in Figure 4, having a central blackboard to control and manage the overall ship design process applying the appropriate knowledge bases, tools and methodologies.

Figure 4: An "IDEA" for Safety

The integrated Design for Safety environment, illustrated in Figure 5, accommodates a methodological assessment of relationships between safety, cost, and design features adopting a top-down approach by assessing hazards and risks at the event level, e.g. for collision, grounding, impact, flooding, and fire/explosion. Furthermore, the IDEA for Safety accommodates the identification of risk prevention and mitigation measures, cost-benefit quantification of design features/safeguards, assessment of ship performance effects and provides decision support in order to design safe, cost-efficient ships fulfilling the operational themes in an iterative procedure. A holistic description of the various elements of the integrated environment has been reported in [7].

Blackboard systems

Blackboard systems (BBS) are regarded as a part of the Artificial Intelligence family and originated with the Hearsay project in the USA twenty years ago [8, 9]. BBS constitute a realisation of the fundamental philosophy of design co-ordination, a formalisation within

596

ICED01-C586/639

concurrent engineering. Design co-ordination advocates that tasks must not necessarily be carried out concurrently, but rather in such fashion as to achieve optimum performance. Design co-ordination is defined as a high level concept of the planning, scheduling, representation, decision-making and control of product development with respect to time, tasks, resource utilisation and design aspects [10].

Figure 5: An Integrated Design for Safety Environment

The philosophy of blackboard systems is to opportunistically piece together a solution on the blackboard by using external knowledge sources, which are working co-operatively and are activated by a control mechanism, be it human or software programs, applying the right knowledge at the right time [11]. In this respect, various sources of knowledge participate in forming and modifying the emerging solution by knowledge sources contributing opportunistically when called upon. Furthermore, as steps are taken toward the solution, the processing commitments are minimised since the solution is built incrementally and steps of forward chaining can be arbitrarily interleaved with steps of backward chaining. Blackboard systems are particularly effective for incremental solution generation, which is typical for the ship design process, where the knowledge sources contribute to the solution as appropriate outperforming a problem solver that uses the traditional ship design approach to generate a solution.

4.1 Blackboard system components

A blackboard system consists of three components as illustrated in Figure 6 [11]: Knowledge sources: Independent modules that contain the knowledge needed to solve the problem and they have a formal structure to receive and send information in order to communicate with the blackboard. Knowledge sources are static repositories of knowledge, which are activated in a predetermined way by trigger functions, or instances, which are the active functions looking for a triggering command, or condition, on the blackboard. Knowledge sources can be referred to as agents in engineering applications where the technology supports the integration of fully autonomous software and human expertise. Knowledge sources can be added or deleted from the blackboard system as required without influencing the overall performance of the blackboard, they can have a wide diversity in ways

ICED01-C586/639

597

of representing information and problem solving techniques, but must operate based upon a common interaction language. With regard to ship design, lines development could be such a knowledge source, engine selection another, both performed in the ship design process based upon separate methods, tools, and information. The blackboard: A global structure that is available to all knowledge sources and serves as a storage medium of raw input data, partial and final solutions, and control information, as a communication medium and buffer, and as a knowledge source trigger mechanism. A control component: It directs the problem-solving process by allowing knowledge sources to respond opportunistically to changes on the blackboard database. The control triggers any knowledge source based upon a defined ranking, and it can change the focus of attention based on the state of the solution.
Knowledge Sources Software specialists each providing expertise needed by the application. The Blackboard Shared repository of problems, partial solutions, suggestions, recommendations, and contributed information. Control Shell Controls the flow of problemsolving activity in the application.

Figure 6: Blackboard Systems Components

4.2 Application of BBS to ship design

Blackboard systems offer a powerful problem-solving framework when satisfying the five arguments on the left side of Table 1 and their application to ship design is justified on the right hand side of the same table. Blackboard applications are not widely used despite their long history and documented advantages. The reason for this is "that blackboards are only worth pursuing for complex applications" and "while useful for prototyping an application, once developed and understood, the application can be re-implemented without the blackboard structure" [12]. The former statement indicates that for a ship designer a blackboard tool would be invaluable. The latter statement is valid for any type of developments since human experience is hard to beat in any case. The best example on this is ship designers who produce ship designs based on feeling and experience. Three situations are given in Table 2 when a blackboard system is not directly applicable to ship design. These arguments highlight research and development required for the introduction of blackboard systems in the ship design process.

598

ICED01-C586/639

Table 1 : Applicability of Blackboard Systems to Ship Design

Ship Design Blackboard Systems Many diverse, specialised knowledge There are few engineering activities that are representations are needed. more diversified and specialised than ship design. An integration framework is needed that A ship design evolves today by performing allows for heterogeneous problem-solving heterogeneous tasks in a sequential order. representation and expertise. A framework for control and management is needed. The development of an application involves Ship design activities involve numerous organisations, suppliers, consultants, etc. numerous developers. Uncertain knowledge or limited data inhibits Alternative solutions can be designed with little extra effort absorbing uncertainties. absolute determination of a solution. Multilevel reasoning or flexible, dynamic Ship design will profit immensely by control of problem-solving activities is enabling dynamic control between two or more applications such as stability and required in an application. resistance.
Table 2: Inapplicability of Blackboard Systems to Ship Design

Blackboard Systems All knowledge could be easily represented in a framework with which a user is already familiar. The application does not need to make dynamic control decisions.

Ship Design This has yet to be achieved within ship design - the knowledge exists in various places and forms. When implemented this function leads to savings on time, effort, and fewer errors. Moreover, with the implementation of simulation in design this function is needed. The complete application will not be Ship design comprises numerous systems combined with other systems. a framework controlling and managing these systems is called for.

Conclusion

Ship design is in need of a formalised framework that allows for efficient interaction and integration among the ship design tasks and the adoption of an integrated approach accommodated in a providing environment. Blackboard systems have been utilised as the platform in such an environment, which provides a dynamic interface between the various design tools and methodologies. Experience so far suggests that blackboard systems provide the appropriate vehicle for accommodating the ship design process and new emerging computer technologies. It is expected that in the near future computer-based control and management tools, knowledge storage/retrieval, and visualisation tools will become fully integrated in the ship design process. Visualisation is a field that will make huge advances into ship design with the development of high performance PCs to model and simulate ship operations enabling large savings on ship model testing costs [13]. This will enable ship designers to test their designs

ICED01-C586/639

599

in the operating environment feeding valuable information back in the design process to produce better solutions through this dynamic interaction between operational and design phases. References [I] [2] [3] [4] Evans, J.H.: "Basic Design Concepts", Journal of the American Society of Naval Engineers (ASNE). November 1959, pp. 671-678. Buxton, I.L.: "Engineering Economics and Ship Design". BMT Publication, 3rd Edition, 1987. Andrews, D.: "Creative Ship Design", Transactions of the Royal Institution of Naval Architects (RINA). Vol. 123, 1981, pp. 447-471. Mistree, F., Smith, W.F., Bras, B.A., Allen, J.K., and Muster, D.: "Decision-Based Design: A Contemporary Paradigm Ship Design", Transactions of the Society of Naval Architects and Marine Engineers (SNAME). Vol. 98, 1990, pp. 565-597. State of the Art Report on "Design Methods". The Sixth International Marine Design Conference (IMDC 97), Vol. 2: State of the Art Reports, 23-25 June 1997, University of Newcastle upon Tyne. Vassalos, D.: "Shaping Ship Safety: The Face of the Future", Marine Technology. Vol. 36, No. 2, April 1999, pp. 61-73. Vassalos, D., Oestvik, I. and Konovessis, D.: "Design for Safety: Development and Application of a Formalised Methodology", Proceedings of the Seventh International Marine Design Conference (IMDC 2000X 21-24 May 2000, Kyongju, Korea, pp. 151165.

[5]

[6] [7]

[8] Erman, L.D., Hayes-Roth, F., Lesser, V.R., and Reddy, D.R.: "The Hearsay II Speech Understanding System: Integrating Knowledge to Resolve Uncertainty", ACM Computing Surveys. Vol. 12, No. 2, 1980, pp. 213-253. [9] Nii, H.P.: "Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures" (Part 1), "Blackboard Systems: Blackboard Application Systems, Blackboard Systems for a Knowledge Engineering Perspective" (Part 2), The AI Magazine, pp. 38-53 and 82-106, Summer 1986.

[10] Duffy, A.H.B., Duffy, S.M., Andreasen, M.M., and Rimmer, D.: "Team Engineering within the Context of Product Design Development", Strathclvde University CAD Centre Paper. CADC\P\95-13, 3 August 1995. [II] Corkill, D.D.: "Blackboard Systems", AI Expert. Vol. 6, No. 9, September 1991, pp. 4047. [12] Feigenbaum, E.A.: "Foreword to Blackboard Systems", edited by R. Engelmore and T. Morgan, Addison Wesley Publishing Company, 1988. [13] Polini, M.A., Wooley, D.J., Butler, J.D.: "Impact of Simulation Based Design on Today's Shipbuilding", Marine Technology. Vol. 34, No. 1, January 1997, pp. 1-9. Professor Dracos Vassalos Department of Ship and Marine Technology, University of Strathclyde, 100 Montrose Street, Glasgow G4 OLZ, United Kingdom, Tel.: +44 141 548 4092, Fax: +44 141 552 2879, E-mail: d.vassalos@strath.ac.uk, URL: http://www.strath.ac.uk IMechE2001

600

ICED01-C586/639

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 0! GLASGOW, AUGUST 21-23, 2001

HOW MUTUAL MISCONCEPTIONS BETWEEN DESIGNERS AND OPERATORS CAUSE ACCIDENTS IN HAZARDOUS INSTALLATIONS
J S Busby, R E Hibberd, P W H Chung, B P Das, and E J Hughes

Keywords: Safety, human factors, risk analysis and management, man-machine interaction.

1 Introduction
1.1 Purpose
Accidents in complex production systems have led in the past to disastrous losses in revenue and human life, and considerable damage to the natural environment. A central role is often played by the misconceptions that designers have about the intentions of operators or maintenance staff, and operators' misconceptions about the intentions of designers. The purpose of this study is to extract knowledge from investigative reports about how mutual misconceptions have occurred, and direct it at the primary decision making points in both the design and operating processes.

1.2 Background
Various work in the recent past has prescribed specific processes or decision making methods to improve the attention paid to safety during design (for example Gauthier and Charron 1995; Stoop 1997). These methods help set limits on the designer's ability to make unsafe decisions, for example by requiring certain kinds of hazard analysis, and build into the design process the benefits of past experience. But any method that constrains the designer can also make the design process less responsive to the specific circumstances of particular cases, and reduce the extent to which the designer can imaginatively make designs inherently safe. A number of studies have instead concentrated on developing accident databases that provide designers with a resource rather than a constraint (for example Chung and Jefferson 1998, Bielecki et al 1995). However, these databases usually organise cases according to the design discipline and type of artefact involved, and often give the designer little insight into the systemic problems that in fact contributed to the accident. In particular, they often say little or nothing about the expectations that designers and users of the design, such as operators and maintenance staff, had about each other. Much is known about various parts of the problem: about the ways the design of an artefact influences error in its use (for example Norman 1992), about the characteristics that lead to omissions in maintenance tasks (Reason 1997), about the way that systems suffer from complex interactivity and tight coupling (Perrow 1984), and about the fallacy of the 'defencein-depth' design principle (Rasmussen 1990). Yet we still seem to know little about how

1CED01-C586/029

601

people who are remote from one another, like designer and operator, develop models of one another's intentions - and how these models can systematically be in error.

1.3 Context
The study took place in the specific context of hazardous installations, and in particular both onshore and offshore process plant. Such plant presents a variety of hazards that could arise from designers and operators having a flawed understanding of each others' intentions - but their complexity, scale and high inventories of hydrocarbons present particular problems. This can make failure modes difficult to identify and forestall, it can make the transmission of a failure rapid and unpredictable, and it can pose considerable problems for the evacuation of staff and access by emergency services.

2 Method
The basic research design involved four stages: the causal analysis of past accidents; the identification of causes which in some way involve designers' misconceptions about operators' intentions or operators' misconceptions about designers' intentions; the development of agenda-generating mechanisms that use the outcomes of the preceding stages in an attempt to influence key decision making points in the design process; the evaluation of these mechanisms. This paper reports on the results of the first two stages. The causal analysis involved representing accident investigators' reports as causal trees. This follows the procedure reported in an earlier study (Busby and Strutt 1999) and draws on the dataset used for that study (which concerned offshore installations), together with an additional dataset of accident reports in onshore installations. Fourteen of these were reported by Kletz (1998) - who is acting as consultant to this study - and six by Crowl and Louvar (1990). The technical failures implicated in these reports were wide ranging, and included brittle fracture, unexpected static electricity discharge, degraded hoses, ruptured pressure vessels and so on. All reports also cited human and organisational error and it is primarily these that there were the focus of attention in this study. It is important to point out, however, that in searching for mutual misconceptions between designers and operators we are looking for combined weaknesses in engineering knowledge and human psychology. The next step was to inspect all of the causal networks to look for sub-networks, within these causal analyses, that appeared to involve some kind of misconception between designer and operator. For each misconception a description was generated in the form of a short narrative, a summarising clause was developed, and the subject and object of the misconception were identified (that is, who did the misconceiving, and who the misconception concerned). There are several factors that complicated this analysis: The identification of subject and object is not always unambiguous. For example, if the designer had failed to anticipate that an operator would use a device in an unintended way, one could argue that the operator should have anticipated the designer's failure to

602

ICED 01 -C586/029

anticipate this. Product users, one could argue, should be used to product designs that do not meet their intentions. It is often unclear from the accident investigator's report what beliefs lay behind people's actions, and it is quite likely that an investigator would often not be able to determine these beliefs. In some cases, therefore, the analysis involved identifying possible, rather than certain, misconceptions. This does not, however, vitiate the purpose of the study since it is as important to draw designers attention to how things might have gone wrong as it is to draw their attention to how things did go wrong. An attempt has then been made to develop general models on the basis of these specific misconceptions. The purpose has been both to capture the nature of the misconceptions and to try to explain why they had not been undermined by experience. Organisational and individual experience among engineers, in principle, should weed out dangerous models. So where such dangerous models persist it is important to try to work out what is wrong with the way engineering organisations work, the way engineering knowledge accumulates, or the way individuals learn about the consequences of their work.

3 Results
From the cases, about 120 distinct misconceptions have been identified. Rather than list all of them, we have described below some of the generalised modes of misconception together with some of the cases in which they arose. We have concentrated on the misconceptions which designers appear to hold about operators.

3.1 Holding mechanistic stereotypes of operators

Several of the misconceptions involved designers making design decisions as though the human operators lacked exactly those characteristics that made them human. For example, operators would be required to sustain attention in a warm, comfortable environment for long periods, scanning for unusual conditions which occurred only rarely. These are typically conditions that are incompatible with attention and arousal (Warm 1984). Similarly, the failure of operators to follow written instructions in operation and maintenance was implicated: in eleven of the onshore accidents injury or death resulted following the neglect of instructions. Yet it is part of designers' folklore that users of artefact neglect instructions, and most models of people learning how to use objects emphasise the role of trial and error, physical interaction and sometimes social observation - not following instructions. If designers can predict that instructions will not be followed there is an argument they should not rely on instruction following for safe operation. If the objective of engineering is to serve human society, it seems unreasonable that engineers should not acknowledge human characteristics.

One explanation of why designers sometimes fail to acknowledge the limits of human attention is that the operator simply does not enter the designer's model of the system. But this cannot be true if the designer provides a device that requires human intervention. It must be the case that the designer's model of the human operator is based on a stereotype that lacks human characteristics. It seems absurd that designers could really use models of operators that lack what they know to characterise a human being, but it may be self-serving to do so if the expectation is that more realistic models will require more design effort. It is

1CED01-C586/029

603

also possible that the problem is an 'attribution' one - to do with a bias in the way people attribute characteristics to other people, which has been a strong theme in social psychology (Fiske and Taylor 1991).

3.2 Neglecting operators' willingness to gamble

There were cases where operators seemed to gamble and lose. For example, a master of a vessel knowingly sailed into a storm even after sustaining early, minor damage. He was under time pressure, and apparently made a decision based on his assessment of probabilities and outcomes. But it is unlikely that his probability estimations were good ones. There is an argument that if designers predicted that operators would gamble with using equipment knowingly in hazardous modes then they could provide information to support them. It is not enough as a designer to say that product X is unlikely to function in condition Y: it is important to say that product X in condition Y has a probability p of failing. Again it is possible to speculate on why designers' models of operators do not seem to acknowledge that operators will gamble (and should either be helped to gamble informatively or possibly impeded to gamble entirely). It is plausible, for instance, that designers did not predict that operators would be under production pressure. Then there would be no reason to gamble since there would be nothing to gain from it - although, conceivably, operators might gamble if they were bored and expected excitement as a possible payoff. So, rather than designers' models of operators being poor reflections of the operators they might be poor reflections of circumstances that operators work in. The failure to predict gambling behaviour would then be a symptom of the failure to understand an environment.

3.3 Misconceiving operators' beliefs about boundary conditions

Designers appear to be weak at inspecting boundary conditions and operators appear to acquire little experience in testing boundaries - so boundary infringement is a prime cause of accidents. For example, in one case operators had adopted a ballasting practice on a semisubmersible structure that made the structure vulnerable in severe weather. In another case, operators of a small craft kept an autopilot engaged while manoeuvring close to an installation. In such cases the operators did not acknowledge safe limits to operation of a particular device, and the designers had provided a system which allowed or encouraged the operators to exceed these safe limits. If designers better understood the conditions which lead operators to exceed limits, and if operators better understood the inherent limitations in a particular design, this kind of accident becomes less likely. The accident investigations, unsurprisingly, say nothing about the origins of these causes. But it seems likely that designers' weakness at inspecting boundary conditions arises from: analytical difficulty (it can be difficult to identify comprehensively what kind of operation in what kind of environment will compromise the design, and it takes effort to do so); the nature of experience (accidents are uncommon, and failure often does not lead to an accident, so designers may have little empirical knowledge about a design's operating boundaries); motivational considerations (designers probably are reluctant to defeat their creations so may find it hard to think systematically about their failure). It also seems likely that operators' inability to acquire experience in testing boundaries arises from: the nature of the task (it is usually unsafe to explore boundaries in the production system);

604

ICED 01 -C586/029

the effort involved (production pressures typically mean there is too little time to explore boundaries); system complexity (it may be infeasible to develop sufficiently realistic simulations). Since the boundaries of safe operation vary according to environmental conditions in combination with operator actions these difficulties are all amplified. Operators wanting to know what happens if they adopt a particular ballasting practice, for instance, would need to do so in a variety of weather conditions.

3.4 Assuming that operators' know when to replace degraded artefacts

This is similar to the problem described in the previous sub-section in that a boundary is exceeded, but we have described it separately because the boundary is a temporal one and the process of reaching the boundary (time elapsing) is not one that operators control. A simple example of this was a case where a set of hoses that failed, partly because they had been used for too long. But their service life had not been specified by the designers so there was apparently no clear criterion for replacement for the maintenance and operating staff. Possibly the designers assumed a level of preventive maintenance that was unrealistic for the environment, and possibly they had assumed that degradation would be visually obvious. Presumably the culture of a particular industry will guide a designer as to what he or she can expect an operator to be capable of. This will include expectations about whether maintenance is preventive and whether there is enough knowledge to know when an artefact has become hazardous. When designers can reasonably expect operators to make highly competent decisions about when to replace degraded artefacts it may be the case that the operators will be in a better position to say when something should be replaced than a designer. Even then, however, it seems sensible that designers should provide guidance that can be used if competence turns out to fall short. This, in most cases, would include service life ratings.

3.5 Failing to anticipate operators' non-routine goals

In certain cases the design of a piece of equipment confounded operators' intentions when they were trying to do something outside a routine or planned process. Tragically this included operators evacuating an offshore installation in unpredicted circumstances. The installation was a semi-submersible platform which had partially capsized. When operators tried to evacuate they found that the design of the lifeboat davits precluding launching in a partial capsize, and only allowed launching in a full capsize. Designers appear to identify a process which the design has to support, in this case evacuation following a capsize, but apparently sometimes do not reason about how the design can confound operators when there are differences to this process, in this case a capsize which does not fully develop (at least initially). What is required in cases like this is a systematic way of perturbing the conditions assumed by the designer, and testing whether the design is still satisfactory in the perturbed conditions. Routines like HAZOP do support this kind of reasoning. But its success depends on the designers' ability to identify all feasible perturbations, and then to identify all the consequences, and it is hard to see how to assure this.

ICED01-C586/029

605

3.6 Neglecting the possibility of operator lapses

Several accidents arose when the operator experienced a lapse and left some equipment in a potentially hazardous state. For example, maintenance staff left open a hatch that should have been closed to prevent water ingress; an operator of a vessel left an autopilot engaged during close manoeuvring; a cleaner left an oven on after cleaning. In such cases, the operator had probably planned to change the state of the equipment but had failed to execute the plan after his or her attention had switched - perhaps following an interruption. Such lapses are predictable. Putting the equipment into the state that later became hazardous was something the operator had to do to accomplish an immediate goal, while changing the state into a benign condition was not necessary to accomplishing such a goal. It is obviously not feasible in all cases for the designer to do anything about possible lapses, but it probably is feasible for the designer to identify hazardous states and ask whether they could be reached by a lapse on the part of the operator. Sometimes it might be sufficient to improve the cues provided by the artefact: some artefacts naturally signal their current state to a user but others do not (Norman 1992).

4 Conclusion
The mutual misconceptions that designers and operators of complex systems have about each other's intentions appear to be fundamental causes of breakdowns, and sometimes accidents, in these systems. On the basis of early results, these misconceptions seem to be generated by inappropriate belief systems - such as the expectation among designers that operators will seek differentiating information when in reality they seek resemblances. The promise is that, once designers develop an awareness of how these belief systems can be wrong, they will be able to avoid the hazardous situations that arise from misconceptions. And, because the belief systems are so general, they should be able to avoid specific hazards that (through chance) they have not had any experience or knowledge of at a concrete level. Probably most of the misconceptions described in the last section are better described as 'missing conceptions'. It seems likely that the problem arose because, for instance, a designer had not considered the possibility of an event - not that he or she held a wrong belief about that event. This in turn suggests that the designer's model of the design being operated was incomplete in such cases. In some respects, missing conceptions are worse than misconceptions: one is probably more likely to notice a wrong belief than a missing belief. But in other respects they are better: misconceptions have to be positively undermined, whereas a missing conception suggests an open mind. The distinction could be an important one when thinking about how to remedy problems of this kind. It is important, however, to acknowledge the limitations of this study - which are both contextual and methodological. The contextual limitation is that the domain that was studied is quite specialised, and involves the design of highly complex systems which are used by professional operators. Misconceptions between designers and users of, say, consumer products might be quite different. The main methodological limitation in this study has to do with the dependence on accidents and accidents investigations in particular to reveal mutual misconceptions. This means that:

606

ICED01-C586/029

1. Misconceptions that happened not to lead to accidents, but near misses for instance, were not considered. 2. Much of the causation involved in the accident would not be known to the investigator, especially the state of mind of the designer who might have designed any equipment that was implicated in the accident. 3. We know very little if anything of the designer's circumstances - whether he or she was experienced, for example. The upshot is that we can draw plausible conclusions about the misconceptions that can develop between designers and operators, and suggest what kind of misconception to avoid in the future, but cannot be sure about the diagnosis of specific cases. References Bielecki Z, Osinski Z and Wrobel J (1995). Databases for design for safety of all-terrain cranes. Proceedings International Conference on Engineering Design ICED95, Prague, August 22-24, pp 1108-1109. Busby JS and Strutt JE (1999). Design antecedents of accidents and the implications for design for safety. Proceedings of the International Conference on Engineering Design ICED99, Munich, 24-26 August, 1489-1494. Chung PW and Jefferson M (1998). The integration of accident databases with computer tools in the chemical industry. Computers and Chemical Engineering, 22, S729-S732. Crowl DA and Louvar JF (1990). Chemical Process Safety Fundamentals with Applications. Prentice Hall (Englewood Cliffs NJ). Fiske ST and Taylor SE (1991) Social Cognition (2nd Ed.), Mc-Graw-Hill (New York). Gauthier F and Charron F (1995). Design for health and safety: a simultaneous engineering approach. Proceedings International Conference on Engineering Design ICED95, Prague, August 22-24, pp 891-896. Kletz T (1998). What Went Wrong? Case Histories of Process Plant Disasters. 4th Ed. Gulf Publishing (Houston). Norman DA (1992). Design principles for cognitive artifacts. Research in Engineering Design, 4, 43-50. Perrow C (1984). Normal Accidents, Basic Books (New York). Rasmussen J (1990). The role of error in organizing behaviour. Ergonomics, 33, 1185-1200. Reason J (1997). Managing the Risks of Organizational Accidents. Ashgate (Aldershot), p. 97. Stoop JA (1997). Design for safety, a new trend? Proceedings International Conference on Engineering Design ICED97, Tampere, August 19-21, pp 609-614. Warm JS (ed.), Sustained Attention in Human Performance, John Wiley (New York). Corresponding author J S Busby Dept. of Mechanical Eng. University of Bath Bath BA2 7AY UK Tel. +44 1225-826588 Fax. +44 1225-826928 Email ensjbb@bath.ac.uk IMechE2001

1CED01-C586/029

607

This page intentionally left blank

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

A PROJECT VIEW OF THE HANDLING OF UNCERTAINTIES IN COMPLEX PRODUCT DEVELOPMENT ORGANIZATIONS

R Olsson

Keywords: Risk and opportunity management, uncertainty management, integrated product development.

Introduction

The situation in today's complex product development project is growing more and more towards a total involvement of most functions within the organization. The case of a group of few and, within their own area, highly competent engineers performing most of the tasks in fulfilling an idea to a produced product is obsolete. Instead, an interaction across functional departments and within functions is required for a cost-effective success of the outcome of the project. As product development schedules shrink, it becomes more and more crucial that cooperation, communication and management of product development, function in a shorter span of time [1]. Though refinements have been and are made for processes, tools and methods, still the problems lie at the more mental state of mind within a product development organization. Combining technology and organization and transforming it into a symbiotic relation is a difficult task to manage [2]. New, unproved technologies are inherently risky in the early stages of product development. The risks usually include a combination of technological, manufacturing, financial and business factors [3]. Whilst not fully being able to integrate all aspects of product development, uncertainties arise within the product development project and the organization. Uncertainties that will influence the outcome of project time and cost issues, organizational revenues and the customer's view of inadequacy of the organization. To be able to function better both within a product development project and in the assisting and interactive functions within the organization one must be able to handle such uncertainties.

1.1 Objectives
This paper will focus on factors that illustrate the need for and a possible, but yet pragmatic, approach to a better handling of risks and opportunities within large complex product development organizations. Techniques of identifying and analyzing uncertainties along with the action planning are quite well known and will not be discussed and therefore not included in the objectives. Instead the organizational and managerial aspects are of interest and therefore form the basis for this paper.

1CED01-C586/141

609

The following objectives will be covered: To suggest theoretical bases for handling of uncertainties within complex product development organizations. To study the case of handling uncertainties within an organization, to study factors for success, needs and concerns within such an organization. To propose suggestions for future research directions that will contribute in the area of Uncertainty Management. The paper is based on findings from a case study conducted within Adtranz, a global provider of railway services, rolling stock and systems. Also empirical findings from previous corporate initiatives and action research findings from a pilot project form the base for this paper. It is outlined according to the three objectives mentioned above. The first section describes a base for theoretical references suggested for an adequate handling of uncertainties, the second section describes the case of handling uncertainties within Adtranz, and the third section proposes the direction for future research. The first two sections are described in more detail in the following chapters, whereas the third section is included in the conclusions.

1.2 Research methods

Structured interviews in combination with open-ended questions have been conducted with 25 persons within Adtranz. Managers, engineers and other functions within the project or line organization were interviewed. An interview guide/combined survey has been prepared by the researcher and used during the interviews. The guide was sent to all interviewees in advance. In most cases the interviews took place over the phone. The guide was sent to 38 persons within Adtranz. The rate of response was 66%. Due to time constraints all interviewees could not be included. The survey consists of 35 questions where 15 of them were open (that is, no answering alternatives were given).

Theoretical background

Organizational development (OD) is the practical application of the science of organizations [2]. Drawing from several disciplines for its models, strategies, and techniques, OD focuses on the planned change of human systems and contributes to organization science through the knowledge gained from its study of complex change dynamics. When describing organizational settings and relations, a separation between the organization's internal and the organization's external settings and relations is made to view distinctive prerequisites. Internal relations and settings could be described in factors constituting the organizational work setting [2]. The factors are divided into four basic categories, organizing arrangements, social factors, physical settings and technology. Although they have been dealt with separately, these categories are inevitably interconnected. Transorganizational systems are comprised of organizations that have joined together for a common purpose [4]. A common purpose of co-operating internationally within the organization, in consortia's, with subsidiaries and with subcontractors delivering solutions to the concept. For an organization, it is crucial to understand not only the organizational settings but also interrelation settings within this common purpose.

610

ICED01-C586/141

Risk is a characteristic of decisions that is defined as the extent to which there is uncertainty about whether potentially significant and/or disappointing outcomes of decisions will be realized [5], This definition of risk consists of three dimensions, Outcome uncertainty, Outcome expectations and Outcome potential. Uncertainty is described as an outcome, which could result in a positive or negative impact. Uncertainty could either be an opportunity or a risk. The perception of uncertainty often leads to the, quite common but narrow, interpretation of being risks. Though it is much easier to identify negative outcomes from uncertainties, it is of great benefit also to identify potential outcomes as opportunities. The product development process can be seen as the process from the creation of a wide set of alternative concepts, the consequent narrowing of alternatives to a reliable and repeatable product produced in production [6]. The development of new products is a classic example of the use of project management. From a risk management perspective however, this type of project is unique: the risks are high due to the uncertainty as a prerequisite for any product development project launch, the very nature of the project therefore is to reduce risk. The discipline of project risk management has developed over the past few decades as an important part of project management. Risk Management usually consists of four basic steps: Identification, assessment, response planning/action and monitoring and control but sometimes also the preceding step of risk management planning [7]. However, methods of managing risks are of great importance, the focus being on the execution of a series of actions in order to achieve a stable and well-known risk list with plans for mitigation and monitoring. Various techniques for addressing and performing the above four steps in risk management are frequently presented in previous research [e.g. 1, 8]. However, research focusing on the interaction between project- and functional organization and corporate management seems to be rare. Furthermore, the focus has been on a single project basis and mostly on the execution phases of a project. As risks arise within product development projects, not all of them can be managed within the project boundaries. Instead the responsibility for the management of risks organizationally lies either in another functional department, at sub-suppliers, at the customers or within the management of the organization. Research of today seems not to focus on the positive side of uncertainties as much as the negative. As long as an uncertain issue is not assessed to whether it is considered a risk or an opportunity, uncertainties cannot be properly handled neither within the project nor within the organization. Traditional project risk management can portray negative aspects deriving from uncertainties, omitting large positive outcomes i.e. opportunities [9]. Kahkonen therefore emphasizes project risk and opportunity management, as a means to vindicate a focus on opportunities as well as risks.

The industrial situation - Adtranz

Adtranz is a global provider of railway services, rolling stock and systems. They supply mass transit and main line vehicles, plus the related components, train control and communication systems. Adtranz has 22,000 employees in 40 countries, mainly in Western Europe, but also in India, the USA and Australia. The development of products is built on a global transfer of know-how organized centrally per product type and according to the modular concept.

ICED01-C586/141

611

The following prerequisites describe the situation within Adtranz. Prerequisites that are obstructing the organization to take use of existing techniques and methods within the area of Risk Management to the fullest extent: Highly complex product Low series development The uniqueness of every customer delivery order High cost of product Multinational product development teams The situation differs from that of most other industries and the consequence of above prerequisites has lead to actions towards a more effective handling of uncertainties. Williams [10] concludes that in general, beyond a certain size, the risks of projects increase exponentially and this can either be appreciated at the beginning or discovered at the end. Furthermore, as the need for risk management has been widely recognized, this is particularly so in the case of major projects.

3.1 Adtranz Business Process

Within the Adtranz group, a common process model called Business Process (BP) is applied in all product units as the basis for deployment, further development and application of processes and procedures. Also a methodology called Quality Gates (QG) is applied for monitoring of progress at different pre-determined gates. As the BP and QG methodology itself is a process model developed for the enhancement of a globally structured process, it still handles uncertainties and is therefore considered as an approach for an overall handling of uncertainties.

Figure 1. The figure shows the top level Adtranz Business Process Model and Quality Gate methodology [11].

The BP consists of the large sub-processes needed when developing a product. It is divided into a platform development process and a tender/order execution process. The activities range from product strategy and the first marketing activity to the complete take-over, support and service at the customer. The QG methodology consists of lists of issues to be checked at the end of every sub process as a gate check of completion and quality of work. Though the BP and QG methodology is not the product development model itself, it gives a framework

612

ICED01-C586/141

and guidance for developing a product. In more detail, this model consists of a work breakdown structure (WBS) specifically designed for each Product Unit. Such WBS describes development work to be fulfilled in every step of the project, functional interaction and objectives for each and every activity description. Though the BP and QG methodology itself is a means for identifying, assessing, planning and monitoring of uncertainties known in advance it is not sufficient for the needs of the organization. In parallel, as a separate process, a project risk and opportunity management (PROM) method is used. Although it is not an add-in within the BP and QG methodology, it serves as the means for capturing and handling uncertainties throughout the nroduct develooment nroiect.

Figure 2. The figure shows the observed relation between uncertainties included in QG checklists and the total amount of uncertainties within a product development project.

3.2 Organizational view on the existing Business Process and Quality Gate methodology
It is common knowledge that a model for product development must be a part of any organization developing complex products. The application of such an approach as the BP and the QG methodology is considered a well-structured approach, providing a common "language" within the organization. The results also indicate that this model ensures a standardized way of working with enhanced ability to monitor and control a product development project worldwide. The findings also indicate that the purpose of the BP and the QG methodology must be clearly defined and communicated throughout the organization. To further explain the need of the "knowledge of purpose", a common understanding and a feeling of participation amongst employees and proved benefit of use has to be facilitated. It is quite clear that the BP and the QG methodology is not considered sufficient for an adequate handling of uncertainties.

3.3 The Project's view on the handling of uncertainties

The handling of uncertainties is divided into two, quite separate, approaches namely the use of the QG methodology and the Project Risk and Opportunity Management process (PROM). The QG methodology handles uncertainties known in advance. Such uncertain issues are gathered from post-project feedback, the integrated work within the entire project and the creation of project tailored checklists. These checklists are grouped into deliverables and key deliverables in areas agreed upon within the project. Since all issues causing uncertainties to a product development project cannot be included, this method leaves large areas of uncertainties to be dealt with within the management of the project. As seen in figure 3, it indicates a view of the unsatisfactory ability to handle uncertainties within the BP and QG methodology.

ICED01-C586/141

613

Figure 3. The figure shows the interviewees perception of how well the handling of uncertainties is considered within the Business Process and Quality Gate methodology.

When looking outside of the project boundaries, 80% of the interviewees consider the BP and QG methodology not to handle risks and opportunities within the line organization to a satisfactory extent. This supports the continuous focus on the interaction between the project organization and the line organization. In organizations such as Adtranz it is important to hold the ability to manage cross-functional interaction as well as to manage common causes of uncertainties within an international environment. As this methodology relies on the active management of the development project and the reactive attitude towards uncertainties, it is important that checklists to follow up in Quality Gates will produce wanted results. Figure 4 shows the perception of what will happen to issues not included as a deliverable in such a checklist. The major opinion is that they will not get the proper focus, be de-prioritized and only become visible later in the project progress when a proper handling it is probably too late. Also the opinion is that issues not included will mean a risk of them being forgotten about or actually being ignored.

Figure 4. The figure shows the interviewees perception of what will happen to uncertainties not included in checklists.

The PROM approach is a methodology for handling uncertainties from the single project perspective. The methodology defines the strategy of creating a project based uncertainty management process, the sources for identification of uncertain events, the method of

614

ICED01-C586/141

assessing uncertainties, the response planning and the method of follow-up and control. A computerized program supports this methodology. The emphasis is on both risks and opportunities. Though this methodology is well known and is used, to a various extent, within different projects there are some findings regarding the execution of this approach: Uncertainties are mostly identified but not always managed perfectly. There must be a clear link between active work of handling uncertainties and the management of it. It is hard to know the benefits of the process until afterwards. The tendency for large projects is that facilitation is needed for success. The process itself cannot be an "add-on" approach to ordinary development work. If a process for handling uncertainties becomes an administrative workload it will not be used.

Conclusions and future challenges

Organizations developing large complex products face a great amount of uncertainties. Such uncertainties are inevitable in any kind of project due to the very nature of innovation projects. For organizations facing a low series development, highly costly and complex product, the approach of having a BP and QG methodology alone seems to be insufficient. Even the parallel process of project risk and opportunity management is not seen sufficient enough. Considering an international project organization, it is not enough only to focus on the tools and methods used for handling uncertainties. The findings also show the delicate conflict between the administrative workload and the lack of predictable benefits of a process for handling uncertainties. It is quite clear that a process of handing uncertainties must have the ability to show the benefits to motivate an initially increased administrative workload. The approach with checklists has a positive effect on the handling of uncertainties, but they cannot be extended to cover all possible uncertainties. Therefore, checklists can only be seen as a complimentary check of uncertainties. In the start up of a project, as an active method of identifying uncertainties and during the project execution as a reactive check of completion. The findings are validated for the case of Adtranz. Taking into account own experiences, discussions with other researchers, literature and from the company viewpoint there is not anything that contradicts to the validity of these findings considering the case of other companies. This paper also suggests that theories on risk management should be extended to cover also organizational theories, general management theories and the management of major complex projects. In a more holistic view, this will provide a perspective on how to manage large, lowseries, complex, and multinational product development projects.

ICED01-C586/141

615

The organizational structure is believed to influence the outcome of handling uncertainties, by that including the business-oriented perspective of uncertainty management and the viewpoint of a project portfolio. Risks and opportunities will still, despite all techniques and methods, be an organizational and managerial issue and therefore the interaction and the enabling of handling uncertainties within the whole of the product development organization will be crucial. The Author would like to acknowledge Adtranz for their sponsorship, the ENDREA research school and other researchers in the field of Risk Management for their support. References [I] [2] Smith Preston G (1999), "Managing Risk as Product Development Schedules Shrink", Research Technology Management, Vol. 42, pp. 25-32. Porras J.I and Robertson P.J (1992), "Organizational Development: Theory, Practice and Research". In: Dunette M.D and Hough L.M (eds.) Handbook of Industrial and Organizational Psychology 2:nd Ed, Vol. 3. Consulting Psychologist press, Palo Alto, CA, USA. Hartmann George C and Lakatos Andras I (1998), "Assessing technology risk - a case study", Research Technology Management, Vol. 41, pp. 32-38. Cummings Thomas G, "Tranzorganisational Development" (1984). In: Staw B.M and Cummings L.L (eds.) Research in organizational behavior, Vol. 6, pp. 367-422. JAI Press Inc. Greenwich, CT, USA. Sitkin S.B and Pablo A.L (1992), "Reconceptualizing the determinants of risk behavior", Academy of Management Journal, Vol. 17, pp. 9-38. Ulrich K.T. and Eppinger S.D (1995), Product Design and Development, MacGrawHill: New York, NY, USA. PMBOK 2000. A guide to the project management body of knowledge, Project management Institute PMI, Newton Square, PA, USA. Ward S.C (1999), "Assessing and managing important risks", International Journal of Project Management, Vol. 17, pp. 331-336. Kahkonen K (2000), "Balancing Project Risks and Opportunities", Project Management Institute Annual Seminars & Symposium, Houston, Texas, USA, proceedings.

[3] [4]

[5] [6] [7] [8] [9]

[10] Williams T. M (1995), "A classified bibliography of recent research relating to project risk management", European Journal of Operational Research Vol. 85, pp. 18-38. [II] Adtranz (1999), Business Process model. Internal document, Adtranz, Berlin, Germany.

RolfOlsson Department of Machine Design, Royal Institute of Technology, 10044 Stockholm, Sweden Phone: +46 8 790 97 73, +46 70 663 87 75, E-mail: rolfo@md.kth.se With Author 2001

616

ICED01-C586/141

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

DECISION-MAKING - HOW TO AVOID DYSFUNCTIONS? HOW TO ANALYSE DYSFUNCTIONS? HOW TO IMPROVE AN ORGANIZATION BY ITS DYSFUNCTIONS?
J Stal-le Cardinal, M Mekhilcf, and J-C Bocquet

Keywords: Decision making process, process modelling, human resources, risk analysis and management

Introduction

In connection with the industrial objectives that concerns the optimisation of quality, cost and delay, we present a dysfunctions study for the decision making processes. Our approach in this work is to establish a generic representation which considers any company as a network of actors who can make decisions to reach an objective. A functional analysis of process modelling has led us to four characteristics of such a model: the development process is a decision making process in which questions are conceived, accepted, and answered, time appears as an evolution parameter, the human presence is taken into account in the processes, there are interactions between resources (human or inanimate, concrete or conceptual). To focus the modelling approach further, we have chosen a 'dysfunctions' analysis of the decision making process. With this approach in mind we have constructed a pragmatic tool, SACADO, to analyse existing problems of quality, cost, and delay in terms of dysfunctions and to predict likely dysfunctions given a particular set of resources, interactions, humans, and decision making procedures. The study of dysfunctions within the decision making process is pursued with a particular focus on the choice of actor and with a presentation of tools developed to improve that particular kind of decisions. These tools are gathered under the name SACADO (Choice of Actor and Organisation Decisions Aiding System). In SACADO, a target process is proposed to minimise risks of dysfunctions. This method also provides tools to analyse a given dysfunction in order to find causes and recommendations. Finally, SACADO can help in improving an organisation by analysing its dysfunctions.

ICED 01 -C586/187

617

Some definitions

In a company, projects are the translation of the strategic trends into actions. So as to accomplish a project, people have to be chosen as responsible for some actions. At the strategic level of a company, decision-makers have to choose people to be project managers and then, a project manager has to build his project team. On such choices depends the global success of a project. The "choice of actor" is a decision made by a decision-maker that consists in selecting, evaluating and choosing a person to accomplish a action. As we said before, such a choice can be made either at a very high or low level of the company. An example is the choice of contractors during the procurement phase (PMI [9]). Before going any further, it is necessary to define what we call an actor, a decision and a dysfunction.

2.1 Actor
An actor is a human being among company means. Material resources, software, hardware, people are part of the means in a company. What distinguishes an actor from the other means is that an actor: has competencies quantified by a level, can make decisions, is able to characterise the impact of his action in advance, can perform tasks in order to reach a goal, works with other actors.

2.2 Decision
According to Sfez [5], "a decision is not isolated nor broken into pieces, it refers to all other decisions and it is difficult to find the beginning or the end." Mezher [6] describes another aspect of the decision by considering decision as "a process which generates and evaluates alternatives and which makes choices among them." We propose a very simple definition of decision in order to be as generic as possible. Therefore, we define a decision as a process which leads an actor to answer a question.

2.3 Dysfunction
We propose here an analogy with the maintenance area [3] where "a failure is the stochastic cessation of an entity's capacity to accomplish a required function. " Boucly [7], According to Villemeur [8], "after a failure identification, the entity is considered out of order. A breakdown is always due to a failure." By analogy, we consider an actor in a company as an entity whose function is to decide. If the decision-maker is not able to make his decision, then there is a dysfunction.

618

ICED 01 - C586/187

We, therefore, propose the following definition of a dysfunction in a decision process : a dysfunction is a stochastic cessation of an actor's capacity to make a decision, to accomplish an action. If the action expected to be accomplished has not been realised, then there is a dysfunction. The gap between the effective result and the negotiated objective to be reached is called the dysfunction value.

Two models

Current modelling systems used in a business environment may be characterised as having a static kernel, and mono-actor, that is, a single user/decision-maker. The quantity of information required for more realistic models involving changing kernels and multiple actors is large. Nevertheless, such extensions of models are being considered, in particular to manage product development including social, psychological, customer and software perspectives [4]. From another point of view, a great number of product development approaches represent the firm as a set of components (environment, products, processes and resources) to be coordinated. We propose here two models that we consider to lay the foundations of our approach : the DTL (Decision Time Line), as a decision model, and the target process as a core process that helps people making decision.

3.1 Decision Time Line

A key construct is what we call the Decision Time Line (DTL). Figure 1 brings out the six most important steps in any decision process.

Figure 1. Decision Time Line

ICED 01 -C586/187

619

The DTL includes the decision process from the request to the answer. This dynamic representation of a decision making process is constructed in concert with the conceptual architecture for identifying potential dysfunctions. Among the six decision process steps (figure 1), the time line includes four main phases: The first step includes the primary actor/decision-maker in the subprocess of considering a request for a decision, followed by a negotiation phase which represents the interaction of the primary actor and other actors to establish the request environment (i.e. ground rules in terms of time, resources, and type of decision required). If this initial negotiation leads to the request being considered by the primary actor, then the request is identified. The identification includes decomposition of the request into subrequests, when necessary, and the identification of the competencies needed to accomplish each component. The synthesis phase deals with problem resolution/decision-making, if the request is handled directly by the actor, or co-ordination/synthesis if the request has been handled (at least in part) by others. When ready, the decision/answer and its request environment are documented (capitalized) in a database, and the results returned to the request actor. Dysfunctions are decomposed in elementary dysfunctions and represented along the DTL. Elementary dysfunctions have been established during industrial projects follow up. Each elementary dysfunction are related to a DTL step, independent from each others and cannot be studied as a combination of dysfunctions. The gap due to a dysfunction is then evaluated. Using our model, it is possible to give a temporal characterisation of dysfunctions as well as a functional characterisation that allows classification of various dysfunction types.

3.2 Target process

The target process, as illustrated in figure 2, is a process to follow for a specific type of decision, choice of actor, and which helps to avoid dysfunctions. But even if the different steps are properly followed, risks of dysfunctions still exist, nothing can completly erase them. This target process can be used to evaluate the risks and be aware of them. It is a more precise decomposition of the identification and synthesis phases of the DTL, applied to the choice of actor. The identification phase consists indeed in listing all the steps and in realizing the first one (Tasks to perform quantification), whereas the synthesis phase consists in realizing the five others.

620

ICED 01 -C586/187

Figure 2. The target process as a core process for a decision-maker

How to improve an organisation by analysing its dysfunctions?

4.1 How to avoid dysfunctions? The decision card

So as to facilitate the application of theoretic models in a company, some project managers have been asked to fulfil a decision card (which has been designed upon the DTL and the target process) for dysfunctions that appear in their project. An example of such a card is shown in figure 3. Different kinds of dysfunctions have been studied: past dysfunctions in projects at completion, and past dysfunctions or potential risk of dysfunction in projects in hand.

ICED 01 -C586/187

621

Context Tasks to perform (Quality, Cost, Delay)

Context and quantification oftaskstoperfom

Required competencies

Potential actor

Chosen actor and Why

Steps 2 to 6 of the target process

Risk evaluation and Action plan

Dysfunction and Gap (Quality, Cost, Delay)

Recommendation

Result analysis, recommendation and capitalization

Figure 3. An assistant in the decision for the choice of actor

Once such a card is completed, we are able to analyse the reasons of the dysfunctions. With a consequent number of cards, it is possible then to study the general trend for a given company to cope with dysfunctions.

4.2 How to analyse dysfunctions?

The competencies model is used to analyse the reasons of a dysfunction [2]. As shown in figure 4, a dysfunction in a project may have reasons from different natures either linked to behavior, or techniques, or knowledge.

622

ICED 01 -C586/187

Figure 4. A classification of dysfunctions based on competencies [1]

For instance, a dysfunction can be due to the fact that one of our peers has not been recognized competent for a given action (problem of knowing who). When choosing a project manager, a decision-maker can search for competencies such as directing, coaching, supporting, and delegating. The lack of one of these required competencies could be a source of dysfunction in the decision process. This is a problem of attitude.

4.3 Predictions and capitalization

The capitalization database provides a means for dysfunction prediction, by capturing the firm's experience from prior decision-making tasks. Software accessing the capitalization database and the decision-making model can give an early warning to a decision-maker when an action or decision-making strategy is likely to lead to a known dysfunction and consequently a problem in quality, cost, or delay. The capitalization database can also be used to conduct a statistical study of dysfunctions within the firm: What are the risky steps in the decision-making process? What are the main sources of dysfunctions? What are the main effects?

ICED 01 -C586/187

623

Conclusion

We are able to identify a dysfunction in a decision that consists in the choice of an actor. Then, we analyse and evaluate it so as to estimate its relative gravity level. At first, only priority dysfunctions can be taken into account so as to look for their causes and then give recommendations. It is important to notice that recommendations are context dependent. Even if it is always possible to give a list of actions to avoid a dysfunction, the pertinence lies in the capacity to elaborate a strategy of actions more than in the recommendations themselves. We have so far considered individual decisions and competencies. Neither collective decisions nor collective competencies have been taken into account in our approach. It would now be interesting to see how generic our methodology is and if it can be applied to decision and competencies as far as a group is concerned. An industrial experience has taken place at VALLOUREC and testified that SACADO could be an answer to a real industrial need. References [1] [2] Durand, T., L'alchimie de la competence., p.1-38, Paris, 1998. Stal-Le Cardinal, J., Mekhilef, M., Bocquet, J.-C., A biiective user's profile oriented model for design action capitalization.. Third Biennal World Conference on Integrated Design and Process Technology, Berlin, Germany, Vol.3, p.48-55, 1998. Rees, R., Wtiat is a failure?, IEEE - Transactions on Reliability, Woodinville, USA, Vol.46, p.163, 1997. Ullman, D.G., D'Ambrosio, B., A taxonomy for classifying engineering decision problems and support systems.. Design Engineering Technical Conferences ASME, Corvalis, Oregon, USA, Vol.2, p.627-637, 1995. Sfez, L., Critique de la decision.. Presses de la fondation nationale des sciences politiques, Paris, 1992. Mezher, T., Abdul-Malak, M.A., & Maarouf, B., Embedding Critics in DecisionMaking Environnements to Reduce Human Errors. Knowledge-Based Systems., nll, pp. 229-237, 1998. Boucly, F., Maintenance : couts de la non-efficacite des equipements. AFNOR gestion, Paris, 1998. Villemeur, A., Surete de fonctionnement des systemes industriels, fiabilite, facteurs humains, informatisation. Paris, 1988. Project Management Institute Standards Committee. A Guide to the Project Management Body of Knowledge. Upper Darby, Pa. : Project Management Institute, 1996.

[3] [4]

[5] [6]

[7] [8] [9]

Julie Stal - Le Cardinal Ecole Centrale Paris, Laboratoire Productique Logistique, Grande voie des vignes, 92295 Chatenay Malabry Cedex, France, Tel: (33) 1 41 13 15 69, Fax: (33) 1 41 13 12 72, E-mail: stalj @pl.ecp.fr IMechE2001

624

ICED 01 -C586/187

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 01 GLASGOW, AUGUST 21-23, 2001

PRELIMINARY DESIGN OF A RISK MANAGEMENT DECISION TOOL

J M Feland KEYWORDS: design-for-X, design information management, risk analysis and management, barriers to implementation, expert systems, and knowledge management

Abstract

Given the challenge by NASA Administrator Daniel Goldin to develop and embrace Design For Safety practices, tools and methodologies, this paper details an approach to be taken by researchers at Stanford's Center for Design Research and the Learning Lab in meeting this challenge. The recent disappointments of the Mars Climate Orbiter and the Mars Polar Lander have given rise to this challenge along with NASA's continued focus on mission safety and effectiveness. One of the issues highlighted by Administrator Goldin at the 15th Annual NASA Continual Improvement and Reinvention Conference this year were problems with proper knowledge transfer between designers, operators, and risk managers. Within current mission development practices, risk managers, operators, and designers come together during rare program reviews. As a result of these integrated meetings, several action items are taken by all stakeholders that require additional efforts with impacts on cost, schedule, and performance while mitigating risk and ensuring safety. The figure below depicts the activities of stakeholders during a mission development under the current environment of limited knowledge exchange. In the following, a brief overview of NASA's Design for Safety Initiative will be given. Additionally a survey of NASA's current practice of Continuous Risk Management (CRM) will be made. Once NASA's development environment and practices have been defined, problem areas in NASA's current methods will be outlined. Finally the proposed design for a risk management decision aid will be detailed that will assist in reducing the program risk signature. A program's risk signature is an indication of the level of risk in cost, schedule, and performance.

Figure 1. The graph above qualitatively depicts the normal communication interactions under NASA's current practice of Continuous Risk Management (CRM). System level risk identification and mitigation activity only occurs at monthly Integrated Project Team (IPT) meetings and at major program milestone reviews.

ICED 01 -C586/470

625

Design for Safety Initiative

Recent catastrophic failures of some highly visible NASA missions spurred NASA to perform a top-down review of all system development practices. In each mission area three problem areas kept surfacing. To address these significant issues, NASA started the Design For Safety Initiative. Three emerging technology areas have been focused on as sources for potential solutions. Problem Areas Solution Areas Poor knowledge management Poor System Risk and Multiobjective Trade-off Analysis Intelligent System Risk Rigid and nonadaptive systems Management Technologies for resilient systems Knowledge Engineering
Table 1. NASA has identified three problem areas that contribute significantly to recent mission failures. As part of the Design For Safety Initiative, three technology areas have been identified as potential solutions to these issues. [1]

The NASA requirement to be addressed by the Risk Management Decision Aid falls within the domain of the first two problems and their corresponding recommended solutions. Improving Knowledge transfer between designers, operators, and risk managers will rely heavily on knowledge engineering practices to capture contextual information on each stakeholder's efforts. Additionally, the use of Intelligent System Risk Management will make use of this contextual database to support rapid and superior risk assessment and risk mitigation.

2.1 Barriers to the DPS initiative and other Risk Management process
Members of the European Space Agency identify several barriers to effective implementation of Risk Management. The most common barriers are listed as follows: Technical arrogance and individualism of the engineering staff, information ownership linked to personal power, lack of proper understanding of the advantages of Risk Management, Shoot the messenger Program Manager approach, and the inclination of Program Managers to believe that they have always been doing Risk Management. [3] The Design For Safety Initiative will have to contend with all these barriers to implementation. Based on the various risk management programs already in place at NASA, the last barrier seems to be the largest one to overcome. The Risk Management Decision Aid will have to be implemented to consider and overcome all of these barriers to risk management implementation.

Current Risk Management Techniques at NASA

NASA Program Guidance 7120.5A, "NASA Program and Progress Management Processes and Requirements" states "The program or project manager shall apply risk management principles."[8] To that end, NASA called upon their Software Assurance Technology Centre (SATC) to develop a system level risk management course, the Continuous Risk Management (CRM) process, with assistance from the Software Engineering Institute. CRM has five steps: Identify, Analyse, Plan, Track, and Control, while the need to Communicate and Document connects all steps. [11] This process comes directly from the Software Engineering Institute's risk management process. CRM defines risk management as the responsibility of every

626

ICED 01 -C586/470

person involved with mission development and execution. Identifying the risk involves developing a risk statement and the context/rationale in which it exists. Analysing the risk calls for the stakeholder to determine the impact to the program, the probability of this occurring, the timeframe in which the risk is required to be mitigated, a classification of the risk, and a prioritisation of the risk. SATC provides guidelines to assess the probability, impact, and timeframe of the risk. The planning phase calls for the development of a risk mitigation plan focused on eliminating the risk before it occurs rather than increasing system robustness to survive the risk occurrence. In the next step those responsible track the risk status in case the perceived risk situation arise. The final step determines how to mitigate the risk, usually implementing the existing pre-defined risk mitigation plan. Key to all these steps is effective communication and documentation of risks. Gerosa of the Alenia Aerospazio Space Division describes the typical risk factors that exist in space programs as: Technology; Requirements; Manufacturing; Verification, integration, and test; Development status; Team experience and availability; Planning; Subcontractor/Supplier; Customer/Contractual/Legal; and Financial. [5] CRM relies on the vigilance of the Program Manager to ensure these risk factors are addressed during mission development and execution. As part of their system level risk management training in CRM, the SATC has published a sample risk management plan for a fictional project meant to be the example of how to accomplish risk management within a project. This "Project Zeus" risk management plan applies the five-step CRM process as well as details the risk management responsibilities of all development stakeholders. [2] The plan describes several personnel intensive methods of risk identification ranging from formalised questioning designed to expose risk and design team brainstorming. Members of the Integrate Product Teams (IPT), the IPT lead, and the Systems Assurance Manager complete risk analysis. All three groups vote on impact of risk, probability of occurrence, and the timeframe the risk must be acted upon. It then becomes the team lead or Project Manager's responsibility to either develop the risk mitigation plan or pass the responsibility to another organisation. Tracking of the risk status is done by the owner of the risk and communicated to the Project Manager (PM) during weekly or monthly meetings. Decisions are made by the PM to control the risks during weekly and monthly meetings. "Project Zeus" relies on weekly project, IPT, and monthly project meetings to communicate risks and their status. Formalised project documentation is used to document risk information. "Project Zeus" and other real NASA missions suffer from the lack of continuous interaction illustrated in Figure one. Project stakeholders continuously make decisions that affect the risk signature of the development program. Weekly and monthly risk updates place the stakeholders in a constant state of reacting to risk information instead of proactively addressing potential risk situations as they evolve. The entire risk management process creates significant additional responsibilities for all the project stakeholders. The increase in formal program documentation, specifically for risk along with the normal document authoring, approval, and publishing cycles, not only contributes to the growth in the workload of project personnel, but also increases the delay in important program risk communication. Additionally the entire plan relies on a serial risk management process with discrete steps to be taken at various time intervals. The additional duties placed on project personnel move risk management activities from the desired state of an attribute to be considered like cost, schedule, and performance, to a cumbersome tasking that increases the cognitive overhead of all program stakeholders. Key to the success of any NASA mission are the efforts of the operators. Unfortunately the only time operators as asked to consider the risks are during Integrated Product Team meetings. The operational community typically has the greatest insight to the impact and probability of various risk events occurring.

ICED 01 -C586/470

627

Automated Requirements Measurement Tool (ARM) is a software development management tool developed by SATC for providing NASA project managers metrics regarding requirement specification documents. [7] ARM searches documents for various significant phrases, developing metrics for lines of text, imperative phrases, continuances, weakly worded phrases, directive phrases, options, unique subjects, and readability statistics. By analysing these metrics, requirements with the greater risk potential are highlighted for further review. While valid for software specifications, the tool has not yet been expanded to cover the domains required for a system level implementation. In five Israeli companies known as leaders in risk management, an assessment of the validity of risk management tools was performed. [10] The study categorised the tools into five groups based on the SEI risk management process with and an additional category for tools that provide background information in support of a stable risk management environment. The background group of tools received the highest usage rates. The tools in this category support various portions of the entire risk management process. This result indicates that risk management practices are highly coupled with other management practices. Top five risk management tools used by these companies were Simulation (Background), Responsibility assignment (Planning), Risk impact assessment (Analysis), Configuration control (Background), and Subcontractor management (Background). Responsibility assignment and Subcontractor management both focus on identifying an owner of the risk. Risk impact assessment is obviously a critical step to understanding and coping with risk events. Simulation provides insight for all five steps of risk management by acting as a predictive tool. Configuration-control functions as a risk mitigator by controlling the program baseline and managing changes to critical system components. The most used risk management tools were the tools that assisted in all phases of risk management and even relevance to other management practices associated with the execution of a successful project.

Risk Management Decision Aid

Making use of recent developments in knowledge capture, design information management, and decision support systems, a Risk Management Decision Aid will be developed to improve NASA's in-process risk identification and communication challenges.

Figure 2. The above graph represents how risk Management Decision Tool would not only drastically improve in process communication between stakeholders, but also reduce the amount risk mitigation redesign activity and risk assessment activity, thereby leading to safer and more efficient execution of the program.

628

ICED 01 -C586/470

4.1 System Architecture

The Risk Management Decision Aid will consist of six components. These include Knowledge Acquisition System (KAS), the Risk Assessment and Analysis Knowledge-Base (RAAKB), the Design Communication Database (DCD), the Project Structure Database (PSD), the Risk Identification Expert System (RIES), and the Risk Evaluation Expert System (REES) as shown in the figure below.

Figure 3. Risk Management Decision Aid system architecture illustrating which system components require interface to others. Each will be implemented to make maximum use of legacy software and knowledge-base while minimising the cognitive overhead to the Design For Safety stakeholders, designers, risk managers, and operators.

4.2 Knowledge Acquisition System

The Knowledge Acquisition System (KAS) will be made up of three components. These are RECALL-derived program knowledge capture systems dispersed through the stakeholders' activity areas, programmatic email archives, and databases of formal programmatic documentation. RECALL is a design-knowledge capture tool developed by researchers at Stanford University to assist in the capture and reuse of design efforts. [12] The system makes use of video, audio, and sketch data to record the efforts of design teams. This data is then parsed and organised according to sketch activity. Traditional design capture tools capture only audio and video. These legacy systems required tremendous amounts of post processing to make the data useful for reuse. RECALL indexes the design context information with thumbnails of the sketch activity. As the sketches are easily recognised for their efforts, this allows users of this data to quickly locate which contextual data is needed for review. To meet the needs of the DFS initiative, modified RECALL systems will be peppered throughout stakeholder common team areas. These systems will be located where project personnel normally congregate to discuss the project and make decisions that affect the program risk signature. To integrate the use of the system into the program's normal work habits, the cognitive overhead required to make use of these RECALL stations will be minimal. Each system will be connected to the Design Communication database for archival and processing purposes. The Programmatic Email Archives are simple storage databases of project related email communication. The emails contain not only important design and decision history communication, but also contain real-time information of actions impacting program risk. It is envisioned that both the Risk Identification Expert System and the Risk Evaluation Expert System will use this information. Formal Programmatic Documentation such as requirements

ICED 01 -C586/470

629

documents, design specifications, and operating instructions, contain valuable information regarding the program baseline. These documents will be stored in the Design Communication database for further use by the RIES and the REES.

4.3 RMDA Databases

The RMDA makes extensive use of three knowledge-bases. They are the Design Communication Knowledge-Base, the Project Structure Database, the Risk Assessment and Analysis Knowledge-Base. The Design Communication Knowledge-Base is the main repository of project specific knowledge. Captured via the Knowledge Acquisition System, this database contains real-time information about decisions and discourse regarding the program, a time-history evolution of programmatic information, and current program baseline with respect to both the design and the risk. The Project Structure Database contains information regarding the organisation of the program. This includes information such as program organisation chart, IPT members, and contact information. One of the critical pieces of information in this database is a risk profile for each of the program personnel. This risk profile contains information regarding which program elements the author is involved with and a catalogue of past risk related experience. This risk profiling is essential for the Risk Identification Expert System to be able to perform its tasks of integrating several disparate pieces of information in order to assist in identifying potential risk events. The Risk Assessment and Analysis Knowledge-Base contains both the current state of the system risk and the information required to assist the expert systems in aiding stakeholders in their efforts to identify and evaluate risk. Based on lessons-learned and other institutional risk information, this database will build risk cases to assist in evaluating risk.

4.4 Decision Support Systems (DSS)

The RDMA contains two decision support systems that interface with stakeholders to reduce the system risk. The two systems are the Risk Identification Expert System and the Risk Evaluation Expert System. Traditionally Decision Support Systems and Expert Systems have focused on assisting individuals in their decision-making processes. Druzdzel comments that experts, though capable of better decisions than novices, are still susceptible to the same judgmental biases as novices. He gives an example where the ability of psychiatrists to diagnose future violent behaviour in patients was compared to the ability of a simple linear DSS based on past incidents of violent behaviour. The doctors proved inferior to the model. [4] Hamer advocates the development of Group Decision Support Systems to support asynchronous decision support among several group members. [6] The RDMA will have elements of a Group Decision Support System due to the complexity of NASA programs, the many risk factors to be considered, and the number of stakeholders involved. According to Druzdzel and Flynn, Descriptive systems are based on human intuitive reasoning and Normative systems have their foundations in decision theory, probability theory, and decision analysis. [4] It is critical that the RMDA be based on normative methods to avoid the biases of human reasoning, specifically as it relates to NASA missions. This assists in overcoming some of the barriers to effective risk management such as technical arrogance and the propensity of program managers to rely only on past risk abatement experience. Pal and Palmer advocate a hybrid case-based / rules-based DSS structure to take advantage of the benefits of both DSS development methods. [9] Case-based systems involve making use of past experiences to determine the recommended course of action. Rules-based systems represent domain knowledge in the IF - THEN format. The use of Case-based systems allow for exceptions to the more rigidly structured Rules-based architecture. The flexibility to consider many sources of information and models of system behaviour is a requirement of the

630

ICED 01 -C586/470

RMDA as in each NASA mission there are valuable similarities as well as critical differences. For example, the methods and means of achieving a Martian orbit can be used repeatedly to send probes to Mars, while specific experiments rely on domain specific knowledge of limited usefulness beyond the mission timeline. The Risk Identification Expert System (RIES) assists stakeholders in identifying potential risk events. By making use of the Design Communication Knowledge-Base, the Risk Assessment and Analysis Knowledge-Base, and the Project Structure Database, the RIES determines potential risk events and notifies the stakeholders with responsibility for that risk area. The data captured from the RECALL-based program information capture systems is sifted for risk identifiers, similar to the operation of the ARM tool. The archive of programmatic emails is utilised in a similar matter. The RAAKB is used to assess the current risk signature and perform a preliminary assessment of impact, probability, and timeframe for initial delivery to the program stakeholders with interest and responsibility based on the information in the PSD. This allows for the continuous communication of developing risk events to the program personnel involved, rather than waiting for weekly, monthly, or quarterly meetings to surface these potential risk events. Additionally, the RIES will allow for shared notification of potential risk events found independently by stakeholders without the assistance of the RIES. The Risk Evaluation Expert System (REES) goes the next step in assisting stakeholders to evaluate the risk event, suggest potential risk mitigation activities or concepts for increasing system robustness, and update the current risk status of the program. Through the use of a normative, hybrid case-based/rule-based group DSS, each stakeholder makes their assessment and evaluation of the risk events alerted by the RIES and other means. As the REES is a Group DSS, tools will be in place to assist the various stakeholders to come to a consensus on the risk impact, probability, timeframe, and priority. Additionally the REES will be the interface by which stakeholders view the current program wide risk status as maintained by the Risk Assessment and Analysis Knowledge-Base.

4.5 Implementation Impacts and Benefits

As with the use of any new methodology, there are impacts to the organization's normal workings as these new capabilities are brought on-line. During the initial set-up of RMDA there will be some significant resource impacts with respect to infrastructure changes and training on the system. Once up and running, the impacts to organization and individual efforts would be minimized. The RMDA is designed to mesh into the normal working habits of program stakeholders. The only significant impact to day-to-day efforts is the increased awareness of potential risk events and the corresponding response to that knowledge. This extra effort is well worth it as the end result is overall risk reduction, increased mission safety, and more assured mission performance. Applications of RMDA would reduce risk signatures on NASA programs over $10 million. In smaller programs the cost of implementation would outweigh the programmatic benefits gained from RMDA. For NASA the cost of RMDA is much less than the economical and political losses associated with a $70 million mission failure. Beyond NASA's Risk Management needs, the RMDA could reduce the risk signature of projects in several other domains. There are benefits to the development of Defense Systems, specifically with respect reducing both development risk and operational risk. As automobiles become more complex, a tool like RMDA would assist the Automobile industry in flagging risk adverse activity during development. Consumer Product Development, typically at a smaller scale than NASA programs, would also benefit from RMDA, especially if the development stakeholders are distributed geographically. Many industries would benefit from the risk signature reduction afforded through the adoption and use of RMDA.

ICED 01 -C586/470

631

Conclusion

The Risk Management Decision Aid consists of capture tools, knowledge-bases, and decision support systems designed to support NASA. NASA's current risk management programs do not involve all stakeholders, and allow for only sporadic risk communication. Additionally they are hampered by a focus on subsystem risk management rather than a system level approach. Current practices do not significantly reduce the risk signature of NASA missions enough to avoid catastrophic failures. The RDMA will improve the risk signature through the use of the knowledge capture technology; knowledge-base engineering; and Normative, Group Decision Support Systems. By decreasing the time between risk information communication and assisting in rapidly assessing the risk, stakeholders can either mitigate the risk or increase system robustness. The RDMA will ultimately provide NASA the means to accomplish more economical, safe, and effective missions for space exploration. References [1] [2] [3] [4] [5] http://dfs.nasa.gov NASA's Design For Safety Website http://satc.gsfc.nasa.gov/crm/ NASA's Website for Continuous Risk Management Chacuat, J. "Risk Management a Tool Embedded in Project Management." European Space Agency 1st Risk Management Workshop. 1998. Druzdzel, M. and Flynn, R. "Decision Support Systems," Encyclopaedia of Library and Information Science, Kent, A. (editor), New York: Marcel Dekker, Inc., 2000. Gerosa, S. et al, "Methods and Applications of Risk Management in Space Programs," Proceedings of the 30th Annual Project Management Institute 1999 Seminars and Symposium. Philadelphia, Pennsylvania, USA, October 1999. Hafner, A. "Group Decision Support Systems, Executive Team-Management Tools for the Military." Program Manager, January - February 1994. Hammer, T. et al, "Requirement Metrics for Risk Identification," Dec 96, last accessed 23 Jan 01 from http://satc.gsfc.nasa.gov/support/SEW_DEC96/sel.html NASA Program Guidance 7120.5A, "NASA Program and Progress Management Processes and Requirements", April 1998. Pal, K. Palmer, O., "A decision-support system for business acquisitions," Journal of Decision Support Systems, Vol 27, pp. 411-429, 2000.

[6] [7] [8] [9]

[10] Raz, T., and Michael, E., "Benchmarking the Use of Project Risk Management Tools," Proceedings of the 30th Annual Project Management Institute 1999 Seminars and Symposium. Philadelphia, Pennsylvania, USA, October 1999. II1] Rosenberg, L. et al, "Continuous Risk Management at NASA," Proceedings of Applied Software Measurement / Software Management Conference, Feb 1999, San Jose, California, USA. [12] Yen, S., Fruchter, R., Leifer, L., "Facilitating Tacit Knowledge Capture and Reuse in Conceptual Design Activities," ASME DTM Conference, Sep 1999. Capt John M. Feland III HQUSAFA/DFEM, Suite 6H2, 2354 Fairchild Drive, Colorado Springs, CO 80840, USA Tel: 719-964-8058, Fax: 719-333-2944, Email: gohogs@cdr.stanford.edu IMechE2001

632

ICED 01 -C586/470

Authors' Index
A
Agogino, AM Ahmed, S Aldanondo, M Andrade, R Aoussat, A 19-26 75-82 131-138 299-304 361-368 Dong, A Duffy, A H B 19-26 123-130, 155-162, 163-170, 195-202, 227-234 393^100, 537-544, 561-568

Eckert, C M

B
Badke-Schaub, P Barr, G Basson, A H Bell, D G Bender, B Bender, B Bermell-Garcia, P Bjarnemo, R Blanco, E Blessing, LTM Bocquet, J-C Borg, J Bramklev, C Brannstrom, O Brookes, N J Buijs, J Burgess, S C Burvill, C Busby, J S Butter, D 251-258, 457^164 497-504 385-392 243-250 313-320 313-320 99-106 377-384 11-18 313-320 269-276, 617-624 219-226 377-384 305-312 433^40 353-360 497-504 277-284 601-608 99-106 Elstrom, B-O Eris, 0
F

43-50, 321-328, 44148, 47380,577-584 305-312 171-178

Fagerstrom, B Fan, I-S Farrell, J Feland, J M Feldmann, D G Frank, C Frankenberger, E Freisleben, D Fuxin, F

329-336 99-106 123-130 625-632 59-66 285-292 115-122 553-560 369-376

G
Gardoni, M Girard, P Grante, C Gullander, S Gwyn, B 11-18, 285-292 67-74 513-520 40108 123-130

C
Caillaud, E Carrillo, A G Carrizosa, K Chakrabarti, A Chung, PWH Clarkson, P J Coates, G Grassland, R Culley, S J 131-138 481^88 465^72 3-10 601-608 43-50, 321-328, 345-352, 497-504,577-584 393-00 585-592 83-90, 179-186

H
Hadj Hamou, K Haffey, M K D Hansen, P K Hibberd, R E Hills, W Howell, L L Hughes, E J Hughes, P Hughes, R 131-138 561-568 171-178 601-608 393-00 521-528 601-608 277-284 277-284

D
Darlington, M J Das, B P de Medina, HV de Pennington, A Deasley, P J Donaldson, KM 83-90 601-608 449-156 409-416 417-24 505-512

I
Ivashkov, M Y
J

139-146

Johannesson, H Jonson, G

329-336 377-384

633

K
Kennel, T Konovessis, D Krus, P Kunz, A M
L

o
42532 593-600 513-520 42532 O'Donnell, FJ Oestvik, 1 Ohrvall-Ronnback, A Olsson, R
P

537-544 593-600 401-408 609-616

Lamothe, J 131-138 Langdon, P M 3-10, 107-114 Larsen, J B 521-528 Lauche, K 187-194, 425-432 Lee, B S 163-170 Lehtonen, T A 293-298 Leifer, LJ 243-250 Leifer, L 171-178, 211-218, 465-72 Lattice, F 433-440 Lewis, W 147-154 Li, G 99-106 Liang, T 243-250 Lim, S 163-170 Lindley, M W 545-552 Link, P 529-536 Lloyd, T 211-218 Lockledge, J C 27-34 Lowe, A 179-186

Palmberg, J-O Payne, K H Pilemalm, J Pons, D Porter, R Potter, S

513-520 417-424 261-268, 401-408 569-576 99-106 83-90

R
Raine, J K Rehman, F Riitahuhta, A O Rodgers, P A 569-576 219-226 293-298 203-210

S
Salustri, FA 27-34 Samuel, A 147-154 Schabacker, M 553-560 Schmidt,J 59-66 Schueller, A 385-392 Schwankl, L 235-242 Shah, T 179-186 Sheppard, S D 505-512 Sheppard, S 465-472 Shimamura, J 51-58 Simons, C 577-584 Sims Williams, J H 497-504, 585-592 Smart, P 433-440 Smith, J S 195-202, 227-234 Song, S 19-26 Spiroudis, S 529-536 Stacey, M K 43-50, 441-448, 473-480 Stal-le Cardinal, J 617-624 Stempfle, J 251-258, 457-464 Stoeltzlen, N 361-368 Strachan, S 123-130 Suistoranta, S 337-344
T

M
Mabogunje, A Magleby, S P Malvisalo, J M Marie, F Matthews, PC Mbiti, K McDonald,: McKay, A McMahon, C A Mekhilef, M Melo, A F Menand, S Merlo, C Millet, D Miiller, S Murakami,T Muranami, M 171-178, 465-172 521-528 293-298 269-276 107-114 425-32 123-130 409^16 179-186, 585-592 617-624 321-328, 345-352 35^2 67-74 361-368 425^132 51-58 545-552

N
Nakajima, N Naveiro, R M Norling, P 51-58 449-56 401-408

Thoben, K-D Thompson, G Thomson, G A Tollenaere, M

91-98 305-312 489-496 35-42

u
Ullman, D G 545-552

V
Vajna, S Valkenburg, R van Overveld, C W A M Vassalos,D Verbeck, A 553-560 353-360 139-146 593-600 187-194

Weir, J West, G Whitfield, R 1 Whybrew, K Williander, M Wu, J-L Wu, Z Wunram, M

147-154 123-130 393-400 569-576 513-520 19-26 155-162 91-98

Y
Yan, X-T 219-226

W
Wallace, KM Wallmeier, S Weber, F 75-82, 107-114 251-258 91-98

Z
Zika-Viktorsson, A 261-268