Design Management - Process and Information Issues

WDK Publications

WDKl

WDK 2a

WDK 2b

WDK 3

WDK 4a

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

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

13th International Conference on Engineering Design - ICED 01

Design Management - Process andInformation Issues

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

Organized byThe Institution of Mechanical Engineers (IMechE)

Sponsored byBAE SYSTEMS

Co-sponsored byThe Institute of Engineering Designers

The American Society of Mechanical Engineering (ASME)

Published by Professional Engineering Publishing Limited for The Institution ofMechanical 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 orreview, 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 copyrightowners. Unlicensed multiple copying of the contents of this publication is illegal. Inquiries should beaddressed 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 conclusionsdeveloped by authors are for information only and are not intended for use without independent substantiatinginvestigation on the part of potential users. Opinions expressed are those of the Author and are not necessarilythose of the Institution of Mechanical Engineers or its Publishers.

Conference Organizing Team

Steve Culley, Bath University, UKAlex Duffy, Strathclyde University, UKChris McMahon, Bristol University, UKKen Wallace, Cambridge University, UK

Scientific Advisory Board

A Chakrabarti, University of Cambridge, UKR Anderl, Technische Universitat Darmstadt, GermanyR Andrade, Universidade Federal do Rio de Janiero,BrasilM M Andreasen, Technical University of Denmark,DenmarkE K Antonsson, Caltech, USAP Badke-Schaub, Universitat Bamberg, GermanyA H Basson, University of Stellenbosch, South AfricaH Birkhofer, Technische Universitat Darmstadt, GermanyL T M Blessing, University of Cambridge, UKG Blount, Coventry University, UKA Breiing, Swiss Federal Institute of Technology,SwitzerlandS Burgess, University of Bristol, UKJ Busby, Cranfield University, UKM Cantamessa, Politecnico di Torino, ItalyH H C M Christiaans, Delft University of Technology,The NetherlandsP J Clarkson, University of Cambridge, UKJ Deans, University of Auckland, New ZealandP Deasley, Cranfield University, UKW E Eder, Royal Military College of Canada, CanadaK Ehrlenspiel, Technische Universitat Munchen, German)S D Eppinger, Massachusetts Institute of Technology,USAD G Feldmann, Technische Universitat Hamburg-Harburg, GermanyS Finger, Carnegie Mellon University, USAP Frise, University of Windsor, CanadaI Gibson, National University of Ireland, IrelandH Grabowski, Universitat Karlsruhe, GermanyG Green, University of Galsgow, UKK-H Grote, Otto-von-Guericke-Universitat Magdeburg,GermanyP H K Hansen, Aalborg University, DenmarkI Horvath, Delft University of Technology,The NetherlandsSt Hosnedl, University of West Bohemia in Pilsen,Czech RepublicV Hubka, Heurista, SwitzerlandB Ion, University of Strathclyde, UKD Jiati, 720 Lab, Bejing University of Aeronautics andAstronautics, Peoples' Republic of ChinaN Juster, University of Strathclyde,B Katalinic, TU Vienna, AustriaT Kiriyama, Stanford University, USA

S S Kok, Nanyang Technological University, SingaporeL Leifer, Stanford Centre for Design Research, USAB Lewis, University of Melbourne, AustraliaYn Li, Sichuan University, Peoples' of Republic ChinaUo Lindemann, Technische Universitat Munchen,GermanyM L Maher, University of Sydney, AustraliaM Mantyla, Helsinki University of Technology, FinlandD Marjanovic, University of Zagreb, CroatiaH Meerkamm, Universitat Erlangen-Nurnberg, GermanyM Meier, ETH-Zurich, SwitzerlandF Mistree, Georgia Institute of Technology, USAM Norell, Royal Institute of Technology, SwedenM Ognjanovic, University of Belgrade, YugoslaviaK Otto, Massachusetts Institute of Technology, USAU Pighini, University of Rome 'La Sapienza', ItalyD F Radcliffe, The University of Queensland, AustraliaY Reich, Tel Aviv University, IsraelA Riitahuhta, Tampere University of Technology, FinlandR Rohatynski, Technical University of Zielona Gora,PolandN Roozenburg, Delft University of Technology,The NetherlandsE Rovida, Politecnico di Milano, ItalyA Samuel, University of Melbourne, AustraliaJ W Schregenberger, ETH Honggerberg, SwitzerlandP Sen, University of Newcastle, UKM Simon, Sheffield Hallam University, UKJ Simmons, Heriot-Watt University, UKL Stauffer, University of Idaho, USAK G Swift, University of Hull, UKO Tegel, TU Berlin, GermanyG Thompson, UMIST, UKD L Thurston, University of Illinois at Urbana-Champaign, USAM Tollenaere, ENS Genie Industriel, FranceT Tomiyama, The University of Tokyo, JapanD G Ullman, Oregon State University, USAS Vajna, Otto-von-Guericke-Universitat Magdeburg,GermanyC Weber, Universitat des Saarlandes, GermanyM P Weiss, TECHN1ON, IsraelP M Wognum, University of Twente, The NetherlandsK Wood, The University of Texas, USAM M F Yuen, Hong Kong University of Science andTechnology, Peoples' Republic of China

Industrial Advisory Board

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

ContentsPreface

Knowledge and Information ManagementInformation ManagementImproving access to design solution spaces using visualization and datareduction techniques

P M Langdon and A Chakrabarti

Supporting non-structured graphical information in integrated designteam

E Blanco and M Gardoni

Automatic composition of XML documents to express design informationneeds

A Dong, S Song, J-L Wu, and A M Agogino

Design communication using a variation of the design structure matrixJ C Lockledge and F A Salustri

Multi - a tool and a method to support collaborative functional designS Menand and M Tollenaere

Information flow in engineering companies - problems and their causesC M Eckert, P J Clarkson, and M K Stacey

Design case relevance in quantity dimension space for case-based design aidT Murakami, J Shimamura, and N Nakajima

A web-based information tool for application engineeringJ Schmidt and D G Feldmann

Knowledge Representation and ManagementAn agent environment to support co-ordination between design actors

P Girard and C Merlo

Developing a support system for novice designers in industryS Ahmed and K M Wallace

Using domain knowledge to support design requirements elicitationM 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 implementationP Bermell-Garcia, I-S Fan, G Li, R Porter, and D Butter

3

3

11

19

27

35

43

51

59

67

67

75

83

91

99

xii

New techniques for design knowledge exploration - a comparison of threedata grouping approaches

P C Matthews, P M Langdon, and K M Wallace

Computer-supported systematic design and knowledgein the early design phase

E Frankenberger

DEKAS - an evolutionary case-based reasoning system toprotection scheme design

G West, S Strachan, J McDonald, A H B Duffy, J Farrell, and B Gwyn

Knowledge for product configurationK Hadj Hamou, E Caillaud, J Lamothe, and M Aldanondo

An operational model for design processesM Y Ivashkov and C W A M van Overveld

Classifications and TaxonomiesA common language for engineering design practice and research

A Samuel, J Weir, and W Lewis

Using situation theory to model information flow in designZ Wu and A H B Duffy

Shape matching and clusteringS Lim, A H B Duffy, and B S Lee

The product develoment process ontology — creating a learning researchcommunity

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

The application of an automatic document classification system to aid theorganizers of ICED 2001

A Lowe, C A McMahon, T Shah, and S J Culley

Analysis and classification methodology for objectifications in collectivedesign processes

A Verbeck and K Lauche

Design ReuseModularity in support of design for re-use

J S Smith and A H B Duffy

Capturing and classifying information in undergraduate design teamprojects

P A Rodgers

Incorporating incentives into design documentation toolsT Lloyd and L Leifer

107

115

123

131

139

147

147

155

163

171

179

187

195

195

203

211

Scaling-up domain knowledge representation in the development ofknowledge intensive CAD for proactive design for manufacture

X-T Yan, J Borg, and F Rehman

Re-using knowledge - why, what, and whereJ S Smith and A H B Duffy

Documentation and evaluation in early stages of the product developmentprocess

L Schwankl

Mapping experience - learning from experience of peers through socio-technical interactions

T Liang, D G Bell, and L J Leifer

Transfer of experience in critical design situationsP Badke-Schaub, J Stempfle, and S Wallmeier

Organization and Management of DesignProject ManagementProduct development models for shorter lead times and more rationalprocesses - its effects on the work situation for project managers andproject group

A Zika-Viktorsson and J Pilemalm

A multi-project management approach for increased planning processF Marie and J-C Bocquet

Applying conceptual design methods to engineering managementP Hughes, C Burvill, and R Hughes

Finding and implementing best practices for design research activitiesM Gardoni and C Frank

Project Strategy and ManagementLate point differentiation analysis for configurable products

T A Lehtonen, A O Riitahuhta, and J M Malvisalo

On the design of servicesR Andrade

Functional products create new demands on product developmentorganizations

O Brannstrom, B-O Elstrom, and G Thompson

How missions determine the characteristics of product developmentmethodologies

B Bender, B Bender, and L T M Blessing

219

227

235

243

251

261

261

269

277

285

293

293

299

305

313

Planning and Workflow ManagementVisualization 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-suppliercollaboration

B Fagerstrom and H Johannesson

Identifying and analysing changes in a dynamic companyS Suistoranta

Design process planning using a state-action modelA F Melo and P J Clarkson

Concurrent Engineering and Integrated Product DevelopmentIntegrated new product development - a case-based approach

R Valkenburg and J Buijs

Material instrumentation for inter-trade co-operation - a source ofinnovation: application in the domain of painting and varnish finishes

N Stoeltzlen, D Millet, and A Aoussat

Geometry users from a process perspectiveF Fuxin

Concurrent design of product and package- extending the concept of IPDC Bramklev, R Bjarnemo, and G Jonson

Distributed Design/Supply Chain IntegrationA framework for distributed conceptual design

A Schueller and A H Basson

A system for co-ordinating concurrent engineeringR I Whitfield, G Coates, A H B Duffy, and W Hills

Distributed product development - a case study in inter-organizationalSME business networks

J Pilemalm, S Gullander, P Norling, and A Ohrvall-Ronnback

Organizational design - a tool for evaluating alternative extended enterprisestructures

A McKay and A de Pennington

Design TeamsCultural issues in aerospace engineering design teams

K H Payne and P J Deasley

Supporting the teamwork by new means of the information technologyA M Kunz, S Muller, T Kennel, K Lauche, and K Mbiti

The importance of informal networks to effective design managementN J Brookes, P Smart, and F Lettice

321

321

329

337

345

353

353

361

369

377

385

385

393

401

409

417

417

425

433

Managing uncertainty in design communicationM K Stacey and C M Eckert

Managing the integration between design, research, and production in theautomobile industry

H V de Medina and R M Naveiro

Researching the thinking process in design teams - an analysis of teamcommunciation

J Stempfle and P Badke-Schaub

Towards a science of engineering design teamsA Mabogunje, K Carrizosa, S Sheppard, and L Leifer

Dimensions of communication in designC M Eckert and M K Stacey

A statistical study of how differing levels of diversity affect the performanceof design teams

A G Carrillo

Management of the Clarification PhaseRequirements engineering - laying the foundations for successful design

G A Thomson

The organization and management of engineering tendersG Barr, J H Sims Williams, S C Burgess, and P J Clarkson

Modification of a methodological design tool for the developing countryscenario - a case study in product definition

K M Donaldson and S D Sheppard

An approach for structuring design specifications for complex systems byoptimization

C Grante, M Williander, P Krus, and J-O Palmberg

An engineering approach for matching technology to product applicationsJ B Larsen, S P Magleby, and L L Howell

Performance EvaluationFinancing innovation in co-operation projects

P Link and S Spiroudis

Performance management at design activity levelF J O'Donnell and A H B Duffy

A metrics methodology developed in co-operation with industryM W Lindley, M Muranami, and D G Ullman

Improvement of engineering processesS Vajna, D Freisleben, and M Schabacker

441

449

457

465

473

481

489

497

505

513

521

529

529

537

545

553

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

Risk and Uncertainty ManagementThe methodology for system integrity in design

J K Raine, D Pons, and K Whybrew

Change prediction for product redesignP J Clarkson, C Simons, and C M Eckert

Survey of current UK practice in managing technical design riskR Crossland, C A McMahon, and J H Sims Williams

Development of an 'IDEA' for safetyD Vassalos, I Oestvik, and D Konovessis

How mutual misconceptions between designers and operators causeaccidents 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 productdevelopment 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 toolJ M Feland

Authors' Index

561

569

569

577

585

593

601

609

617

625

633

PrefaceThis is one of four books resulting from the contributions to the 13th InternationalConference on Engineering Design (ICED 01). The conference was held in August2001 in the Scottish Exhibition and Conference Centre located on the River Clydein 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, theaim 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 oneof the most pre-eminent conferences in the field of Engineering Design, with thelast two conferences being held in Tampere, Finland, in 1997 and in Munich,Germany, in 1999. Both these conferences attracted well over 500 delegates fromboth academic institutions and industrial organizations. Nearly all the leadingauthorities in the field of Engineering Design attend to report their latest findingsand exchange current ideas with colleagues.

All conferences have focussed on the process of planning, developing anddesigning technical systems and products. ICED covers all aspects and disciplinesof engineering design, from general product development and innovation tofeature-based geometric reasoning and design for later life-phases. As engineeringdesign is a process to which many disciplines are contributing, an additionalemphasis has been placed on design management, organization, teams, andindividuals. Over the years ICED conferences have become the forum forestablishing, maintaining, and improving contacts and co-operation betweenresearchers and engineers from countries all over the world.

It is self evident that the engineering design process has changed to meet thechallenges of globalization, increasing international competition, and the need forsustainable development. Equally the performance and quality of engineeringproducts have improved in many aspects, time to market, performance, reliability,reduced environmental impact, etc. If the improvements are to be maintained, theelements that contribute to the product development process must continue to bestudied and enhanced.

Improvements in the engineering design and its process have been supported bytheories and methods developed by research groups around the world. Theresearch is beginning to mature into an overall and consistent understanding ofengineering design as will be seen in the pages of the four books. However theresults are still fragmented and there is a need to unify the findings, and to ensurethat these findings are transferred into industry.

The theme chosen for ICED 01 was Unifying Engineering Design - Building aPartnership between Research and Industry.

The organizing team received 664 Abstracts and this resulted in some 325 fullpapers. All papers are eight pages in length and went through a double blind reviewof the abstracts and a double review of the full papers. The books consist ofcontribution papers from some 35 countries.

xiii

DESIGN MANAGEMENT

This book consists of some 13 topics and really has an overarching theme of themanagement of the process and the information that supports the process. It coversknowledge and information management at all levels and the organization andmanagement issues associated with the design activity itself.

Books in the seriesBook 1 Design ResearchBook 2 Design ManagementBook 3 Design MethodsBook 4 Design Applications

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

Steve Culley Alex Duffy Chris McMahon Ken Wallace

Knowledge and InformationManagement

Including sub-sections:

Information ManagementKnowledge Representation and Management

Classifications and TaxonomiesDesign Reuse

This page intentionally left blank

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

IMPROVING ACCESS TO DESIGN SOLUTION SPACES USINGVISUALIZATION AND DATA REDUCTION TECHNIQUES

P M Langdon and A Chakrabarti

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

1 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 todesigns of higher quality [2]. FuncSION [3] is a computational tool that synthesises a widerange of solutions to a class of mechanical design problems involving transmission andtransformation of mechanical forces and motions that are specified as inputs and outputs. Ituses a set of primary functional elements along with combination rules to create an exhaustiveset of solutions in terms of their topological and spatial configurations. Previous research hasdemonstrated FuncSION's potential for generating novel solution ideas that designers had notthought of. However, it was found that the large number of ideas generated could not bemeaningfully explored, while their representation proved too abstract to visualise. Effectivesupport for conceptual design should help designers obtain a thorough overview of thesolution space, as well as a detailed understanding of its individual solutions. However, thegreater the variety and number of solutions to be explored, the less likely it is that a detailedunderstanding of the potential of all individual solutions will be achieved. The DESYNsoftware 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 ofassisting designers in their exploration of large solution spaces such that an overview of theentire space is obtained while at the same time facilitating understanding of the individualsolutions contained in it.

2 Background

A paper presented at ICED99 [4] described a scheme adopted in order to solve the aboveproblems. The problem of exploring large combinatorial spaces is an unresolved issue incomputer aided synthesis research, which is further complicated by the difficulty in displayinglarge volume of information [5].

The approach adopted was a novel method of clustering the solution configurations to reducethe space of solutions that the designer needs to consider in order to get an overview of theentire space of solutions [6]. This was done by presenting the designers with representativesolutions that were by-products of the clustering process. In this way, large numbers ofsolutions can be summarised by a small number of cluster exemplars of prototypes.

ICED 01 - C586/223 3

A number of previous approaches have adopted rule-based heuristics for the generation ofsolution 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 apartially 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 interactionwith the systems GUI.

In the authors' earlier paper, some initial validation of the cluster algorithm was reportedfocussing on whether the system's clusterings of solutions were intuitive and whether theclusterings suggested by the system correspond to designers' own partition of the solutionspace. Initial experiments examined a number of DESYN clusterings of two sets of 20solutions resulting from a synthis using 0-5 elements per solution from a choice of < 4elements. Figure 1 is an example diagram of the outputs of the same clustering algorithm for asmaller 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 eachsolution 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 Leverelements.

The arrows indicate the solutions that leave the 3 cluster solution to form new clusters. On theleft of the diagram the six possible solutions output by the synthesiser are enumerated. Thevertical columns show increasing number of clusters in the solution set. The cells show thecluster membership for each solution. Each cluster has a representative solution that isdenoted by circling. Finally, the box in the corner of cells shows the average distance of therepresentative to all the other members of the cluster. The right hand diagram shows a Venntype representation of the 3,4 and 5 cluster solutions. Solution sets for the larger 5 elementproblems were presented to 5 subjects as printed words with illustrative diagrams.

Subjects were required to form groupings of the 20 solutions that corresponded to theirjudgements of those that seemed to them to be similar on the basis of their engineeringexperience. The subject's groupings were scored for the percentage similarity of groupingswith the DESYN clusterings of the same set. This was to test whether designers found thesystem's clustering of solutions intuitive, and whether the clustering suggested by thedesigners correspond to their own partition of the solution space. This clustering was based onan element-pair feature count (focusing on the type of interfaces possible as design elementsin combination), and provided an average commonality, between designer's clustering and the

4 ICED 01 - C586/223

method's, of 74% in contrast to 55% commonality yielded by comparison with a randomclustering.

However, this evaluation was carried out using only the topology, rather than the 3-Dconfigurations 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 forceand motion solution chains; (2) Graphic representations of the clustered solution space. Thegoal of this evaluation is to find whether or not this clustering-based technique improves adesigner's overview of the entire solution space, and whether the software facilities assisttheir understanding of the solution space.

3 Current Developments

Current developments include further development of the GUI and visualisation support, andfurther 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-3Ddisplay of a component chain schematic (Figure 3) that we have developed to improve accessto the functional synthesis software. The former is used to aid visualisation of the spatialrelationships between the component interfaces, while the latter is intended to aid theunderstanding 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 spaceand the spatial layouts of selected solutions resulting from the synthesis is under development.

ICED 01 - C586/223 5

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

Figure 3. The Pseudo 3D visualisation interface

The orientation, direction, and sense of forces will be represented by arrow triplets. TheNominal direction of rotation or force was represented by 2D sprites. Elements will be fittedinto the mechanism boundaries by an algorithm that distributes the element lengths evenlyinto the available space.

Figure 3 represents a schematic of a concept that has four elements, nominally oriented asshown by the arrows, such that an input rotation is taken by the first (shaft-like) element, andpassed on to the second (crank-like) element, which passes the resulting translation via two tierod-like elements to the output point. The 3D representation and facilities for manipulation ofindividual solutions are intended to provide designers a more detailed understanding of theindividual 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 solutionsset 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 thestructured group received the representation in the form of 2D "sun-and-planet" graphicrepresenting clusters calculated by the algorithm, the representative central member and theaverage distance of cluster members from that medoid (Figure 2).

The task required the designers to select, using the representation available to them, a set ofsolutions to the specified problem that were both different from each other and formed a setcompletely representative of all solutions.

In the unstructured condition the designers were given a text field on the interface into whichthey could fetch groups of solution on demand. This was managed by the use of a button thatsimply obtained five solutions from the total set and placed them at the bottom of the list on

6 1CED 01 - C586/223

the screen. No indication of the total number of solutions was given and the solutions werenot presented in any ordering linked to their functional structure. Hence, the designers wereallowed to select as few or as many solutions as they liked. The task further required that thedesigners selected individual solutions form the list (left, Figure 4) that they felt met thecriteria. This was made on a point-and-click basis and the resulting set stored in a further textfield (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 2Dcluster 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 upperright text field. Dwelling on the numbered "planet" members highlighted the location of thesolution 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 (topright, Figure 5) that they felt met the criteria. This was made on a point-and-click basis byclicking on the member "planets" and the resulting set stored in a further text field (bottomright, Figure 5). In both conditions the designers were able to delete members of theirselected set at will.

3.3 Data analysis technique

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

ICED 01 - C586/223 7

and solutions listed by the designers in the list condition (Gl) rather than with those listed bythe designers in the clustered condition (G2), then it could be concluded that designers had abetter overview of the solution space using clustering than without. This would indicate that adesigner 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 theclustering algorithm, taking the size of the list as the number of clusters. A comparison wasthen made between the list of concepts of the designer with the solution clusters generated bythe algorithm to find how many solutions from the designer's list belong to distinct computedclusters. The proportion of the solution space covered by the designer, taken as a measure ofthe 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 solutionspace covered by designers in each group was then calculated by dividing the total of theratios (for all the designers in the group) by the number of designers.

4 Results

List Condition (G1)

Subject

S1

S2

S3

Total

Average

No.

3

3

7

13

4.3

Matched

1

1

6

8

2.7

Ratio

1/3

1/3

6/7

21/32

0.51

Clustered Condition (G2)

Subject

S4

S5

S6

Total

Average

No.

3

3

7

11

3.7

Matched

1

1

5

9

3.0

Ratio

1/3

1/3

5/7

21/29

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 thenumbers of clusters sampled by the designers in each experimental group and this wasreflected by the ratios of computed and designer sampled clusters (Table 1.). Although noinferential 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 threesolutions that sampled only one cluster of the computed solutions.

5 Discussion

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

8 ICED 01 - C586/223

tested in these experiments. However, it was observed that the time to complete the task wassignificantly shorter (about 50%) in the clustered condition. Although this was not measuredaccurately, it may suggest that the list condition designers required more time to gain anoverview 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 twoelement combinations that re-occur. These included mechanisms that allowed orthogonalchanges in force direction, such as lever to lever; lever to cam; or lever to screw links. Thereports collected from these designers suggested that the criteria applied was simplicity ofsolutions, ignoring repetitions of sub-mechanisms and spatially translating force to forceelements such as tie-rods. The effect of prompting the designers for more solutions in thesecases led to the choice of variants on these mechanisms with tie-rods added to circumventpossible spatial constraints.

The limitations of the evaluation lie in the small number of designers sampled and the use of asingle 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 paper-based solution-sorting task. In addition, the clustering method was based on a feature basedon a count of pairs of solution elements. Other features of the solution chain could be used forclustering to further test the effectiveness of the clustering approach. It was also clear fromthe designers performance that a more realistic task would involve a realistic design taskcarried out over a longer period. In addition to this, the pseudo 3D visualisation software wasnot integrated into the DESYN interface such that visualisation of individual solution chainswas possible during the trial. It was evident that such a visualisation tool would have assistedthe designers understanding of the individual solutions. Work is currently underway with alarger group of designers, sampling a wider range of problems over a range of sizes ofmechanisms and difficulties of task.

6 Conclusions and further work

A software system for assisting the visualisation of alternative solutions to mechanical designproblems involving transmission and transformation of mechanical forces and motions wassuccessfully implemented. This utilised a clustering algorithm for the purpose of datareduction and visualisation of a large solution space. An empirical evaluation of this systemexamined whether the designers' sampling of the known solution space was effectivelyassisted by an element-pair clustering represented in a 2D display of clusters, in conjunctionwith a pseudo-3D visualisation technique.

There was no evidence for any improvement in the number of clusters sampled when theinterface provided a list of solutions as opposed to a 2D cluster membership diagram, thougha substantial improvement in time to complete the task was noted. Two strategies wereobserved in the designers tested. The predominant strategy involved listing 'elemental' sub-mechanisms that were capable of orthogonal changes in force direction. These designersignored repetitions of sequences or complex combinations as well as elements providinglinear or parallel force transformations. These second strategy group appeared to list solutionsets that were clearly distinctive sequences, because of simplicity or unique elementcombinations.

The small number of designers sampled does not enable generalisation to designers at large asthe results may reflect individual strategies. It is also possible that designers' choices were

ICED 01 - C586/223 9

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

7 References

[1] Chakrabarti, A. and Wolf, B., Reasoning with Shapes: Some Observations from a CaseStudy", Proc. 1995 ASME Design Engineering Technical Conferences: (9th Intl. Conf.on DTM), DE-Vol. 83, Vol.2, pp-315-322, 1995.

[2] Fricke, G., Experimental investigation of individual processes in engineering design,Research in Design Thinking, (N.Cross, K. Doorst and N. Roozenburg eds.) DelftUniversity Press, pp 105-109, 1992.

[3] Chakrabarti A., and Bligh, T.P. "An Approach to Functional Synthesis of DesignConcepts: Theory, Application, and Emerging Research Issues", AI in EngineeringDesign, Analysis and Manufacturing, Vol. 10, No. 4, pp-313-331, 1996.

[4] Langdon, P., and Chakrabarti A. "Browsing a large solution space in breadth anddepth", A. 12th International Conference on Engineering Design (ICED 99), Munich,Germany, v3 p. 1865-1868, 1999.

[5] Johnson,B., & Shneiderman, B. "Tree-maps: A space-filling approach to thevisualisation of hierarchical information structures". Proc. IEEE Visualization'91.IEEE, Piscataway, NJ, 284-291, 1991.

[6] Kaufman, L. & Rousseeuw, P.J., Finding Groups in Data. Wiley Series in Probabilityand Mathematical Statistics. John Wiley and Sons, Inc., 1990.

[7] Campbell, M.I. ,Cagan, J., Kotovsky, K., A-Design: An Agent-Based approach toconceptual design in a dynamic environment. Research in Engineering Design, Vol. 11,pp 172-192, 1999.

[8] Finger, S., and Rinderle. J.R., A transformational approach to mechanical design using abond-graph grammer. In Design Theory and Methodology, DTM 89, vDE Vol. 17. pp107-115, 1989.

[9] Bracewell, R.H., Sharpe, J.E.E. Functional descriptions used in computer support forqualitative scheme generation - Schemebuilder. AI EDAM Journal - Special Issue:Representing Functionality in Design 10(4): p. 333-346, (1996).

[10] Robertson G.G., Card S.K., Mackinlay, J.D., Information visualization using 3Dinteractive 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 citationlinks. 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, TrumpingtonStreet, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

SUPPORTING NON-STRUCTURED GRAPHICAL INFORMATION ININTEGRATED DESIGN TEAM

E Blanco and M Gardoni

Keywords: design information, design understanding, hypermedia and multimedia,knowledge management

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

1 Evolution of Engineering Information Requirements

Traditionally, engineering activities are performed in a sequential order. Over the last tenyears, companies have tended to apply the Concurrent Engineering approach (CE) in order todrastically reduce the time-to-market of their products [1]. This approach is opposed to thesequential engineering approach because they have respectively two fundamental ways ofworking. In sequential engineering approach, the work starts at the reception of the results ofthe early stage when CE is based on information exchanges. Those exchanges are mainlyperformed verbally face-to-face or on the phone. Unfortunately, this information is thereforepoorly controlled. This term "control" can be characterised in terms of four criteria [2] :

- Information Structuring: it relies on a formal conceptual scheme which organiseinformation at appropriate places. The evaluation criteria are the easyness to organiseinformation in an intuitive and logical way and to be able to manage information atseparate 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, weassume 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 informationexchanged in Integrated Team. We will focus here on information Structuration model. Inorder to meet the rigour needs of companies without going down on a too fine level ofgranularity, we choose an instructional design of the information significance. We thenconsider that the construction of a sentence corresponds to combine instructions formulated interm of variables, which provide a sense to the statement. Exchanged information is then anabstracted entity, a theoretical object which consists of [3]:

ICED 01 - C586/418 11

- Linguistic components which build the significance of information starting frominstructions.

- Rhetoric components which bring a sense to information by addition of contextualinformation.

Figure 1. Instructional design of the information significance

Thanks to this instructional design of the information significance, we characterise differenttypes of information [2] :

Structured-Information (SI), linguistic and rhetoric components of the 57 are generallyimposed.

- Semi-Structured-Information (SSI), linguistic components of the SSI are little formalisedand rhetoric components could be parsimonious.

Non-Structured-Information (NSI), the NSI are very little formalised and the rhetoriccomponents can be very light if they ensure a sufficient degree of relevance for thecomprehension of information by the receiver.

The MICA approach [4] (a specific interactive messaging system) has been developed andexperimented 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 beenimplemented 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 IntegratedTeam.

Nevertheless, this kind of capitalisation from linguistic data is limited because of thegraphical NSI lack. Sketching takes a large place in the group understanding of technicalproblems. Goel [5] also argues that freehand sketches facilitate creative and explorative workat 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 atthe same time models of the product and communication vectors. MICA only takes intoaccount linguistic data but does not take care of GNSI management. This is today one of theactual limit of the MICA approach and more generally of Knowledge Management systems[6]. Generally Groupware solutions for interactive sketching have to be improved.

2 GNSI in collaborative design

In order to analyse the role of GNSI in collaborative design we have carried out a designexperiment [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 thewhole progress of the design. The work began with the requirement list supplied by the clienta few days before the experiment. It took six hours to implement the detailed drafts of eachpart 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 IntermediaryObjects (IO) which, circulating at any given moment between the actors of the process, can beseen 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 productdesigners. These two aspects are so indissociable in the reality of the process that we cannotisolate 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 theobject. What we observe, see and feel in the design process, are objects being constructed,talked about, manipulated, interpreted, transformed, etc. Considered separately, the objectsand actors are merely capacities for action. They are inert, static, mere?? "possibilities". It isthe 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 ofrepresentation they use. This leads to a particular way of objectivising the idea or the intentionby inscribing it in a specific organised matter. Thus, for example, a drawing is not simply afaithful representation of the mental idea or specifications : it is a translation, i.e. a realisationand 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 oron screen) and its own rules and conventions. Lastly, the way in which the IntermediaryObjects play the role of mediators in the design process is a result of their beingrepresentations.

IO contents are mainly of cognitive nature : it results from the use of acquired knowledge bythe actors in their various fields. They also signal the gradual production of new knowledgeabout the product as it is being designed. However, these contents are only of a cognitivenature in a situation of action, oriented by a given project and made up by the choices of theactors, the multiple negotiations that they are involved in, and the compromises and decisionsthat result from these. Therefore the cognitive contents cannot be isolated from the context ofaction

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 situationof the experiment that we have carried out emphases on the second category of sketches. Thecollaborative activity involved many talking sketches. On the contrary, studies based onsingle 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 areable 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 andcognitive characteristics that enhance opened or closed use. The situation of action as well asthe 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 forhis own use and after a few minutes be proposed to the others for evaluation. It moves from aprivate status (it is a thinking sketch), to a public one in the centre of the table. The existenceof the private area is very important for the designer. This area is the thinking area that allowsto explore ideas without judgement from the other. In a second step, the actor presents themeaning 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 thedesigner's solution mental image. But this talking phase is also a thinking phase for the groupthat can make the sketch evolve. Every sketches are not built in a private area. Some aredrawn 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 theinstrument of solution negotiation and elaboration, can get a prescriptive status after the grouphas built an agreement over it. For example, the sketch figure 2 got this prescriptive status bythe group agreement. This decision is confirmed by a mark on the object: One of the actorunderlined the word piston. This mark (detail Al) acts as the validation of the agreement. Thedefinition 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 betweensuccessive sketches in the early stages of design: lateral and vertical transformations. A lateraltransformation movement goes from one idea to a slightly different idea. Vertical express amovement 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 evolutionbetween to successive sketches. The next table sum up the different categories of sketches wehave identified.

Thinking

Talking / open

Prescription / closed

Lateral transformation

Private new conjecture

Public new conjecture

New prescription

Vertical transformation

Private in depth conjecture

Public in depth conjecture

In depth prescription

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

14 ICED 01 - C586/418

Table 1. Typology of sketches

Private area

Public area

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. TheObject presented in figure 3 is in fact an addition of different sketch steps. The building ofthis sketch represents 20 minutes of group interaction during the design process. We considerthat it is in this object that emerges the solution principle developed during the next phases ofthe experiment[7]. The first sketch (detail A) was drawn to put a end to a misunderstandingbetween two actors. They did not have the same interpretation of the requirements. The threesketches (A, B, C) allowed them to build a shared understanding of the problem. Then, fromthis representation a third actor had doubt about the connection between the device and itsenvironment. This actor assessed the rubber tubing connection (detail D) as a non reliablesolution for this system. From this negative evaluation of the solution elements represented onthis sketch emerged a few minutes later a rigid and quick connection solution that isrepresented (detail E) on the sketch. This move is a lateral transformation that highlight theemergence 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 blocksinterconnection (detail F). This last view is a vertical transformation showing the samesolution from another point of view.

Figure 2. Status of object moves during theprocess.

Figure 3. Different level of sketches in the samedraft...

This sketch shows that the knowledge of construction process is necessary to be able tounderstand the sketch. In this sketch, aborted solutions and the solution chosen arerepresented on the same level. Nothing but the knowing of the process allowed the actors todifferentiate the good from the aborted solution.

This point allows us to point out that this type of GNSI is not able to support a prescriptiontask. It failed as a memory of the process, In our protocol, we highlight that the actorsthemselves 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 tosemantic in a local convention. This allowed them to let some part of the device in a lowdefinition level: fuzzy and partial. The objects were used as "cognitive artefacts". Theparticipants did not describe precisely what they were talking about, they showed the differentelements they wanted to highlight with a finger or a pen and they used diectic words to pointthem. For example, an actor said: "that will be difficult to manufacture" (showing theelements 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 theycan also use a higher level of convention as cultural ones, shared by the actors (the rules ofindustrial drawing in our case).

The sense of the sketch is built in the action process and the conventions which allow thisinterpretation are quite local. Rhetoric components of sketches are specific and part of thelinguistic components are built within the action itself.

This characteristic of GNSI is important in order to imagine design tool able to support GNSIin an asynchronous communication process; furthermore, in order to involve sketches in aknowledge capitalisation process as MICA does for textual NSI. Indeed local conventionswhich allow interpretations are built in the interaction process. They won't be available toactors that were not involved in the process itself.

3 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 toolhave to be minimised [14]. Even if we can expect that the actors will learn the tool. That iswhy the tool is based on a simple blackboard technic and uses a digital table with anelectronic pen. Indeed, when the designer needs formal drawing he will mainly use CAD orStructured information tools. Sketches are just GNSI and support fuzzy and partial definitionsof elements. The functions that we offer are not supposed to help the drawing process but topartially structure GNSI in order to capitalise and treat them in the knowledge process. We areat the moment unable to manage a knowledge treatment directly on sketches. The principlewe develop here is to characterise GNSI, track the steps of the building process and toassociate textual and symbolic information that the data-mining techniques used by MICA areable to treat. At the moment, a designer creates a new sketch, he creates a properties filecontaining the legend of the file, type of the GNSI created and all the textual annotationscontained. All this textual information is able to be treated by the MICA data-miningprocess [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 drawingprocess. It is also impossible to identify in a sketch the valid elements from the abortedsolutions. It is important to follow the sketches modifications and to track the different sketchlevels 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 wantsto 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 newlayer disconnected from the previous sketch. In order to track information about the sketchcontents and intentions, we characterise the type of opened layers. Six types of layers areavailable corresponding to the typology proposed in table 1. Public layers and private layershave different properties. When an actor wants to send a sketch, the public layers areautomatically sent. Private layers sending is optional. If the actor accepts to send them thecategory 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 thecolour 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 differentdevices to the users. Firstly an actor as to define a title to the sketch using few keywords. Wenotice here that some contextual components (product, process, state, part etc. ) are alreadyidentified in the MICA form. [2] [4]

It is important to give the actors the ability to express comments in the sketch itself. In asynchronous interaction around sketches actors explain some elements of the solution theyfocus on. Drawing is generally accompanied by a speech concerning the sketch. In anasynchronous process, the speech does not exist. It is supported by writing in the message orby 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 areaand to associate elements that allow the receiver to interpret the sketch in the right way. Theyhave sometimes to explain some symbolic elements they have used to fuzzy represent anelement. Annotations can allow them to do it. The annotations are textual information that areconnected to the graphic properties.

A further step is to allow an actor to define different types of annotations using colour andtype of markers. Each time he defines a new type, he has to explain the legend of thissymbolic feature. Laureillard had pointed out the importance of what he called co-operativefeature in the co-operation between specialists [15][16]. Those symbols are local conventionalsupports which refer to shared knowledge between the different actors. We don't have deeplyinvestigated the different types of annotation. Our proposition is to offer a toolbox to theactors. They have to define themselves the relevant type co-operation feature.

4 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 asynchronouscommunications tools for design activities. Engineering design needs visual representations:structured (like CAD models) and non structured (like sketches). GNSI allows to managequick conjecture-evaluation process. We notice that the move from direct interaction totextual explanation implies the risk of the deterioration of the contents. But the advantages oftextual information related to GNSI are their ability to be treated in a knowledge process.

References

[1] B. Prasad, Concurrent Engineering Fundamentals - Integrated product and processorganisation, Vol. 1, Prentice Hall, Englewood Cliffs, NJ, 1996

[2] M. Gardoni, M. Spadoni, F. Vernadat, "Information and Knowledge Support inConcurrent Engineering Environments", 3rd International Conference on EngineeringDesign and Automation, EDA'99, Vancouver, B.C., Canada, August 1-4, 1999

ICED 01 - C586/418 17

[3] Moeschler, J. Modelisation du dialogue (representation de 1'inference argumentative),Editions Hermes, Paris, 1989

[4] M. Gardoni, Maitrise de 1'information non structuree et capitalisation du savoir et dusavoir-faire en Ingenierie Integree - Cas d'etude Aerospatiale Matra, PhD thesis of MetzUniversity 1999

[5] Goel V, Sketches of thought MIT press Cambridge, MA 1995

[6] Gardoni M., Blanco E Taxonomy of information and capitalisation in a ConcurrentEngineering context 7th ispe international conference on concurrent engineering(CE'2000), Lyon, France, July 2000

[7] Blanco E., 1'emergence du produit dans la conception distribute PHD thesis INPGrenoble 1998

[8] Garro O., Salau I., Martin P., Distributed design theory and methodology, Concurrentengineering: research and applications, vol 3/1/1995.

[9] Vinck D., Jeantet A., 1995 Mediating and commissioning objects in the sociotechnicalprocess of product design: a conceptual approach, pp111-129 in D. Mac Lean, P.Saviotti, D. Vinck (eds), Management and new technology : Design, Networks andStrategy. COST Social science serie. Bruxelles. Commission of european

[10] Blanco E., Garro O., Brissaud D., Jeantet A., Intermediary object in the context ofdistributed design CESA Computational Engineering in systems applications, IEEE-SMC, 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 inDesign studies 21 N°5 pp 465-481 sept 2000

[13] N. Dodier, les appuis conventionnels de I'action elements de pragmatique sociologiqueReseaux n°62 edition CNET, 1993

[14] Aytes G., Comparing Drawing Tools and Whiteboards: An Analysis of the GroupProcess 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 throughtvirtual or physical objects. In COOP 2000 conferences Workshop Sophia AntipolisMay 2000

Dr Blanco EricSoils Solids Structures laboratory, Domaine Universitaire, BP 53, 38041 GRENOBLE Cedex9, France, Tel: (33)-4-76-82-70-11, Fax (33)-4-76-82-70-43, mail - eric.blanco@hmg.inpg.fr

Dr Gardoni MickaelGILCO 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) IMechE 2001

18 ICED 01 - C586/418

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

AUTOMATIC COMPOSITION OF XML DOCUMENTS TO EXPRESSDESIGN INFORMATION NEEDS

A Dong, S Song, J-L Wu, and A M Agogino

Keywords: Information analysis, classification and retrieval; information representation;design information management

1 Introduction

Engineering design is an information intensive activity. It is reported that designers spend inexcess of 50% of their time in handling information [7]. Thus, the efficiency and the qualityof the design process depend considerably on how well designers are able to handle largeamounts of information. One study [8] of the information required by design engineers tocomplete their jobs indicated that less than 50% of that information was actually available andonly 20% could be provided by the existing specialized applications. Directing the rightinformation 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 resultof these findings and the recognition that lacking sufficient or missing key design informationmay lead to sub-optimal decision-making and design [2,4]. Much of the existing research hasfocused on the capture, storage, indexing and presentation of design information includinginformal information [3,9]. Less work has been done on information retrieval based on anunderstanding of individual designers, their experience, their skills and the ways in whichthey use information in the context of their design task [1]. One key step in finding the rightinformation is expressing information needs in context. This paper presents a methodology togenerate an XML (extensible Markup Language) document that expresses the informationneeds of a design engineer. XML documents and their underlying Document Type Definition(DTD) offer an efficient structure for the organization of design information [5] andrepresentation of information needs. Through declarations of XML entities and the inherentstructural hierarchy of XML documents, XML documents can express the designer'sinformation needs while framing the design's structural hierarchies. For example, an elementin the DTD may permit the design engineer to express a preference for formal companydocuments of past designs (e.g., technical memos) rather than informal design notes. Thedata in the XML document may be drawn from a repository of semi-structured orunstructured text documents that the design engineer has retrieved and placed into a personalinformation store by using an information retrieval system.

Our methodology draws from the computational linguistics techniques of natural languageprocessing and latent semantic analysis (LSA). We assume there exists some underlyinginformation needs that are expressed by the type of information the engineering designerwishes 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 formatof 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 containsinformation directly from the documents that is consistent with the major patterns ofinformation preferences of the designer.

2 Methodology

2.1 Technical Approach

The methodology for automated composition of the XML documents proceeds along twoaxes: 1) explicitly solicit information needs from the designer through standard informationretrieval means; 2) implicitly monitor the information retrieval behaviour of the designer toinformation sources including the type, quality and information contained in the documentsthe designer chose to retrieve. We test this methodology on access to unstructuredengineering data, such as full-text, because unstructured, textual documents are the principalmode of communication by engineers. Before proceeding to a detailed discussion of ourmethodology, we discuss two core technologies to the methodology: mining of transactionlogs 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 asmodelling user information needs. Most information retrieval systems require that peopleexpress information needs through a set of keywords or key phrases. However, ascertaininginformation needs simply by a word or two is inadequate and subject to loss of contextualinformation. For engineering design, studies have shown varying information needs ofdesigners depending on level of expertise and stage of the design [1,6]. Our approach inmodelling user information needs is based on a human-centred computing. Our methodologyexamines the user's document access patterns, that is, the user's personal information storeand transaction history in an information retrieval system, for patterns of informationpreference. The basic approach is to examine the user's session information over all sessionswhile using the information management system. In learning information needs implicitly,we are primarily interested in discovering the similarity between documents that the user hasdownloaded into a personal information store. The assumption is that the user's particularchoices of documents to store locally are indicative of information needs. Thus, instead ofrequiring the designer to a priori categorize the information, the system attempts to learn asimilarity mapping using contextual clues such as project name, engineering discipline, anddocument format. Similar categorisation strategies have also been found in the classificationof supplier information practised in industry [12].

To ascertain relevance, the system records each document downloaded into the user'spersonal 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 ofthe content of the document containing meta-information such as abstract, author, documenttype, and subject. The assumption is that during any single session utilizing the informationretrieval system, the user has a dominant goal (information need) in mind that is expressed bythe type(s) of documents the user decides to download. Similar assumptions exist in otherstudies [13] of information retrieval systems.

We use the vector space approach [14] for document and query representation. Weanalytically 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 allcombined vectors consisting of the query and relevant documents is called the "centroid" ofthe user's intended information needs. The centroid is then used as a representation of thedominant information need of the user. The maximum angle between the document vectorsor query string vector and the centroid is used as an indication of the variation in the user'sinformation needs.

2.3 Computational Linguistic Approaches

Our methodology employs two computational linguistics techniques, natural languageprocessing and latent semantic analysis, to extract and summarize the primary topic of a set ofsimilar documents.

Natural Language Processing

While we use the designer's past transactions as an indication of information need, thestructured information contained in the documents that are referenced in the transactionsneeds to be discovered and refined before it can be utilised effectively. The key phraseretrieval process helps in crosschecking the indexed subjects and compacting the size of theaggregated XML document by representing paragraphs of text with just a few representativenoun phrases. As the designer adds documents to a personal information store, we do notneed to concatenate all the textual information about the document to the XML document, justthe extracted noun phrases that are not already in there and plug them under the appropriatetags. By identifying the noun phrases in the document, we are able to find the correspondingcontents for each XML tag in the text. Additional rules and procedures are needed other thanstandard noun phrase retrieval process to perform this task for all tags. This latter componentforms a part of future research.

Extracting from the full-text content-bearing noun phrases documents that can be used inprofiling and indexing involves 3 steps: tokenization, part-of-speech (POS) tagging and noun-phrase identification. Tokenization is a procedure that identifies sentence boundaries andremoves extraneous punctuations. POS taggers then take the processed corpus and tag eachword with their POS information. Taggers that operate following semantic rules or juststatistical information were developed. After the text corpus has been tagged with POSinformation, we could use the contextual information to identify noun phrases. The extractednoun 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 permitscomparisons of semantic similarity between pieces of textual information. The idea is that thetotality of information about all the word contexts in which a word does and does not appearprovides a set of mutual constraints that largely determines the similarity of meaning of wordsand sets of words to each other. The primary assumption of LSA is that there exists anunderlying or "latent" structure in the pattern of word usage across documents. LSA uses thematrix technique of singular value decomposition (SVD) to reflect the major associativepatterns of words in the document and to ignore the smaller influences. The ability for LSAto remove the obscuring "noise" makes LSA useful as an analytical tool for discovering theprimary conceptual content of documents. We use LSA to help us to categorize and group thedocuments 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 localitythrough 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 expresstheir 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 informationrequired to manage, locate and evaluate learning resources. Having a standards-based XMLDTD allows us to assess our methodology's completeness and efficacy and for comparisonagainst other systems. Because of the analogous human cognitive processes of informationprocessing and learning [11], the LOM serves as a reasonable model for describinginformation needs.

Once the user has specified an XML DTD, the user must now utilise the informationmanagement system, retrieving and downloading design documents. The system implicitlymonitors the information retrieval transactions of the user, eventually formulating a seed anXML document containing information from the user's session. Typically, the XMLdocument 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 semanticanalysis to characterize the knowledge conveyed by the all documents the person chose toview. To perform this phase, we analysed the transaction logs containing the transactions ofboth 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 relevantdocuments necessary for phase two. Using a similarity measurement, the system identifiestopics represented by the documents the user viewed. By doing this step, the systemascertains the topic locality of the various documents the person viewed. This is a critical stepbecause the user may have multiple and widely varying information needs. Then, for eachtopic locality, the system augments the XML document expressing the user's informationneeds with the metadata elements from each relevant document. In practice, the informationmanagement system will contain most of the information required to complete the taggingsuch as Author, Title, Date, and Format. Subject and Description information are generatedautomatically from the second phase. This matching can be done by exact one-to-onecorrelation, i.e., both the tag and attribute match, or via a crosswalk between the informationabout 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 theinformation management system.

In the second phase, we apply natural language processing techniques to ascertain theprincipal subject of the documents within each topic as discussed in Section 2.3. The processrepeats until all possible elements in the user's original XML DTD are filled, resulting in afully marked up XML document. The completed DTD is now an expression of theinformation needs of the designer, based upon the available information stores and the patternof information retrieval undertaken.

In summary, a designer's information needs can be found implicitly by looking at the set ofdocuments the designer has deemed relevant and useful and stored in a personal informationstore. We use LSA to find signatures of similarity in this set of documentation. Once we findthe 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 thefull LSA space by combining information from all the similar documents, with some of theinformation filtered through NLP techniques to reduce the size of the document. Otherinformation about the document indexed in the document database, such as document type, isadded to the corresponding XML tag. This final XML document is then an expression of thedesigner's information needs.

3 Experimentation and Results

3.1 Test Case

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

3.2 Results

First, we validated the ability of our methodology to discover information needs. Weconducted this study by analysing for the known information needs of all users of the digitallibrary. Based on the fairly homogeneous content of the digital library (courseware onengineering design) and the known profile of the audience of the digital library, we expectedthat our methodology would reveal one dominant information need, namely coursewarerelated to engineering education. We would not expect for the system to reveal numerousdistinct clusters of information needs. We ran the latent semantic analysis over the entireusage database. Figure 1 illustrates the distribution of all users' information needs overmultiple 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 downloadeddocument 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 casestudies and courseware on the design of disk drives, a specific subset of engineeringeducation. 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 theinformation needs of one sample user, specifically information on "control systems". Thecircle represents, in LSA space, the initial query to the information retrieval system whereasthe boxed numbers indicate the documents downloaded by the user. One can then applylatent semantic analysis to ascertain the similarity between downloaded documents, theoriginal query, and the documents themselves. Users may have multiple information needsdespite using the same keyword to query the information retrieval system. In the exampleshown, 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 foundthat 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 anXML 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 softwareengineering graphics tutorialsengineering visual encyclopedia

24 ICED 01 - C586/422

mechanicsvirtual 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'sinformation needs as an aggregation of the documents that the user found relevant and usefuland that were related to each other.

4 Conclusions

This research has established a basic framework for identifying and modelling engineers'information needs using XML documents. We performed latent semantic analysis over acollection of engineering resources to construct information needs as vectors in LSA spacebased on usage analysis. We visualized different information needs in multi-dimensionalspace. Based on a cluster of similar documents representing an information need, wegenerated an XML document using natural language processing techniques to express theinformation need.

These results are encouraging. They show that latent semantic analysis can be applied to thetask of ascertaining information needs by monitoring the information retrieval habits of auser. In order to assess the actual "truth" of the XML document in representing the user'sinformation needs, we would need to have the user respond positively or negatively tosuggested relevant information provided autonomously by the information retrieval system.We have projects in progress to incorporate this feedback. In addition, we are working onmethods to incorporate reading time into the model of information needs and to predict theexpected 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 informationto the designer as others generate them. In addition, intelligent software agents might use theXML document as a guide to search document repositories for new, useful information. Themethodology may provide insight into the cognitive states of the designer over various stagesof design, offering a tool to study how changes in information needs relate to the designer'sunderstanding of the design problem. We are currently analysing the effect of time oninformation needs, particularly the rate of change of information needs. In addition, we areinvestigating learning the information needs of design teams by analysing teamcommunication. Our methodology presents a new means for learning information needsthrough a combination of LSA, natural language processing and a human-centred approachwhich places emphasis on understanding what it is that the user is doing.

ICED 01 - C586/422 25

5 References[1] Lowe, Alistair, McMahon, Chris, and Shah, Tulan, Culley, S., "A Method for The

Study of Information Use Profiles for Design Engineers," Proceedings of the 1999ASME Design Engineering Technical Conferences. September 12-15, 1999, Las Vegas,Nevada.

[2] Court, A.W., Culley, S.J., and McMahon, C. A., "The Influence of IT in New ProductDevelopment: Observations of an Empirical Study of the Access of Engineering DesignInformation, International Journal of Information Management, 17(5), 1997, p359-375.

[3] Dong, Andy and Agogino, Alice M., "Text analysis for constructing designrepresentations." Artificial Intelligence in Engineering. 11, 1997, p65-75.

[4] Rangan, R.M., and Fulton, R.E., "A data management strategy to control design andmanufacturing information." Journal of Engineering with Computers. 7, 1991, p63-78.

[5] Rezayat, M., "Knowledge-based product development using XML and KCs,"Computer-Aided Design. 32, 2000, 299-309.

[6] Ullman, David G., Dietterich, Thomas G., and Stauffer, Larry A., "A Model of theMechanical Design Process Based on Empirical Data", Artificial Intelligence inEngineering Design and Manufacturing. 2(1), 1988, p33-52.

[7] Williams, Ruth L., and Cothrel, Joseph, "Four smart ways to run online communities,"Sloan Management Review. 41(4), Summer 2000, p81-91.

[8] Wood, William H., Yang, Maria, et al., "Design information retrieval: improving accessto the informal side of design," Proceedings of the ASME Design EngineeringTechnical Conferences. 1998.

[9] Deerwester, Scott, Dumais, Susan T., Furnas, George W., Landauer, Thomas K., andHarshman, Richard, "Indexing by Latent Semantic Analysis," Journal Of The AmericanSociety For Information Science. September 1990, 41(6), p391-407.

[10] Learning Object Metadata, http://ltsc.ieee.org/doc/wgl2/LOMdoc2_4.doc.

[11] In Klahr, David and Kotovsky, Kenneth, (Eds.), Complex Information Processing: TheImpact of Herbert A. Simon, Lawrence Erlbaum Associates, Hillsdale, New Jersey,1989.

[12] Culley, Stephen J., Boston, Oliver P., and McMahon, Christopher A., "Suppliers in NewProduct Development: Their Information and Integration," Journal of EngineeringDesign, 10(1), 1999, 59-75.

[13] Cooper, William S., 1976, "The Paradoxical Role of Unexamined Documents in theEvaluation of Retrieval Effectiveness," Information Processing and Management, 12,367-375.

[14] Salton, Gerald and McGill, Michael J., 1983, Introduction to Modem InformationRetrieval, New York: McGraw-Hill Book Company.

Dr. Andy Dong, LecturerUniversity of California, Berkeley, Department of Mechanical Engineering, 5138 EtcheverryHall, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

DESIGN COMMUNICATION USING A VARIATION OF THE DESIGNSTRUCTURE MATRIX

J C Lockledge and F A Salustri

Keywords: concurrent engineering, automotive engineering, design information management,workflow management.

1 Introduction

As reported in earlier work[1], the authors have constructed a mechanism for structuringdesign communications at a leading American automobile maker using a variation of theDesign Structure Matrix (DSM). This paper provides a formal process to create similarmatrices and outlines a mechanism for keeping participants updated on the design status. Theoriginal work was carried out in collaboration with, and implemented at, a major Americanautomobile manufacturer. The new work reported herein is a prototype which has as yet to beimplemented 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 ofdesign processes, but they also introduce new complexities in terms of communicationsbetween team members and management of tasks carried out by the teams. This isparticularly true in major industries, like the automotive industry.

Thus, while modern design practices have improved the nature of the products beingdeveloped, they have also increased the administrative and management burden arising fromincreased complexity; what is gained in one respect can be easily lost in the other. Becausethese complexities are not product complexities but, rather, complexities of design anddesigning, they were not immediately recognized as important performance issues. Recently,however, more and more interest has been shown in North America to seek a deeperunderstanding of the complexities of modem design as they arise largely from these issues ofcommunications and task management. The authors are developing a means of managing thedesign process to ensure appropriate communication between design team members isfacilitated, that task management is streamlined, and that all this can be done without placingfurther burdens on the designers.

Different enterprises choose different strategies to achieve these goals. One leadingautomobile manufacturer chose the strategy of re-defining its design process. While the carmanufacturer currently designs world class engines, they felt a need to reduce their time tomarket. As part of this overall effort, they identified their engine design process as one forexamination and improvement.

The authors undertook to assist the company by developing a tool to help the company'sdesign engineers manage engine design information more efficiently and reduce the initialdesign 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 (conceptualdesign), and the day-to-day design process (design information flow). In particular, theauthors 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 thecomponents or systems for which they were responsible. The authors conducted interviewswith many DEs involved in engine design at the auto maker. Based on analysis of theseinterviews and background research into the company's practices, the authors concluded thata successful tool would have to be extremely flexible to respond to mid-program changes indesign priorities and objectives. The tool also had to be very simple to use so as not to burdenthe DEs further with extra work.

Our solution was a variation of Steward's Design Structure Matrix (DSM)[2]. The DSM waschosen for of its simplicity of presentation and of construction. It essentially allows designersto capture the relationships between structural elements, systems, subsystems, etc. of aproduct in an easily understood matrix form. Once in this form, various manipulations can beperformed on the matrix to discover features of the design, such a clusters of very highinteraction between product components. The analogy between simple matrix operations,which all engineers understand, and design information management make the DSM quite auseful tool.

The authors modified the DSM in two ways. First, we distinguished between the physicalcomponents of an automobile engine (listing them on one axis) from the functional systemsand subsystems of the engine (listing them on the other axis). Identifying interactions in themodified matrix now results in identifying the functional dependencies of the structuralcomponents. By linking structure and function in this way, the matrix was used to identifythe 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 thechange. This means that change information is more efficiently managed.

28 ICED 01 - C586/584

Table 1: Example Design Process Matrix (DPM)

Manufacturing

Process

Lubrication

Combustion

Cooling

PowerConversion

DeliveryReturn

IntakeExhaust

FuelDelivery

Chamber

X

c0

CO

X

X

X

8CD

X

X

X

X

X

X

TD

I

X

X

X

X

X

X

X

X

c'aH

1CO

>

X

X

X

X

X

X

CD

§o%ca

X

Con

nect

ing

Rod

X

X

X

Cra

nksh

aft

X

X

The second modification was to build a secondary matrix above the first one to coverinteractions between components and manufacturing processes. In this way, interactionsbetween components and the systems needed to manufacture them can be made explicit. Thisextends the chain of interactions all the way from the functional systems, through physicalcomponents, to fabrication. Any change to one can be propagated to only those stakeholdersin related aspects who need to know about the change.

The authors refer to the resulting matrix structure, as shown in Table 1: Example DesignProcess 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 interactionsshown by the DPM are indicative of causal relations between systems, components, andmanufacturing. For each of these, stakeholders can be identified. Therefore, the DPM is amodel of the interrelationships between tasks as well as a model of the required interactionsbetween stakeholders needed to carry out the design tasks.

The researched sketched above was received by the automaker and integrated into theiroverall technical process. However, it was empirical and derived largely from the particularcharacteristics of the automaker's enterprise and corporate structure. The authors believe thata generalization of the DPM to a broader category of design enterprise could be verybeneficial. In order to perform this generalization, a deeper understanding of the process ofDPM construction is needed. This paper lays the foundations for such a generalization.

2 Approach to Constructing the Matrix

The purpose of this process is to create a Design Structure Matrix analogue that can be usedfor automating communication in a complex design environment. This environment owes itsexistence to the design of a product (or group of products) that will be produced by theorganization. To warrant using this process, the product is expected to be complex enough tohave multiple functions and several components that must be manufactured.

As pointed out by Hubka and Eder3, the design intent (which are goals within specificconstraints) is met by a series of functional systems. Each system exists by being embodiedin one or more components (or more precisely organs). These components interact with eachother, producing the desired effects through their functional systems. Within an organizationindividuals or teams (although typically a single individual) are assigned responsibility forreleasing a component for production. As originally pointed out by Steward4, the underlyingcomponent interaction can therefore be used to model the required interaction of thoseresponsible for designing them.

This process allows an Engineering Manager to create a mechanism that takes advantage ofthese 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 whichcomponents define others. Rules for the construction of hierarchical, component DSMs hasbeen delineated by Sabbaghian[6] in his work with Boeing. He points out that in constructing aDSM that has components and sub-components, any interaction between sub-componentsfrom 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 Pistonthat causes the interaction with the Piston Assembly. Interactions between sub-componentsboth belonging to a single component do not affect the relationship of the component. Thiscan 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 notinfluence other components.

A hierarchical DSM permits a larger number of components to be addressed withoutoverwhelming those who are indicating the relationships. A hierarchical DSM is necessarybecause the larger number of components (and sub-components) allows finer granularity ofthe relationships, and the granularity of the dependencies affects how specific the messages tousers can be. It also affects the number of messages a user is likely to receive, since coursergranularity implies that all of the people involved in a component will receive information onchanges to any related component.

30 ICED 01 - C586/584

Table 2: Hierarchical Component DSM

Components

ConnectingRod

Valve TrainComponents

PistonAssembly

ExhaustValveIntakeValve

RockerArm

Piston

PistonRing

Con

nect

ing

Rod

Val

ve T

rain

Com

pone

nts

1 >-C fljX >

W

X

<U OII

X

<5 -J* C

!<

Pist

onA

ssem

bly

X

c

E

X

1 g>E"2

2.2 Constructing a System Based DSM

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

Table 3: Hierarchical System DSM

Systems

Lubrication

CoolingCombustion

DeliveryReturn

Air IntakeExhaustChamber

Lubr

icat

ion

t>

1

E2(2

§~Q

5

X

X

Com

bust

ion

Air

Inta

ke

3Jrw C

ham

ber

2.3 Constructing a Human Role to Component/System Mapping

In most design organizations, individuals are given final authority for releasing a component'sdesign. Since they are the only actors in the system that can affect the design, the systemmust interact with them, making them recipients of messages concerning design changes. Forthe system to do this, these roles must be identified and specified in the Role/ComponentMapping (RCM) and the Role/System Mapping (RSM). Identifying these roles (and/or theindividuals responsible for them) should be straight forward, as each of the sub-componentsmust have an individual responsible for releasing it. Assigning an individual to an entirecomponent implies that they are the responsible party for all of the sub-components. Theindividual assigned responsibility will then receive and need to respond to all of the messagesconcerning their sub-components.

Individuals may also be assigned to the systems. These functional systems are not usuallyviewed as "released parts" so that this position takes on a monitoring role. The personassigned this role would be responsible for keeping individual DE aware of the implicationsto 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 thefunctional systems and the components. It is constructed by assigning sub-components tofunctional systems. An assignment results from the system being embodied in the componentand thus both defining it and being defined by it.

ICED 01 - C586/584 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 customerservice. Concurrent engineering [7] discusses the need for these parties to be involved in thedesign process. During this step, individuals who should be aware of design changes, butwho may not be central to the process, are added to the matrix. Additional roles are added tothe 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 notrequired to respond to the changes unless they see an opportunity or problem.

3 Assisting Communication

These three matrices and two mappings are the starting point for the communication routingsystem. When a DE makes a change in their (sub-)component (which we'll call M) thesystem 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, andSsc 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 CMwho will need to be aware of this change. The change can also be routed through the RSM tothe monitors of the system in SM. The messages to DEs would contain a statement that M waschanging and which systems (Sc) would likely be affected both directly and indirectly (fromSsc).

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 arenot given hierarchically to conserve space. If a DE made a change in the Crankshaft, wewould know from Table 1 that the Lubrication Delivery System and Power Conversionsystems would be affected and that Manufacturing would like to be kept aware of anychanges.

32 ICED 01 -C586/584

Table 4: Example Component DSM (CDSM)

Component

PistonBlockHead

Valve TrainValve Cover

Connecting RodCrankshaft

co"«h

X

X

X

.*:8mX

X

X

T3ra03T

XX

XX

Val

ve T

rain

X

X

Val

ve C

over

XX

Con

nect

ing

Rod

X

X

Cra

nksh

aft

X

X

Turning our attention to Table 4 we can determine that the Crankshaft directly affects theBlock and Connecting Rods. By going back to Table 1 we see that these components sharethe Lubrication Delivery System and Power Conversion systems.

Further, by going to the SDSM (Table 5) we can find that the Lubrication Delivery systemalso interacts with the Lubrication Return system and that Power Conversion interacts withthe Combustion Chamber.

Table 5: Example System DSM (SDSM)

System

Lubrication

Combustion

Cooling

PowerConversion

Delivery

Return

IntakeExhaust

FuelDelivery

Chamber

Lubr

icat

ion

£•0)>

"o>Q

X

X

c3

"CDrr

X

Com

bust

ion

CD

aC

X

X

Exh

aust

X

X

£•>0>Q

'ffl13

LJ.

X

X

Cha

mbe

r

X

X

D>_C

"5oo

X

X

Pow

erC

onve

rsio

nX

We can now frame messages to the individuals in charge of the Block and the Connecting Rodthat would read:

A change was recently made in the Crankshaft:

<Text generated by the DE who was changing the Crankshaftwould appear here>

This may impact Lubrication Delivery and Power Conversion. Ifso, these could cause also impact the Lubrication Return and/or theCombustion Chamber. Please verify the impact of this change onyour 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 thedesign has changed and their attention may be required.

Work is underway to construct a Web based tool to coordinate the communication betweenDE. This tool will permit users to either log into a server to be made aware of the currentstatus of the design, or be sent daily emails that summarize the changes.

1CED 01- C586/584 33

4 Conclusion

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

References

[1] Lockledge, J.C. and Salustri, F.A., "Defining the engine design process", Journal of Engineering Design, 10,1999, pp. 109-124.

[2] Steward, D. (1981) System Analysis and Management: Structure, strategy and Design, 3, (New York,Perocelli).

[3] Hubka, V and Eder, E., "Engineering Design: General Procedural Model of Engineering Design", Heurista,Zurich, Switzerland, 1992.

[4] Steward, Donald V., "The Design Structure System: A Method for Managing the Design of ComplexSystems" 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 Paperno. 3690-94-MS, May 1994.

[6] Sabbaghian, N, Eppinger, S. and Murman, E, "Product Development Process Capture and Display UsingWeb-Based Technologies", Proceedings of the IEEE International Conference on Systems, Man, andCybernetics, Par 3 (of 5), pp. 2664-2669, Oct 11-14, 1998.

[7] Kusiak, Andrew, Engineering Design: Products, Processes, and Systems, Academic Pr, 1999.

Corresponding Author: Jeffrey C. LockledgeInstitution: Wayne State UniversityDepartment: Department of Industrial and Manufacturing

EngineeringAddress: Manufacturing Engineering Building,

4815 Fourth St.,Detroit, MI 48202

Phone: 313 577 3507Email: j_lockledge@wayne.edu

© IMechE 2001

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

1 Introduction

Concurrent engineering consists in fastening development time by executing in a parallelmode design, analysis, and industrial tasks while they were executed sequentially intraditional development methods. This results in a shortened time to market [7]. Automotiveindustry has applied successfully concurrent engineering to the most recent range of cars.However, concurrent engineering has not taken into account the dramatic evolution ininformation systems technology as the new WEB based tools allow to distribute and sharetechnical information through all partners involved in a project [2] [7]. This will lead to newdistributed organisations in design teams, to more innovative designs as design hypothesis canbe more quickly tested and validated by all actors at Project Wide level. For any designproblem, the best specialists from extended enterprises and partners can be appealed with fullaccess to authorised design data with adequate viewpoint. Those new organisations, namely"shared engineering" or "collaborative engineering", will be supported by new "ProductInformation Systems" that directly take benefits from the information technology and thepower of semantic support to information. Information technology must take into account alllegacy systems to ensure of continuous data and service access to users: amongst those legacysystems, calculus worksheets, previously developed pieces of software... Further, manyefforts 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]. Thosepieces 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. Thisknowledge must be accessible to all actors involved in the design process, must be executablein the available design software, and must be maintained by accredited staff.

This paper provides concepts for knowledge and information product sharing during theredesign. The second section describes what functional design and redesign are. The thirdsection is dedicated to the presentation of the knowledge management approach employed inthe study. The model is presented in section four. The fifth section details the web based toolthat have been used to support the methodology. In section six, the application case ispresented. Finally some conclusions and open issues conclude the paper.

ICED 01 - C586/021 35

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

MULTI - A TOOL AND A METHOD TO SUPPORT COLLABORATIVEFUNCTIONAL DESIGN

S Menand and M Tollenaere

2 Definition

2.1 Functional design

In practice, the product designer needs to know all the principle functions that the product hasto accomplish. Consequently, he has to think about either the technical functions andsolutions associated to its principle functions. These activities are called conceptual orfunctional design. They consist to design those technical solutions or to choice ones, whichalready exist, with the correct dimensioning. The functional design don't require anygeometric 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 beexecuted 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. Linkedto the fact that a function is often deployed on several parts of the product [9] which aredesigned by different actors, it is a co-operative activity. In fact, a function is defined by a setof parameters defined by different actors. The definition of these parameters could beconditioned by a lot of constraints, which come from other actors. These actors work on otherphysical 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 modelof the product life cycle. The first model supports the co-ordination between actors involvedin the functional design. The second model ensures that all product life cycle constraints aretaken into account during the design phase. For instance, the different life cycle situations of acar 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 ofcombined 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 cyclesituations. Hence, the product functions are virtually simulated in all their potential life cyclesituations.

2.2 The functional re-design

The functional re-design consists in the choice of the principle solutions among those that arealready designed and studied. After that, the goal of the designer is to find the correctdimensioning of the product parameters allowing the product functions to be realised with theperformances targets defined in the project requirements and according to the integrationconstraints. This "new product" also has to be integrated in its new environment taking intoaccount the new physical and functional environment constraints.

The main aim of the present study is to formalise the functional design to assist the designteam in its functional redesign tasks (also called repetitive tasks). The designer need toolsthat assist in repetitive tasks in order to obtain time for more innovative and creative tasks.

3 A knowledge management approach

The knowledge management consists in managing information, data, knowledge and know-how 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 areillustrated 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 knowledgeidentification, its capture (and the associated models), its re-use and its maintenance. It isapplicable in the design phase, which requires the use of some repetitive tasks stemming fromthe previous design of similar product or from the same range (redesign or routine design). Inthis study, for each capitalising cycle phase, some concepts are proposed. These concepts areleading to a generic methodology to help the designers to manage their knowledge in theircollaborative functional design. The first phase was developed in section 2.1. The followingsection is dedicated to the second phase. Phases three and four are presented in section 5.2.

4 A model to support the "volatile" concurrent engineering re-design

This section is dedicated to the presentation of a new model able to formalise respectively theshared 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 functioningaccording to the required objectives or performances. It must respect the integrationconstraints. The fact to formalise the functional design process and the product with theirfunctions view point help the designer to design with the efficient quality and the performanceat lower cost. Hence, with these models, the designer can reuse the knowledge and theinformation during its redesign activities.

4.1 A generic approach

Knowledge in functional design can be divided into three different levels. Each leveldescribes both the resulting product and the co-operative design process. A generic leveldescribes the nature of functional design. It is independent from any particular technology androutine of redesign problem. This level is embedded in a "meta model" which contains thedefinition of the following entities and their relationships: design parameters, features, parts,subassemblies, assemblies, lifecycle phases, functions, sub-functions, constraints betweenparameters, 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 specificdesign "domain model" like braking system, bearing system or steering system, etc. Thislevel contains the know-how to perform design in a specific technical domain. It help thedesigner to know how a function is usually materialised, which constraints must be taken intoaccount for a specific phase of the lifecycle, etc. Presently, this piece of knowledge is oftenwritten in a handbook that can be shared on the WEB. This level must have the ability toevolve when new technologies appear. This evolution must be under the control of anyresponsible actor.

The third level is a repository for the design problems and projects. It is called "projectsrepository" and contains the definition of the products that have been designed in a specificdomain. This level can be supported by a specific piece of software that assists the co-operating designers. It should be in accordance with the second level and can also contain theill-structured information (texts, CAD files, sketches. . . notes) that have not been formalisedyet. The ill-structured information must be captured during the design process. Indeed, for thecurrent project or in the future, these information can appear to be very useful for all thedesigners.

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 theirspecific pieces of knowledge (engineering tasks from process model, product model andassociated 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 thedistributed nature of the product model and the co-ordination between actors. In practice, theknowledge, 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 lifesituation of the product.

Product design, often "volatile", must be at least supported by two related models. A productmodel embedding the design problem alternatives and results, and a design process modelaiming at the capture of tasks, activities, roles and actors. The proposed generic methodologyis supported by generic models, which are studied in this section. The generic modelsrepresent knowledge at different levels. They describe the collaborative design process, theinformation flow between actors (design workflow), the shared product information(functional parameters) and the other shared knowledge (feed back to design, know howdescription, 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 ofthe representation such as diameter for a bolt, the capacity for a roller bearing, etc. Each partof the product is associated to an actor, which is responsible to give the information of "itspart" to others. The model of figure 2 represents the structure of the product.

Functional representation is crucial to represent the design reasoning and to supportknowledge. In the studied system, functions are represented in a classical breakdownrepresentation 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 toresist to the static efforts, etc. The project repository (third level) is represented by theinstance'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) whoexecutes the tasks, the input data and their origins (previous tasks), the output data and theirdestination (following tasks), the associated knowledge (user guides execution, « recipe »,formulae, advice, previous experiences. . .), the associated resources (software, tools. . .), theannotations (remarks), the constraints issued from the life cycle artefact (production,assembly, etc.) and the conditions of task executions (dependent of the previous choices). Theconstraints are taken into account in the design process. However, the actors working on aproduct life cycle phase can affect its constraints on the product parameters. For example, themanufacturing actor can impose the tube section value to use the existing broach. In thefuture, it will represent some different product view dependent to the actors who participate tothe 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 figure3 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 arerelations 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 thenext figure.

Figure 4. The instances association

5 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 accessknowledge and data with a dedicated and context dependant viewpoint. They can access to thetasks with their related knowledge, data and also its description issued from the implementeddesign process model (inputs, outputs, constraints. . .). The actors can access (if they wanteither a functional approach or a structural approach) and edit or modify the appropriateengineering product parameters. They can know the tasks they have to make (tasks push) withtheir associated data and knowledge (knowledge push) in order they execute all the projecttasks (edit the value of a parameter, make an operation. . .). The tasks are valid (send in theactor's agenda in order that he execute it) when all there inputs (parameters) are instantiatedby 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 interestingfor the designer. With this methodology, we plan that the designer will have the rightinformation at the right time (knowledge push) and could maintain and capitalise itsknowledge as one goes along. So, the actors can edit their feedback [3] to design for a task asone goes along (post it), update the knowledge on a task, update the life cycle constraint on atask 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 aboutthe knowledge base up-date to take into account the experiences notifications.

6 The case study : designing assisted steering systemsTo apply our methodology, to "instantiate" the models associated and to test our informationsystem, our background is the functional design of the assisted steering column (see theFigure 4). This functional design is repetitive because for each vehicle project, the designerhas to choice one technical solution among some feasible technical solutions "on shelves" andto dimension it. The goals are that the product ensure the new performance targets and can beintegrated in the new physical and functional vehicle environment. This application case aimto have the experiences returned of its use from the twelve designers involved in thefunctional design phase.

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

7 Conclusions and open issues

This paper has presented an approach to support knowledge management in co-operativefunctional design. This approach is based on the three levels of the model, each levelcapturing a piece of knowledge. At the higher level, the "meta-model" captures the nature offunctional co-operative design, while the "domain model" embeds the know-how for aspecific technical design domain. Finally, the "projects repository" stores the former andpresent design projects. This repository can be supported by a specific collaborative software,implementing some concepts of the domain model. An application of this approach ispresently in progress for the functional design process of assisted steering columns. At thisstage of our research, many issues remain opened: communication and consistency betweenthe levels rely on a top down approach, the domain knowledge using the concepts defined inthe meta-model, the projects repository storing objects in accordance with their definition inthe domain model. Some mechanisms have been defined to allow evolution of the uppermodels, 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 andtechniques of data mining might be useful to extract formal concepts from those large projectdatabases. These techniques could help evolution of the models in a bottom-up approach.

References

[1] Bernard, A., "Modele de produit et de processus", Proc. Universite d'automnePRIMECA - Nancy - oct 1999

[2] Bonnevault, C., Couffm, F. and Faure, J.M., "Modele de processus de gestiond'informations dans un environnement multi-concepteurs base sur une methode deworkflow", 3 erne congres international de genie industriel a montreal, Mai 1999

[3] Busby, J.S., "The neglect of feedback in engineering design organisation", designStudies, Vol. 19, N°l, January 1998

[4] Chapa Kasusky, B.C., "Outils et structures pour la cooperation formelle et informelledans un contexte de conception holonique", Thesis report of the Institut NationalPolytechnique de Grenoble, October 1997

[5] Ermine, J.L., "Les svstemes de connaissances". Paris Hermes, 1996

[6] Grunstein M. and al. "Livre blanc", report of the III A workshop in France, 1999

[7] Kusiak, A. and Wang, J., « Concurrent Engineering : Simplification of the designprocess », Proc. CAPE'91 : Integration Aspects. Bordeaux, 1991, p.297-304.

[8] Nomaguchi, Y., Tomiyama, T., and Yoshioka, M. : "Document-based Design ProcessKnowledge Management for Knowledge Intensive Engineering," in U. Cugini and M.Wozny (eds.): Proceedings of the Fourth IF1P Working Group 5.2 Workshop onKnowledge Intensive CAD, May 22-24, 2000, Parma, Universita degli Studi di Parma,Parma, Italy, (2000), pp. 163-185.

[9] Prasad, B., "Towards a computer-supported co-operative environment for concurrentengineering", Concurrent Engineering, Volume 5, Number 3, September 1997

[10] Sivaloganathan, S. and Evbuomwan, N.F.O., " Quality Function deployment - Thetechnique : state of the art and future directions", Concurrent Engineering. Volume 5,Number 2, June 1997

[11] Suh, N.P., <<Applications of Axiomatic Design», Integration of Process Knowledge intoDesign 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 InformationSystem - 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 (InstitutNational 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

INFORMATION FLOW IN ENGINEERING COMPANIES - PROBLEMSAND THEIR CAUSES

C M Eckert, P J Clarkson, and M K Stacey

Keywords: Design teams, design information management.

1 Introduction

Providing everybody with the right information at the right time is one of the greatestchallenges facing all organisations. This means providing relevant information and the rightamount of information - not too little, but also not too much, so that the receiver does not getswamped in information, unable to tell the important from the insignificant. This paper reportson observations of how failure to achieve appropriate information flow in large-scaleengineering design processes contributes to a variety of problems for designers and decision-makers. Our observations support the conclusion that large organisations need to support bothpersonal contact and informal channels, and thought-through mechanisms for informationtransmission between individuals and groups who usually have little personal contact.

2 Some characteristics of large-scale engineering design

Information management in large-scale engineering design is difficult and challenging for avariety of reasons. Diversity of channels. Information is exchanged among humans, betweenhumans and computer systems and written records, and increasingly between differentcomputer systems. CAD models and other documents often play important roles in structuringand coordinating product development activities [1]. Scale, Complex engineering products aredeveloped over several years in teams of dozens or even hundreds of people with verydifferent backgrounds and expertise, often working in different locations. For example thedesign of a passenger aircraft takes over 100,000 person-hours. Large organisations andcomplex teams almost inevitably have a complex managerial structure with hierarchies ineach field of expertise, and specific process management in addition to the business andfinancial management that all large organisations have. Engineering companies are usuallyembedded in a supply chain, and need to manage the interaction and information exchangebetween collaborating companies. They must often follow procedures requested by theircustomers while enforcing their own procedures on their own suppliers. Variety ofperspectives. Most design projects involve the collaboration of engineers from different fields,as well as scientists, mathematicians, computer programmers, product designers, CAD-engineers, draughtsmen, technicians and model builders. These different specialists all havetheir own sets of concepts for understanding the characteristics of designs, and their owns wayof thinking about problems - what Bucciarelli [2] terms object worlds. They have differentways to express ideas, and different skills for creating and interpreting diagrams and othervisual representations [see 1]. Communication between object worlds fails to convey thesender'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 thecreation of something new that has not previously existed - this involves a high degree ofuncertainty. Initially many aspects of the design are unknown and others are imprecise orprovisional. Often many blind avenues are pursued as the design develops. Communicatingincompleteness, imprecision and provisionality is an important part of team designing [3, see4, 5]. Tone and phrasing in conversation can convey uncertainty effectively [6], but sketchesand other visual representations carry such meta-information inadequately [7, 8]. Cost-benefitmismatches in communication through documents. Computer support for informationmanagement has been the subject of intensive research and is increasingly important inindustry, but so far the human computer interaction of most engineering support systems hasbeen treated as secondary to the functionality that they can offer. So recording informationbeyond that absolutely necessary requires too much effort; and the person responsible forrecording information is typically not the person who would benefit from the informationonce it is recorded. Moreover, communication through electronic and paper documents islimited by the expressive power of the available representations [cf 1, 8].

Designers are still reliant on human guides to the huge amount of information potentiallyrelevant to each design, especially for explanations of context. For instance March [9] foundin a study in Rolls Royce that designers gained 82% of their information from people theyknew and 9% from people they didn't know. Only 9% of all information gathered by hissubjects came from computers (3%), bookshelves (2%), filing cabinets (2%), desks (1%), ordrawing vaults (1%).

3 Methods

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

4 Perspectives on communication

In understanding communication in large-scale design processes, we need to balance andintegrate two contrasting perspectives: how individual human beings exchange information inparticular 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 howinformation is expressed and constructed from content and context [3, 2, 6, 1]. They seedesigns as generated in negotiation between human actors, where information is activelycommunicated and actively made sense of. Each individual's understanding of the designsituation is dynamic and unique, and is constructed largely through interaction with otherpeople 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, suchas a modification to a design, comprises obtaining the information needed and making senseof it. Making sense of what you see or are told has three aspects (that are inseparable inpractice) shown in Figure 1: interpreting this information from the form in which it isrepresented; integrating it into one's understanding of the situation by elaborating it andevaluating its quality with contextual knowledge; and inferring its implications for one's owntasks and responsibilities, and how to apply it. This necessarily involves learned interpretationskills, background knowledge and awareness of context, which are different for eachparticipant. A representation of design information might be incomplete, ambiguous orinconsistent, or obscure aspects of the design. Missing information must be filled in fromcontext, typically with conventional assumptions or default values, which might or might notbe right for the problem. If the recipient realises that the information is incomplete orinadequate, he or she will try to find the missing or correct information, either by going backto 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 sociologicalinsights into individual designing episodes can give us. We need to understand how manydifferent activities fit together to create a design. Taking an information-centred perspectiveallows us to consider how designing activities are structured by the design itself (as well asrequirements and constraints it must meet) and by the social organisation of the designers andtheir environment. However, information flow isn't smooth or infallible or confined to formalchannels, or even deliberate communication; it is often chaotic and cannot entirely bepredicted. In engineering design, a great deal of information is usually communicated throughthe 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 andplaces [see 1]. CAD models, drawings and formal documents are seldom produced to conveyspecific points. Often they carry more information than needs to be communicated at aparticular time. Much information is transmitted through the customary organisationalcommunication patterns, for example distribution lists, between people with particularorganisational roles. Designers also become aware of information that they are not activelyseeking through the activities of their colleagues.

In taking an information flow perspective, this paper concentrates on communication betweenthe members of a large team designing a complex product, who cannot all meet frequently orsolve problems by interactive negotiation (see [11] for a discussion of differentcommunication situations). Even when designers can meet and discuss, they may beresponsible 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 mucheasier 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 bothinfeasible and unnecessary for guiding the management of design communication. What isneeded instead is understanding what information and expertise should inform joint designing.

5 Manifestations of communication breakdown

The following list does not present a complete picture of possible failures of informationtransmission. Instead it describes manifestations of inadequate information flow that havebeen 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 theprocess by which it is generated. The designers in our study had a localised knowledge of theproduct and the process, but had very little understanding of other aspect even on a very highlevel. For example the aerospace designers had only the most cursory understanding of therole avionics played in the overall craft. Of course, complex products are decomposed as faras is possible into modules with relatively simple interactions, to minimise the complexity ofthe design process. But lack of awareness of interactions between components of designs andbetween design processes results in a number of problems, when designers don't know whatinformation 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 therequirements of other designers and therefore failed to do tasks. Often they knew aboutbig tasks, but small seemingly insignificant tasks can have a huge impact on the designprocess if they are not done in time, for example ordering a vital component for aprototype.

2. Lack of awareness of information history. Team members often don't know whereitems of information such as specifications and parameter values come from. Inconsequence they can't trace them back the designers who are responsible for them, and socan't question the information. If the designers need to change previous decisions such asparameter values, they don't know who has based their decisions on this value andtherefore would need to change their own areas of the design. Tracking information isespecially difficult across organisational barriers.

46 1CED 01 - C586/219

3. Lack of awareness of how information is applied. Team members often don't know howtheir contribution fits into the overall process. They don't know who depends on theinformation that they are creating, nor how they use the information. In consequencedesigners often don't provide their colleagues with all the information they need to have,especially about what decisions are provisional, or the boundaries within whichparameters can be changed [see 5].

4. Lack of awareness of changes to processes. Design processes are often changed becausenew requirements are added, or scheduled tasks have failed and need to be repeated orreplaced with more complex procedures. News of process changes is often not passed onto members of the design team, so that they don't re-plan their own activities, or do tasksthat 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 howtheir information has been used by colleagues. In consequence they can't identify failingsin 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 theinformation that they receive; for example if a parameter value is a final value or a simpleestimate, or if an element of a sketch is an important and carefully thought-throughelement of the design or merely a placeholder there to make other elements of the sketchcomprehensible [see 4, 7]. People therefore often assume that values are exact and putgreat effort into meeting a seemingly exact target. In our study of knitwear design [7,8] wefound that technicians often ignored parts of garment specifications because they couldnot assess which aspects they should rely on.

7. Power structure excludes viewpoints. Contractors and suppliers are often excluded fromdecision-making processes, because they have no official standing in the companyhierarchy or because the information discussed in meetings is considered confidential. Yettheir tasks depend on decisions made in these meetings; moreover the success of theproduct might depend on the decisions made in these meetings drawing on their expertiseand addressing their concerns.

8. Information is consciously withheld. Contractors or suppliers are consciously not giveninformation that might be useful for their tasks, because it is considered confidential.Information can also be withheld when the provider of the information does notunderstand why the information is required or believes the recipient has no authority toknow. Henderson [1, p. 65] was often not given technical information as a technicalwriter, because engineers and administrators could not see why she needed to know (shereceived 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 itreaches the recipient. The generator of the information may not know the ultimate recipientsat all, or does not know the recipients' needs, tasks and background, so can do little to ensureaccurate transmission.

1CED 01 - C586/219 47

9. Information is oversimplified. Due to the sheer volume of information concerning aparticular design, complex information often needs to be simplified or abstracted to becommunicated clearly. However different team members may have different criteria forwhat information is relevant [see 1, p. 157], so significant details and qualifications can beleft out.

10. Chinese Whispers. Information that is passed on through other people is likely to bedistorted. Unless everybody knows the context, the details or emphases are likely to bechanged. This applies in particular to information passed on orally.

11. Hierarchical Communication Paths. In many companies, communication betweenexperts of the same speciality in different teams is passed on along hierarchical paths. Anindividual engineer alerts his group leader, who passes information on to his boss outsidethe 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 nohorizontal communication between people solving similar problems. Each person selectsinformation 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 thetechnical knowledge to understand the implications of the information, or to argue thecase for a particular technical solution. An extreme example is that project presentations tothe board of directors or to clients are often made by managers or finance experts withvery little technical understanding.

5.4 Interpretation of representation

The representations designers use to express design ideas and other information, and therepresentation-understanding skills they possess, have a powerful influence on designcommunication [see 3, 1, 4, 7]. The following two points are taken from observational studiesand 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 oftenpresented ambiguously or can be interpreted in more then one way. (Note that any level ofabstraction can be fleshed out in different ways, without having being representedambiguously.) The recipients interpret this information based on their own experience andcontext, 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 moreeffective than others. And many representations of designs make some aspects of thedesign explicit and hide others. Information can be obscured by the representation, forinstance when parameter values have to be inferred rather than read directly. Arepresentation can be vague or ambiguous to someone lacking its creator's diagram-understanding skills [1], or be incomplete when its creator thinks it is complete.

6 Factors contributing to communication breakdown

Communication problems are seldom monocausal. Communication breakdowns can resultfrom a combination of several problems; so resolving one issue in isolation may beinsufficient. For instance, our study of the knitwear design process found a communicationbottleneck 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 keyissues are the difficulty of creating consistent and unambiguous representations cost-effectively, 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 andexpertise think with) is always potentially problematic. In our study in the aerospace industrywe found that mapping problems are amplified the further the other object world was awayfrom the designers' own experience. For example the stress engineers and mechanicalengineers 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 personalconnections and informal communication. People who have once worked together, forexample for the same past employers, talk to each other. People moving between departmentsoften create links between those departments; for example if a load expert is moved to thestress department, he will think about the load implications of his stress analysis. Suppliers areoften a conduit of information between competitor companies. Contractors move betweendifferent companies in the same industry; while they are bound by confidentiality, theytransfer 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 thesame site will always be easier than between different locations, though technologysupporting remote meetings with shared workspaces is proving effective in commercial use.

7 Conclusions

Communication can fail at every stage shown in the figure. Many problems simply arise frominformation 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 inferencesfrom the information that they are given. Our studies highlight the importance of minimisingdistortion, by ensuring so far as possible that information is conveyed by people who fullyunderstand it, and that information can be traced back to its sources. They reinforce the well-recognised finding that one key to effective knowledge management is enabling the peoplewho have the knowledge to talk to each other.

Ensuring the accurate and timely delivery of appropriate information is a less tractableproblem. In complex processes information flow is always problematic and difficult tosupport. Only if designers know where information is coming from and where it needs to gocan they communicate effectively. We are working on tools for planning and managingdynamic design processes [12] based on the parameter values exchanged between tasks, anddeveloping visualisation techniques for design process that make these dependencies andconnections salient [13].

Ackowledgements

This research was funded by the EPSRC Rolling Grant to the Cambridge Engineering DesignCentre. We are grateful to our informants for the time and trouble they took talking to us.

1CED 01 - C586/219 49

References

[1] Henderson, K., "On line and on paper", The MIT Press, Cambridge, MA, 1999.

[2] Bucciarelli, L.L., "Designing Engineers", The MIT Press, Cambridge, MA, 1994.

[3] Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies oiGroup Engineering Design Practice", PhD Thesis, Department of MechanicalEngineering, Stanford University, 1991. Xerox PARC report SSL-91-22.

[4] Stacey, M.K. and Eckert, C.M., "Against Ambiguity", Computer Supported CooperativeWork, in press.

[5] Stacey, M.K. and Eckert, C.M., "Managing Uncertainty in Design Communication",Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001.

[6] Brereton, M.F., Cannon, D.M., Mabogunje, A. and Leifer, L.J., "Collaboration inDesign 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.

[7] Stacey, M.K., Eckert, C.M. and McFadzean, I, "Sketch Interpretation in DesignCommunication", Proceedings of ICED'99, Technical University of Munich, Munich,Germany, vol. 2, pp. 923-928, 1999.

[8] Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis andComputing Solutions", Computer Supported Cooperative Work. 2001.

[9] Marsh, J.R., "The capture and utilisation of design experience in engineering design",PhD Thesis, Department of Engineering, University of Cambridge, 1997.

[10] Eckert, C.M., Zanker, W. and Clarkson, P.J., "Aspects of a better understanding ofchanges", 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 tosupporting human decision making in design", Proceedings of the ASME 20thComputers 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 ProcessPlanning," Proceedings of the IEEE Conference on Information Visualization. London,2000, pp.155-154.

Dr Claudia Eckert and Dr P John Clarkson Dr Martin StaceyEngineering Design Centre Department of ComputerDepartment of Engineering and Information SciencesUniversity of Cambridge De Montfort UniversityTrumpington Street Kents HillCambridge CB2 1PZ Milton Keynes MK7 6HP, UKPhone: 0044 1223 332758 Phone: +44 1908 834936Fax: 0044 1223 332662 Fax: 0044 1908 834948Email: {cme26,pjc10}@eng.cam.ac.uk Email: mstacey@dmu.ac.uk

© IMechE 2001

50 1CED 01 - C586/219

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

DESIGN CASE RELEVANCE IN QUANTITY DIMENSION SPACE FORCASE-BASED DESIGN AID

T Murakami, J Shimamura, and N Nakajima

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

1 Introduction

Nowadays, designers must consider an increasing number of issues such as product liabilityand environmental friendliness as well as functionality and performance of artifacts.Supporting such complicated design processes by compiling design knowledge andinformation and making use of them is becoming more important. There are two approachesto such design aid: one is to prepare a general building block library or knowledge base fordesign problems (e.g., [1]), and the other is to store past designs and extract valid knowledgeand information for new design problems case by case. For the latter approach, we havestudied a computerized retrieval of kinematic designs to possibly achieve a required behaviorusing 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 case-based design aid. First, quantity dimension space is defined to characterize various designsand design-related terms using relevant physical quantities. Then similarity and relevancebetween various designs and terms is defined in the space. By applying the proposed methodto 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 producethe phenomena are determined. Therefore, many concepts used in design processes arerelevant to (physical) quantities. When designing a hydraulic cylinder, for example, weshould consider and calculate quantities such as the "force" to be generated, "pressure" offluid and "area" of the cylinder as in Figure 1 (The design case "hydraulic cylinder" in Figure1 is described hierarchically by containing sub design cases such as "cylinder tube innerdiameter" 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" asin 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 becharacterized 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 dimensionspace. 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 amathematical space, which we call "quantity dimension space". A unit dimension of aquantity is a nine dimensional vector in this space: [length mass time electric-currentthermodynamic-temperature amouni-of-substance luminous-intensity plane-angle solid-angle}. 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 ofquantities as explained before, it can be represented as a cluster of vectors in the quantitydimension 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 thisrepresentation, design-related concepts with similar physical quantities share some vectorsand make similar and overlapping clusters, whereas concepts with different physicalquantities share few vectors and make different or separate clusters. Therefore, we canmathematically define similarity between concepts by defining distance and similaritybetween 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 multipleaxes closer than the difference about a single axis (e.g., Euclidean distance between N andN/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, dq(qi qj)= dq(qj, qi).

Similarly to vi, we introduce an appearance vector ai. If a fundamental unit appears inquantity 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 theunit 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 00], 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. Herewe 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 distancedecreases similarity to 0.

The scalar product of appearance vectors ai and aj in the right-hand of the definition has thefollowing 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) inFigure 4 are orthogonal and thus their scalar product is 0.

- However, if some common fundamental units appear in the two quantity definitions, thevalue is not 0 even when two vectors are right-angled. For example, vectors vi and V2 inFigure 4 are right-angled but the scalar product of their appearance vectors is not 0 becausea1 and a2 share time and length.

- Even when two vectors vi and vj are dimensionless, the value is higher when the originalquantity definitions are more similar because appearance vectors ai and aj hold theinformation.

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 usingsimilarity sq between two quantities, we define similarity sc of cluster ca to cluster c/, asfollows. For each quantity <?, in cluster ca , we calculate similarity between that and quantityqj 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 asphysical quantity clusters, and calculate similarities in the quantity dimension space in anobject-oriented Lisp [4]. Design cases can be defined hierarchically as in Figure 1. A casecan be either a detailed description containing all calculation sequence as in Figure 1 or just acollection of characteristic physical quantities obtained as a product specification informationfrom catalogs. In our implementation, a design case is considered to have all physicalquantities in its sub cases, in other words, a physical quantity cluster representing a designcase contains all physical quantity clusters representing its sub design cases.

Although we calculate a "similarity" of physical quantity clusters representing design casesand 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 childcases. Part of which are listed as follows.

(d2) "digital Roentgen"(d3) "dyeing and finish process using super high pressure"(d4) "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"

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 showsthe sorted result. Electricity-related design cases generally exhibited higher scores; thesecomparisons 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) "hydrauliccylinder" and (d2) "digital Roentgen", were calculated. Figure 6 shows the sorted result.

Pressure-related design cases generally exhibited higher scores; these judgments can be usedfor 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 termsgenerally exhibited higher scores; these comparisons can be used to make a dictionary ofsynonyms.

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 acomponent technique to achieve such design aid. By extending and combining the proposedidea to conventional keyword-based searches, this approach should provide an effectivemethod 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 containkeywords by some strings as well as physical quantities in Figures 1 and 2. Now we areworking 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 amongquantities are not considered. In actual design cases, however, there are structures amongphysical quantities such as calculations (in a design of a hydraulic cylinder for example, tubethickness is calculated from pressure). By representing such structures as networks amongquantities and taking them into account, we can probably define more precise and accuratesimilarity between design cases and terms.

In some studies on case-based design aid (e.g., [5]), attribute names and their values (typicallyimplemented 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 efficientreasoning when the domain is rather fixed (for example, architectural design) and the slotnames can be unambiguous enough as keys for reasoning. On the other hand, the motivationof our study is to establish a method to cover wider range of engineering design usingphysical phenomena. The reason we came up with the idea of quantity dimension space isthat any physical quantity in the past, present and future design problems can be objectivelyand unambiguously compared with nine fundamental units even when the name or keywordsassigned to the quantity may be subjective, ambiguous and different by persons or technicaldomains. Of course, a method using physical quantity alone should have problems of poordescriptive power and inefficient reasoning. To find a good combination of the idea in thispaper 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 wasproposed, and similarity between design cases and design-related terms were mathematicallydefined in the space. The similarity calculation results for several examples of design casesand terms show that the quantitatively calculated similarities seem making sense in general.Our next directions include verifying that our mathematically defined similarity matchesdesigners' comprehension quantitatively and constructing a design aid technique based on themethods in this paper.

This work is partly supported by "Modeling of Synthesis" project (JSPS-RFTF 9600701) inthe "Science of Synthesis" research field of the Research for the Future Program, JapanSociety for the Promotion of Science.

References

[1] Umeda, Y., Ishii, M., et al., "Supporting Conceptual Design Based on the Function-Behavior-State Modeler", Artificial Intelligence for Engineering Design. Analysis andManufacturing. Vol.10, No.4, 1996, pp.275-288.

[2] Murakami, T. and Nakajima, N., "Mechanism Concept Retrieval Using ConfigurationSpace", Research in Engineering Design. Vol.9, No.2, 1997, pp.99-111.

[3] Gruber, T.R. and Olsen, G.R., "An Ontology for Engineering Mathematics", FourthInternational Conference on Principles of Knowledge Representation and Reasoning.Morgan Kaufmann, 1994.

[4] Matsui, T. and Kara, I, EusLisp version 8.00 Reference Manual Featuring Multithreadand XToolKit. ETL-TR-95-2, Electrotechnical Laboratory, Agency of IndustrialScience and Technology, 1995.

[5] Maher, M.L. and Garza, A.G., "Developing Case-Based Reasoning for StructuralDesign". IEEE Expert. Vol. 11. No.3. 1996, pp.42-52.

Tamotsu MurakamiDepartment 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

A WEB-BASED INFORMATION TOOL FOR APPLICATIONENGINEERING

J Schmidt and D G Feldmann

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

1 Introduction

Nowadays increased global competition forces companies to intensify and structure theinformation flow between the departments and enterprises to be successful on the market withits grown technological and economical challenges in product development. Time to marketdecreases; development time can be substantially shortened by introducing innovativecommunication and information tools, which enable the project teams to work on the basis ofa common development platform. Particularly the early phases of product development offer alarge 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 ofpossible 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 affectsthe product quality.

The Institute for Mechanical Engineering Design of the Technical University Hamburg-Harburg is developing a product model based tool for application engineering of hydrostaticsystems, which supports the early stages of product design. To guarantee that all employees ofthe company have access to product data and design knowledge via Intranet the tool is WEB-based. Increased data processing support especially in the early stages of product developmentrequires computer-supported acquisition of the task which is offered by the tool. Additionallydifferent modules support the solution identification process by supplying design experienceand giving access to realized solutions. Circuit diagram creation, selection of components,system simulation, error estimation and 3D-layout of the hydrostatic system are alsosupported by the tool. Central component of the engineering tool is a product model, definedespecially for hydrostatic systems, in which all product specific analysis and synthesis dataare stored. The design of the hydrostatic system, thus the filling of the current product modelwith information, takes place with help of IT-tools, which support the several stages ofproduct design, following the "VDI guideline 2221" [1].

ICED 01 - C586/147 59

2 The structure of the Application Engineering Tool

The widely hardware independent client-server-architecture of the tool allows distributedproject teams to develop several new products at the same time; thereby the designers alwayshave access to a current base of product data. The design construction and experience whichis 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 ofseveral closed and platform-dependent tools such as text processing systems, programs forspread-sheet analysis, CAD systems and simulation programs. The variety of program-specific and thus usually not compatible data formats represents a weak point; there is nocentral data management implemented, whereby redundancies and inconsistencies in the datapool 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 forall planning and design phases is due to missing or only insufficiently operating interfaces notpossible. Especially the missing computer supply in the early phases of product developmentis a considerable weak point of the conventional product development process. There are notools available for a systematical entry and evaluation of the task, that often leads toincomplete and unstructured tasks. Considerable delays in the later stages are the result, thatoften causes iteration cycles, which increases time to market.

With the following concept of a WEB-based application engineering tool for hydrostaticsystems a constant computer support of all planning and design phases becomes possible. Theengineering tool supports the systematic solution search by supplying design experience anddesign 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 storedin a "static" area of the data base. For circuit diagram generation and simulation of thesolution concepts a commercial simulation tool is connected to the IT-tool by an interface. Aspecific 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. Fourinterlaced modules for information input, information storage, information extraction andvisualization form together the structure of the engineering tool. With consideration of theheterogeneous information of the planning and design phases, separate IT-tools have beendeveloped, which support data processing and storage in the respective development stage.The product model, which is specific for each product, enables the structuring and centralstorage of the information.

The product model contains the entire information to a product. During the developmentprocess quantity and quality (accuracy and completeness) of information in the product modelgrow. If a project is in its final stage, i.e. an optimal solution concept has been identified, theproject manager finishes the development process. Thereupon the system modifiesautomatically the access rights for the current product model. From this point in time theproduct model is fixed and represents new design experience, available for following projectsand development stages. Only the project manager or one of his assigned coworkers can makesubsequent modification of "fixed" product models, which may be necessary to correct faultsor optimize the design as a result of application experience; in such a case they have to use thedesign 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. Accessto 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 developmentprocess a uniform user interface was implemented. WEB-browser are used to visualize the IT-tools, these user interfaces are available in each modern enterprise as a standard. The concept-conditioned client-server-architecture allows a distributed and parallel operating in thecompany-wide Intranet and guaranties, that inconsistencies and redundancies in the data baseare avoided.

For user acceptance data security is important. Here must be differentiated between world-wide and enterprise-spreading information exchange in the Internet and local data transfer inthe Intranet of the company. The compliance of safety requirements at the enterprise-internalIntranet can be ensured by password-controlled access rights; that however presupposes thatno connection to the Internet exist. If there is a demand to access over the enterpriseboundaries beyond Internet, far more complex safety mechanisms are necessary. At presentthese usually server-lateral mechanisms offer still no total protection from abuse byunauthorized persons. That concerns in the long run the entire area of e-Business, whydevelopers of WEB-browsers and servers do a lot to increase data security. The developedengineering tool uses the currently available safety mechanisms of browsers and servers.

3 The computer supported process of product development

To explain the functionality of the Application Engineering Tool in the following all planningand design phases are (exemplarily) passed. The engineering process for a hydrostatic systembegins 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 evaluationand 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 putdown either by a customer or by a department of the company. The first requirements on thenew product are typically incomplete and unstructured and they are documented in form ofdiscussion logs, simple CAD documents or also handwritten tables, sketches and diagrams. Inthis early phase the computer support of the engineering tool begins; all documents are storedvia digitization in a database, i.e. in a new product model. For a first structuring the collectedinformation is divided into request classes. According to standard the classes technicalrequests, economic requests and organizational requests are predefined at the engineeringtool. The coworkers of a project group are informed about task modifications automaticallyby 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 problemscaused 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. Bothphases will be gone through in an iterative process until a sufficiently structured and completetask definition can be formulated; the release of the task definition is usually made intuitivelyby the project manager. The use of the design tool shortens this process and ensures astructured formulation of the problem, based on product functions. The representation of thetechnical requirements by product functions has the advantage that it does not limit the set ofsolutions in advance by the determination of components. The review of the task definitionconcerning completeness is made easier by the functional description of requirements and canbe to a high extend carried out automatically by the engineering tool.

The simplified presentation of the Functional Product Structure (FPS) shown infigure 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 productfunctions that have been defined within the frame-work of previous projects. The groups arepredefined for the first deployment of the design tool and will be adapted and extendedaccording 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 withinthe frame-work of the problem description to the product functions necessary for theperformance. If for example a linear output is requested as a part of a new system, the projectdesigner firstly calls up the class of output in the Functional Product Structure and limits thepossible number of product functions by selecting the necessary main function, here supplytranslational motion. The project designer is now provided with the next range of functions inthe functional hierarchy. Five steps are needed as a rule to reach the level of basic functionsthat make it possible to completely describe the requirements. Each function is so describedby a set of clearly defined and product-independent attributes and characteristics.

Should it not be possible during the task clarification to indicate specifications for allattributes 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 completelycleared product functions are automatically summed up in a report and can then be discussedwith the customer or the concerned departments. The project task is only released by thesystem, when all product functions are finally cleared or the yet unknown features are markedas "to be cleared" upon authorisation of the project manager. If none of the systems existingproduct functions is able to describe the task, it is possible to define a new function with itscharacteristics and attributes. In order to ensure the consistence of the Functional ProductStructure and the integrated data structure a number of further entries - omitted here - have tobe 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 fromprevious projects. The design experience that is stored in the models of previous projects canbe extracted through search patterns defined by the customer requirement specification (at thistime already structured), which will identify correspondences and similarities of new productmodels with stored product models of previous projects. The search patterns structuredaccordingly 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 developedsystems that needs only to be fine tuned according to the current problem definition. As aresult of the search the project designer is supplied with a catalogue of preceding projects withsimilar models which can be used as a basis for new concepts. The search results are rangedaccording to the priorities of the requirements of the task definition by weighing the searchparameters in the search patterns of the different requirement groups. The suitability ofpreceding projects for new developments is defined by establishing a limit value ofconformity. The basis for the step from concept to realization is the Function-/ FunctionCarrier Matrix. The matrix is product-independent and represents the connection between theFunctional Product Structure and the Function-Carriers, defined as a mathematical andgeometric description of real hydrostatic components. Function-Carriers can be singlecomponents 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 diagramgeneration as well as the technical system data required for the optimization of controlengineering. The symbols and the parameters needed for the simulation correspond to thesimulating program connected with the tool. A function carrier can perform more than onefunction of the FPS and the other way round one and the same function can be performed bydifferent function carriers. The Application Engineering Tool provides the project group witha requirement-specific Function-/ Function Carrier Matrix for solution finding, where everyrequired product function is assigned to all known workable function carrier; every newproject enlarges the scope of the Function-/ Function-Carrier Matrix. By choice and bycombining different Function-Carriers various solutions are generated.

The engineering tool must not hinder creativity by working with or offering only knownsolutions; 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 incommon product development the creativity of the project designer is of great importance; theengineering tool encourages creativity since it offers all Function-Carriers known to thecompany for each required product function together with an explanation of their pros andcons. The constantly methodical approach and the subject-related access to the basis ofdecision-making in preceding project developments also promote the optimization of thedevelopment process.

3.4 The simulation, choice of components and evaluation

The examination of the performance of the developed concepts is carried out with an existingcommercial program that is able to generate circuit diagrams as well as to simulate the staticand dynamic system performance. This program is an integrated part of the engineering toolin the way that the project designer is provided with a concept-specific library of componentson the user-surface of the simulating program. These libraries contain all of the Function-Carriers respectively their hydrostatic symbols needed to describe the concept developedwithin the frame-work of the design; the symbols are combined in groups analogue to theFunctional Product Structure, thereby a clear allocation of the symbols in the circuit diagramof the hydrostatic system becomes possible. In order to generate the circuit diagrams and forthe simulation the internal functions of the simulating program are used. A detaileddescription of the software would go beyond the scope of this paper. A condition for anautomatic choice of devices is the disposability of the technical specifications of the usedhydrostatic components in a digital form; such as technical data sheets, operating instructionsand geometrical descriptions in the form of 3D-CAD-models. The experiences gained fromprevious projects with these components are stored in the data base and can be taken intoconsideration. The allocations of the component data to the Function-Carrier deduced fromthe task definition is carried out automatically on the basis of the product-independentFunction-/ Function-Carrier Matrix; apart from the local component data there is thepossibility in principle to use electronic component libraries in the internet, although thiswould presuppose a standardized and company-independent language of description that hasnot yet been defined for the fluid technology. The evaluation of the system conceptconcerning 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 methodcame into use as a method of evaluation. This method stands out due to its easy handling andclarity. As a result of the assessment a priority of possible product concepts is provided andthe optimal product concept can be chosen.

64 1CED 01 - C586/147

4 The realization of the Application Engineering Tool

After the data structure and the flow of information had been deduced in the form of ER-models from the concept of the engineering tool, the main emphasis of the project work wasthe predefinition of the actual data bank structure, i.e. the definition of the relations, theirentries and keys. The used relational data base can be divided into a product-independentstatic part and in a product-specific dynamic part; the product model that clearly describesevery product concept is member of the dynamic part of the data base. Through data bankinquiries views on the internal sections of the product model are opened that enable theproject designer to be informed via internet/intranet about the state of the project orrespectively to further develop the project through the input program. The interface betweenuser 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 systemvia interactive forms, i.e. http-inquiries are sent to the web-server; e.g. a http-inquiry containsa html-form from the project designer that contacts the data base in order to store the data. Acommercially available interpreter (CF-server) was installed between the web-server and thedata base since a common web-server is not able to interpret a html-source coding withintegrated data base inquiries. The investigations for the development of an internet-basedinformation 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; theillustration should give an impression of the arrangement of the user-interface of theengineering tool. Apart from forms like this, tools such as charts, graphics and trees will beused to visualize and acquire information; tools for the construction of state-diagrams or forthe 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

5 Summary and Conclusions

As a result of the computer-supported project design with the here presented tool an optimaldesign of a hydrostatic system is available considering the evaluation criteria. From thehydrostatic and control engineering point of view, this design contains an optimal hydrostaticcircuit with its components assigned to the parameters of available devices. All informationthat is handled or produced in the course of project design is stored in the product model ofthe system for the product development of future products. Next to the basic primary taskdefinition of the customer and its changes, the Functional Product Structure, the concepts, theresults of the simulations, the circuit diagrams and lists of parts as well as all decisions andcomments of the concerned project group is documented. Since the number of available andcompletely filled product models increases with the run time of the IT-tool, a growing supplyof experience can be used for the development of new products. Commercial programs will betied in for the design of the circuit diagrams and the simulations. The design tool is based on aclient-server-architecture that supports simultaneous engineering on one hand and allows thecontrol of "workflow" on the other.

The further development of the design tool will provide tools for the geometrical design of thehydrostatic systems specified in the product concept. The aim is to make statements aboutpossible collisions between devices or dimensioning errors in the project design stage of theproduct, using a 3D-geometrical model. With the help of a so-called assembly model theproject designer can arrange early remedial measures, like selecting different devices, in thecase of inconsistencies on a new or modified construction. The hydrostatic devices areassigned simplified geometrical models in order to keep the amount of geometric data low forthe assembly research. The assembly model of the hydrostatic system consisting of these"configuration models" of components is composed out of simple geometries like cuboids andcylinders. Only the functional surfaces and volume units important for the assembly and thedimension rating of these simple geometries are completely worked out, e.g. the position forholes, casing surfaces or the fastening threads important for assembly.

References

[1] VDI-Richtlinie 2221. "Methodik zum Entwickeln und Konstruieren technischerSysteme und Produkte", VDI-Verlag, Diisseldorf 1986

[2] VDI-Richtlinie 2225. "Konstruktionsmethodik, Technisch-wirtschaftliche Bewertung",Blatt 3, VDI-Verlag, Dusseldorf 1990

[3] Stritzke, H. Intemetgestiitztes Informations- und Kommunikationssystem fur verteilteProjektteams am Beispiel der Produktentstehung. Dissertation. Fortschrittsberichte VDIReihe 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 428782296, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

AN AGENT ENVIRONMENT TO SUPPORT CO-ORDINATION BETWEENDESIGN ACTORS

P Girard and C Merlo

Keywords: Design information management, knowledge acquisition, knowledge management,product data management, collaborative design.

1 Introduction

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

2 GRAI approach in engineering design

Considering the expansion of co-operative design, involving numerous and heterogeneousteams, the GRAI approach proposes a model of the design system with the aim of improvingthe performance of product engineering design. The GRAI reference model describes theengineering system (figure 1) as two subsystems: the decisional system and the technologicalsystem. These two systems converse through a third one, the informational system. Thedecisional system co-ordinates and synchronises the technological system which transformsinformation 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 differentlevels of granularity, and on the basis of a functional criteria defining product or projectoriented decisions. The decisional system is divided into local decision centres according tothis fractal decomposition. Each of them controls a design centre in the technological systemwhich transforms specific requirements into product and route sheet definition [4]. Forexample at a strategic level, a design centre can be in charge of analysing the requirements topropose a decomposition of a design project into several steps, and at an operational level adesign 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 orderto send back information to the decisional centres and to facilitate the control and the co-ordination of design. The informational flows of design centres are formalised using a productmodel and a process model: the product model is based on a functional description, includingalso 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 amulti-spindle machine tool the function "to bind completely" is related to two technologicalentities TE: "Drilling machine interface" and "Pinion". For this function the TE are specifiedby boundary entities: an axis and a point to define their relative position. The process modelarchives the activities of the design centres and at each activity is associated a state epk of theproduct model. The analysis of design knowledge in the design system shows the needs ofcommunication and co-operation between the actors, the flexibility of their organisation andthe needs of capitalisation. These conclusions led us to apply multi-agent concepts to themodelling of the informational system, in order to improve design co-ordination [6].

3 Knowledge modelling

The set of agents defined in the multi-agent system (figure 2) compose an assistanceenvironment for the design actors, In the technological system, actors use informationformalised in the product and process models. The product and process agents are in charge ofstoring, controlling and distributing this information in an active way, to improve the co-operation of the actors in a local design centre. The product agent uses a translation agent todisplay product information with a representation adapted to each design actor. Acommunication agent is assigned to each actor to shape, in an adapted form, the input-outputinformation. 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 designknowledge 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 theirenvironment. We will show their contribution to the engineering design co-ordination.

4 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 theactor context,

non public information from an actor must be evaluated to prepare future integration withproduct model,

- public information (in work or released) must be quickly communicated to concernedactors, 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 therelated tasks, such as the control of the syntax of product information. But they will controlthe 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 productinformation in the area of the co-ordination of the related tasks led by the actors in thetechnological system. So they have to:

- answer to "check out" requests from an agent (an actor most of the time), using ifnecessary a translation agent, and respecting product model formalism,

- answer to "check in" requests from an agreed agent, in order to modify or to increaseproduct 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 agentsguarantee the coherence and the integrity of the product information. For this, agent tasksconsist of controlling information, establishing dialogues with actors and distributing relevantinformation to obtain a coherent state of product information. Each agent is assigned to anactor. The actors are assigned to a design centre, so product agents are organised intoequivalent groups to perform their tasks. A supervisor agent controls their activities in thearea of the design centre and a global supervisor controls their activities in the area of eachproduct. Second, product agents communicate with other agents to support design actors forthe management of design knowledge. They decide to co-operate with translation agents tovisualise information of the product model and with communication agents to exchange withactors. They are requested by process agents to validate a specific state epk+1 of productinformation and by capitalisation agents to extract information about product, In thedecisional system product agents support actors making their decisions by extractinginformation from the product model. They are requested by capitalisation agents to accessspecific 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-agentsystem, on the following definitions from [7]: the system contains a set of objects O; thesystem 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 uponobjects (and agents); operators Ok represent the effects of the operations upon theenvironment of the agents. These definitions led us to develop a mathematical description ofthe agents, we propose a graphical representation (figure 3) which is a transition between themathematical 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 theirenvironment, 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 thevisualisation 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, definingtheir access rights.

For the visualisation requests, the following two operations represent the actions that theproduct agent has upon its related actor, and upon a translation agent if necessary:

For the modification requests, we define the operation Oppj representing the control actionsthat the product agent decides to execute, and the operator Okpi happening after the positiveend 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 toestablish a formalised architecture in order to adapt a methodology to the needs of the globalsystem and to respect quality rules: standardised process of development, more structuredprocess, easier maintenance, components replaceable, ... We propose that the internalarchitecture 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 fromother agents, and the relations R identifying the links with them) and the mechanisms Mto maintain this knowledge,

the "self model" centralises the information about its own identity N, S and F. The agentcan send it to be known by other agents,

the "task model" defines all the basic actions of the agent, these actions are mechanismsM which are combined to obtain external actions Op and Ok,

the "processing model" analyses the received information to define an appropriate strategyby combining basic tasks. This model contains the mechanisms M used for actions. Thismodel and the task model allow the agent to act on its environment or to react.

5 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, ahierarchical organisation and the possibility to locate agents through a network. The casestudy is restricted to the control tasks that the product agent manages in order to guaranteeproduct information coherence between actors. We simulate first a visualisation request andthen 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 calledBEM composed of three actors (Durand, Renard and Cunier), this centre is controlled by adecision centre called DCM. BEM actors co-operate to produce new states of productknowledge. 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 alist of elements (functions, technological and boundary entities) that are added, modified ordeleted by one actor at a time. We define three status types for each element to trace themodifications: not valid, valid (if the element depends on a valid state) or in work (proposedstate). The objectives of the prototype are to test the product agent during the control phase ofthe modifications of product knowledge proposed by one actor from BEM.

We define ApDurand = ("product agent", "Durand", "controlling the evolution of productinformation in a co-operative context", "173.20.20.19", "BEM", list of mechanisms). At thebeginning of the simulation, Durand sends a visualisation request on the product model.Consequently ApDurand reacts and explores the product database to satisfy Durandrequirements 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 designsystem (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 towhich Durand belongs, the centres to which belongs the owners of each element, the rightspreviously associated to the element, and the rights linked to the objectives given by thedecision centre DCM controlling the design centre of the actor BEM (ApDurand uses acommunication task 4 to know these objectives). These rules are deduced from GRAIconcepts and are based on relations such as: Rp(ApDurand , Cunier ) = { Cunier, design centreof Cunier, IP address of Apcunier }. The resulting operation is: Opp (ApDurand , Durand ) = {task1, 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 controlof the modifications to co-ordinate the information inside and outside the design centre. Firstit has to identify (task 5) all the elements added, modified or deleted since ep1, and all theelements linked with these elements according product model rules. Then for each elementidentified, it has to determine the actor(s) concerned by the modifications and the level ofneeded 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 informationabout the proposed modifications and it defines communication tasks 7. Relations are thesame 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 ApDmandand the product agents of Cunier and Renard.

After task 7, ApDurand sends a "check in" request to the product database. This task 8 definesthe 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 relatedactor and an other actor, according to the organisation of design and decision centres. The setof tasks (task 1 to 8) is a part of the mechanisms M of the product agent. These tasks implythat the product agent will keep external information in the environment model (currentorganisation), or in the processing model (objectives, results of control or informationmessages for example). As translation agents are not implemented yet, the operations Opp t donot exist.

As a conclusion, the prototype simulates the co-ordination of the evolution of productknowledge through the use of an agent for each actor from BEM, DCM and BMM. Theagents can be launched on a single PC and also on different PCs over a network. Our aim is toachieve the complete description of agents using a neutral platform, and to validate the added-value of agents for the application of GRAI concepts in engineering design co-ordination.

6 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 objectivesand interests to assist actors in engineering design co-ordination. We formalise amathematical definition and an architecture of product agent.

The implementation validates part of product agent actions and needs to be improved. Wemust extend its abilities in order to allow the agent having a more adaptive behaviour duringcontrol actions and being less dependant from actors. We will apply this work to all agents inthe informational system and define a complete environment to engineering design assistance.

References

[1] Doumeingts, G., Ducq, Y., "Enterprise modelling techniques to improve efficiency ofenterprises", in Production Planning and Control. Taylor & Francis Publishers, Volume12, Issue 2, 2001, pp.146-163

[2] Duffy, A.H.B., Andreasen, M.M. and O'Donnell F.J., "Design Co-ordination", Proc.ICED '99. Munich, Germany, August 24-26, 1999

[3] Merlo, C. and Girard, P., "Knowledge Modelling in Engineering Design Control",IDMME'2000. Montreal, Canada, May 16-19, 2000

[4] Girard, P., Eynard, B. and Doumeingts, G. "Proposal to control the systems designprocess: application to manufactured products", in Integrated Design and Manufacturingin Mechanical Engineering: IDMME'98. edited by J.L.Batoz, P.Chedmail, G.Cognetand C.Fortin, Kluwer Academic Publishers, ISBN 0-7923-6024-9, 1999, pp.537-544

[5] Eynard, B., Girard, P. and Doumeingts, G., "Control of engineering processes throughintegration of design activities and product knowledge", in Integration of ProcessKnowledge into Design Support Systems, edited by H.Kals and F.van Houten, KluwerAcademic Publishers, ISBN 0-7923-5655-1, 1999, pp.351-360

[6] Jennings, N.R., Sycara, K. and Wooldridge, M., "A roadmap of Agent Research andDevelopment", Autonomous Agents and Multi-Agents Systems. 1, Kluwer AcademicPublishers, Boston, 1998, pp.275-306

[7] Ferber, J., "Les svstemes multi-agents - Vers une intelligence collective". InterEditionsHA, Paris (1997)

[8] Glaser, N., Haton, M.-C. and Haton, J.-P., "Models and knowledge acquisition cyclesfor multi-agent systems". Proceedings of 9th KAW, Banff, Canada, 1995, pp.24/0-24/20

[9] Bensaid, N. and Mathieu, P., "A Hybrid and Hierarchical Multi-Agent ArchitectureModel", Proceedings of the Second International Conference and Exhibition on thePractical Application of Intelligent Agents and Multi-Agent Technology: PAAM'97.London, UK, The Practical Application Company Ltd, 1997, pp.145-155

Dr. Philippe GIRARD1 and Engineer / PhD student, Christophe MERLO1,2

1 Laboratoire d'Automatique et de Productique, Groupe GRAI, Universite Bordeaux 1-351cours 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.fr2 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

DEVELOPING A SUPPORT SYSTEM FOR NOVICE DESIGNERS ININDUSTRY

S Ahmed and K M Wallace

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

1 Introduction

Recent studies suggest that designers rely heavily on their memory and experience whentackling design tasks [1, 2, 3]. However, how they apply their experience and knowledge isnot understood and further research in this area is required. In addition, the aerospaceindustry, along with other industries, has recognised the need to capture 'experience'. In orderto capture experience, the nature and use of design experience within the aerospace industryneeds to be more clearly understood.

This paper describes the results of a study of novice and experienced designers undertaken inthe aerospace industry; the research approach and research issues; a method of support fornovices designers; the preliminary evaluation of the method; and the trial implementation ofthe method in the aerospace industry.

2 Experience: current understanding

The long-term aim of this research is to provide a method of support for novice designers. Inorder to understand how to provide this support, it is important to understand how novice andexperienced designers design. Very little is known about this, as most studies have focused onthe time spent on external activities, e.g. task clarification and generating concepts [5], ratherthan focusing on problem solving activities [4]. Too few studies have been carried out, andthose that have been have had differing aims. Hence, the findings are difficult to relate to oneanother. 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 theill-defined area of design is poorly understood, and hence the applicability of these findings todesign is not fully understood [6, 7]. The main findings relevant to novice and experienceddesigners in design (these findings were also applicable to well-defined problem areas) can besummarised as:

• Novice designers were found to have a tendency to reason backwards and to use adeductive approach. Experienced designers tended to reason forwards, and, when solvingmore 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, intheir early stages of development. The design tools reviewed did not support designers withthe provision of design strategies based upon a cognitive model. In addition, methods or toolsthat assist novice designers to gain experience faster were not found.

The review highlighted the need for further research to understand how designers carry outdesign work and to identify the differences between how novice and experience designersapproach design tasks. This understanding could then provide the basis of a tool or method tosupport designers and, in particular, to support novice designers.

3 Research Approach

Empirical research in the aerospace industry was carried out to understand the differencesbetween how novice and experienced designers approach design tasks. Three differentresearch approaches were employed: (1) observations and post-observation interviews; (2)discourse analyses; and (3) interviews. The research was data driven and the findings fromeach study influenced the direction of subsequent studies. All the studies were audio-recordedand no method of analysis was set up prior to the studies. The transcripts were used to createcategories that summarised the designers' activities, including their thoughts and actions. Theresearch method employed for each of the studies is described briefly below:

• During the observations, the designers were asked to think aloud whilst carrying outdesign work. The designers worked on their own task to ensure that it was of a suitablecomplexity 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 gainan understanding of the background of the designer and the task.

• The discourse analyses consisted of pairs of novice designers interviewing experienceddesigners without the presence of a researcher. The aim of the interviews was to elicitknowledge 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 companyculture.

When planning the empirical research, the following issues relating to empirical studies inindustry were considered:

• To keep the amount of time involved for participants at a reasonable level to ensure thesupport and co-operation of busy designers.

• To respect the commercial sensitivity of the aerospace industry. The use of videorecorders 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. thework schedule of the participating designers. There were often delays in arrangingobservations, interviews or evaluations as a result of trying to accommodate the designerswork schedule. These issues added considerably to the time involved in data collection andanalysis. However, the difficulties involved in carrying out research within industry were faroutweighed by the benefits. The results were more relevant to industry and more easilytransferred. The total time for data collection and analysis during this research amounted to1325 hours (or 165 days) and is broken down in Table 1. Each of the three studies contributedin their own way towards identifying differences between novice and experienced designers.

• The observations provided an understanding of how novice and experienced designersapproached design tasks.

• The discourse analyses provided an opportunity to analyse the interactions of novice andexperienced designers without the presence of a researcher. The discourses were used tounderstand 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. Inaddition, they provided an insight into the company and a broad view of the designprojects undertaken by the designers. The interviews were useful for identifying thecategories of experienced designer behaviour (as identified from the observations) that theexperienced designers were aware of.

Table 1. Breakdown of time spent on data collection and analysis

Study

ObservationsDiscourseanalysesInterviewsEvaluationTotal

No. of hoursspent

616374

1202151325

No. of daysspent

7747

1527165

No. of participants

Novice

68

0620

Experienced

68

6626

3.1 Participants

In total, 34 engineering designers from five different teams in Rolls-Royce pic participated inthe 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 withmany years of experience as experienced designers. It was not assumed that an experienceddesigner was necessarily a good designer: no attempt was made to assess the quality of anydesign work. Experience is thought to contribute to being a good designer, but once aparticular level of experience has been reached other factors become more important [8]. Theperiod necessary to become experienced, defined as having attained an international level, infields such as chess playing, arts, sports and sciences, is thought to be 10 years [9, 10, 11 in12]. 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 thelevel of experience required to be good designers. The novice designers would still benefitfrom support that would help them gain experience more rapidly. The research aims tounderstand the differences in how novice and experienced designers approach design taskswithin 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 ofrelevant industrial experience and were not assessed on their design skills. The experienceddesigners involved with the research had worked an average of 19.5 years in the aerospaceindustry and the novice designers an average of 1.5 years.

4 Findings

The findings from the three studies conducted identified differences in how novice andexperienced 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 ofthe main findings for each of the studies is presented in the following paragraphs (a moredetailed description can be found in [13]).

The observations of designers found that novice designers used a particular pattern of trialand error when designing. The novice designers only evaluated decisions after they had beenimplemented. Experienced designers carried out a preliminary evaluation stage allowing themto evaluate decisions prior to their implementation and, hence, avoiding the use of the novicetrial and error pattern. The observations identified eight strategies that experienced designersadopted that allowed them to avoid this process. Novice designers had not developed suchstrategies and were found to be unaware of these strategies. However, the most experienced ofthe 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 tothe 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 ofadditional information; the query was rephrased or declared irrelevant; a combination ofthese. In total 633 queries were analysed. The analysis revealed that novice designers wereaware of what they needed to know in only 35% of all queries. Novice designers were foundto be aware of what they needed to know in queries regarding topics such as domainknowledge, but not about design strategies employed by experienced designers, suggestingthat they were unaware of them. 10% of all the queries were rephrased or stated as irrelevantby the experienced designer. 29% of all queries were statements which indicated that thenovice designers were aware of the topic that they needed to know about, but they did notknow how to phrase their questions. In response to 16% of all queries, the experienceddesigners offered additional information to that required simply to answer the queries. Thesefindings suggest that novice designers require support in identifying what they need to know.

The interviews and the post-observation interviews supported the findings from theobservations and found that the experienced designers interviewed were aware of experienceddesigner behaviour in five out of the eight categories identified as design strategies. Theexperienced designers did not mention all of the categories of experienced designer behaviourthat was identified from the observations. This suggests that the categories not mentionedmight be described as the tacit knowledge possessed by experienced designers. Without theuse of observations as a research method, these categories of experienced designer behaviourwould 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 wererelevant; and were aware of what questions to ask to resolve issues.

The observations, discourses and interviews all indicated, not surprisingly, that experienceddesigners had greater knowledge of how the engine functions, that they questioned data andconsidered issues. The results from the discourses revealed that novice designers are often notaware of what they need to know. The findings suggest that novice designers require supportto formulate design strategies and that supporting novice designers by simply supplyinginformation is not enough, as they also need to be aware of what they need to know and howto phrase appropriate questions.

5 C-QuARK METHOD

A method of support named C-QuARK has been developed based upon the findings (refer toFigure 1). The method aims to prompt experienced designer behaviour by informing novicedesigners of what they need to know through the provision of generic questions. Thesequestions were derived for each of the eight categories identified as design strategiesemployed by experienced designers during the observations. C-QuARK links these designstrategies based upon how experienced designers were observed to move from one activity toanother. The arrows in Figure 1 represent these links and the direction of the arrows havebeen determined by the observations. The basic difference between C-QuARK and an expertsystem is that it provides novice designers with questions rather than answers. It thereforedoes not rely heavily on captured knowledge. C-QuARK is intended to support novicedesigners 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 thelikelihood 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 graduatesrecently recruited to the company. The affect of the method on the graduates is beingevaluated and compared to those who are unaware of the method. The initial reaction to themethod was found to be positive. The novice designers using the method were observed toincrease their use of design strategies, such as consider issues, in comparison to the designersthat 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. Eachwebpage is linked using the links identified from the observations and, hence, prompts thenovice designers to move from one category to another in the same way as experienceddesigners. Information in the intranet is captured and structured using C-QuARK. As C-QuARK is based upon how experienced designers were observed to design it should thereforebe a natural way to obtain information for experienced designers. Although capturing asignificant amount of information into the intranet will take time, the intranet should be ofimmediate benefit by simply supplying novice designers with the right questions and theavailability of examples.

6 Evaluation of C-QuARK

A preliminary evaluation of the proposed method has been carried out, involving a further 12designers. A novice designer was observed using C-QuARK to carry out a design task and anexperienced designer acted as the knowledge source, answering any questions. The aim of theevaluation was to identify inappropriate questions or links and identify any areas the methodhad missed. The evaluation identified missing links between categories, but no major areaswere found to be missing. The evaluation results were useful in refining the categories. Theevaluation validated the method and found no inappropriate categories or links. It was alsouseful in refining the categories. Two additional links between activities were found that werenot identified from the observations. These two links need to be investigated further tounderstand if C-QuARK should be modified to include them.

The initial reaction of both novice and experienced designers to the method was found to bepositive. The use of C-QuARK reduced the number of inappropriate questions asked bynovice designers by around seven percent in comparison to those during the discourseanalyses. The evaluation suggests that the novice designers found three of the categories moredifficult to use than the other five. This indicates that the way these categories are explainedto novice designers needs to be reviewed.

7 Conclusions

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

80 ICED 01 - C586/259

ICED 01 -C586/259 81

Figure 1. The C-QuARK method

8 Acknowledgements

The authors acknowledge the support for this research from the Engineering and PhysicalSciences Research Council (EPRSC) and from Rolls-Royce plc.

References

[1] Court, A., "The Modeling and Classification of Information for EngineeringDesigners". Ph.D.. University of Bath. 1995.

[2] Marsh, J.R., "The Capture and Utilisation of Experience in Engineering Design". Ph.D.,Cambridge University, 1997.

[3] Rodgers, P.A., "Capture and Retrieval of Design Information: An Investigation into theInformation Needs of British Telecom Designers", Cambridge University, CUED/C-EDC/TR5, 1997.

[4] Eisentraut, R., "Styles of Problem Solving and their Influence on the Design Process."Design Studies. 20, 1999, pp. 431-437.

[5] Fricke, G., (1999). "Successful Approaches in Dealing with Differently Precise DesignProblems." Design Studies. 20, 417-429.

[6] Ericsson, K. A., and Charness, N., "Cognitive and Development Factors in ExpertPerformance." Expertise in Context, AAAI Press, California, 1997, pp. 3-41.

[7] Zeitz, C. M., "Some Concrete Advantages of Abstraction: How Experts'Representations Facilitate Reasoning." Expertise in Context. AAAI Press, California,1997, pp. 43-65.

[8] Sonnentag, S., "Expertise in Professional Software Design: A Process Study." Journalof Applied Psychology. 83(5), 1998, pp. 702-715.

[9] Simon, H. A., and Chase, W. G., "Skill in Chess." American Scientist. 61. 1973, pp.394-403.

[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 Differencesbetween Novice and Experienced Designers". Proc. Engineering Design ConferenceEDC2000. London, 2000, pp. 97-106.

[14] Weinert, S., "Learning to Ask the Right Questions: Evaluation of a Program to Improvethe Acquisition of Knowledge in the Design Industry," Masters thesis, TechnicalUniversity 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:/Avww-edc. eng. cam. ac. uk/people/sa233. html

© Cambridge Engineering Design Centre 2001

82 ICED 01 - C586/259

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

USING DOMAIN KNOWLEDGE TO SUPPORT DESIGN REQUIREMENTSELICITATION

M J Darlington, S J Culley, and S Potter

Keywords: Structure of requirements, requirements elicitation, conceptual maps.

1 Introduction

This paper introduces a novel design requirements elicitalion method that is domain-knowledge based. The method combines a simple knowledge-representation formalism and aninterpretation scheme, implemented in a prototype design requirements elicitation system.

Development of this approach has been carried out for three purposes. Firstly, to provide abasis for a requirements elicitation tool that might be used to capture and generate designrequirements for manual or automatic configuration design. Second, to allow the idea ofassociation - implemented in a simple 'concept-chaining' mechanism - to be explored as ameans of embodying constraining domain-limited knowledge in a system. Third, to provide avehicle 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 anddifficult part of the design process [1]. This importance is well illustrated in a number ofcases, where incorrect, incomplete or ambiguous expression of the design requirement hasbeen shown to occur, leading to design of artefacts that are unsafe, unsatisfactory, uneconomicor inappropriate [2,3,4].

The task of capturing and expressing the design requirement acquires an extra dimension inthe 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 andthe 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 growingnumber of commercial software tools, of which DOORS [6] is representative. These helpmanage the process of requirements capture, definition, maintenance and revision. However,the work reported in this paper looks principally not at the methodology of the requirementsdevelopment 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.

2 Identifying the tasks for developing an elicitation scheme

Investigating the expression of the design requirement involves consideration of, amongstother 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 aboutthe concepts, and the language content.

3. The nature of design requirement capture and generation episodes in the real world. Thisincludes such things as essential elements, its evolutionary character, limitations, etc.

4. Methods of structuring the expression and elicitation process, to improve on the ad hoccommunication of the design need.

In addition, effective design requirement expression is dependent on overcoming the problemsidentified in the Authors' earlier work [7] which are a consequence of the nature and power ofhuman 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 Requirementelicitation scheme. First is the identification of the vocabulary for use in talking about thedesign need; second is a method for implementation that will allow guided elaboration of adesign requirement in a controlled way, using the specified vocabulary, through interaction ofthe user and the computer. Thus there are two key issues, which must be dealt with, and in thefollowing order:

1. What to represent

• the concepts that are needed to think and talk about the domain.

• the words needed to label these concepts.

2. The means of representation

• 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.

3 Concepts, content & associations

The above discussion identifies three key elements which are fundamental to providing aframework 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 thecontext of this research work on controlling the expression of requirements, concept will beused according to the following definition.

A concept is a collection of ideas about a separable (abstract) component of the worlddesignated 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) thatmake up wheel. By being a separable component of the world, the concept is demonstratingthat the referent in the world to which it refers is demonstrating a perceivable regularity thatmakes it stand out and be recognizable from one encounter to another. Importantly, thissuggests 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 eachindividual. Communication between individuals is possible just because common experienceassigns overlapping meaning to a referent in the real world, which by agreement is given alabel. The label is used as the common term for the referent, and is the means by whichcommunication 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 beenlimited in the first instance to consideration of an application-neutral verbal language and toone that is appropriate to discussing the motion of a machine. Restricting the area ofinvestigation limits the complexity of the language content, and is made on the presumptionthat 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 mediumalone 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 conventionaldesign. It may turn out to be equally true for eliciting and presenting data for input intoautomated 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 basicactivities 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 interms of the function (the purpose) of the machine and in terms of the action of themachine.

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 generativenature of English).

5. The set of concepts invoked when describing the function or actions is restricted or, atleast, 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 areconstrained 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. Conceptassociation 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 ofappropriateness based on meaning. For a given situation, the conceptual space is disposed insuch a way as to have a focus point situated where the meanings central to the situation areclustered. For a full discussion of concepts see [8].

4 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 onlywhere the mechanism has been pre-specified. However, if contextual constraint can beprovided in humans by an implicit network of concepts, then why should it not be provided tosome extent in a decision-support tool by making the network explicit, by pre-defining theconcepts and their interdependent relationships? This would allow the behaviour of the systemto be constrained, and fix the context for the interaction between it and the human operator. Itis recognized here that some concepts are private. Thus, in making the concepts explicit itwould be presupposed that only those that were readily labelled (and hence shareable) wouldbe available and useful.

4.1 Representing the concepts as a structure

The above discussion clearly identifies for representation, shareable concepts - which will beidentified by labels - and associations or relations between the concepts. The method chosenhere for representing concepts and associations is a simple graph, consisting of nodes(representing the concepts/labels) and arcs representing a direct relation. The relations adoptedbetween 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 thelogical relations: AND, OR and XOR. For example, AND implies that all child concepts arelogically 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 specificationwhich constitutes the domain knowledge for the domain to be considered.

5 Developing the domain specification

The first domain to be mapped for exploratory purposes is that of machine motion. Thegeneral 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 developedin 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. Additionalwords have been adopted as seemed appropriate in order to increase the richness of theexpression. In addition the existing general lexical ontology WordNet [9] has been used as aprincipal source of words and definitions for this specialist lexicon. In particular, WordNetwas used as a means of eliminating synonyms. Development of the lexicon was carried outitcratively 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 isdescribed using a number of graphs, although, in principle, a single graph might be used. Eachgraph 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 afunction that the embryonic design requirement is expressed. Requirements described in termsof 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 XORrelations (hatched lines).

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

ICED01-C586/519 87

6 Implementation issues

In order for the conceptual structures discussed above to be operationalized, an algorithm hasbeen developed to interpret the data expressed as a domain specification and implemented in aprototype 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 isimplemented for numerical and text values to be associated with specific concepts. Thisallows the system (the designer) to prompt the user (the customer) to provide these valueswhen appropriate, and for these values to be output together with the design requirementconcept structure. Together these provide what can be thought of as a Design RequirementRecord. From this record can be extracted those elements that are useful in a given context asthe Design Requirement itself.

7 A computer-supported design requirement elicitation episode

The initialised system can be thought of as taking the part of the designer, about to embark ona information-gathering episode. At this stage the current knowledge consists of the generalknowledge about the domain, but none about any specific episode. The process that ensuescan be seen as one of progressively — by inference and by eliciting user-input — eliminatingfrom consideration irrelevant elements of the closed domain.

The episode is initiated by the system prompting the user to enter a 'key concept': theprincipal functional requirement that the user desires to be satisfied by the design. Thiscorresponds 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. Thisrepresents episode-specific knowledge. The system now looks for the next most closelyrelated concept to the one selected. This is activated and placed in the concept list. Thisprocess is repeated. At each stage the current knowledge - the domain knowledge and thegrowing episode-specific knowledge - is searched, which allows inferences about the nextnearest concept to be considered. The chaining process continues until the choices presentedto the system cannot be reconciled using the current knowledge slate (in which case it promptsthe user to provide the information necessary to continue) or until all concepts that might beappropriate to the current episode have been activated (in which case the elicitation episode isat 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 inthe form of a set of concepts, ordered in a relational hierarchy. In addition, numerical ortextual data, associated with particular concepts, are attached. This constitutes the full design

ICED01-C586/51988

requirement record, which can be modified or augmented manually to form the designrequirement. A fragment of a record and the resulting design requirement is shown in Fig. 2.

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.

8 Results

The test domain specification contains 207 concepts. Taken across ten test cases, the averagenumber of concepts chosen in an episode is 61% of the 207 concept labels in the domainspecification. This is the proportion of the total domain that has been chosen as beingappropriate to the episode. Of these, the average percentage of concepts chosen by the systemwithout intervention from the user is 69%. The remaining 31% are those selected by the userfrom choices presented by the system. Of these an average of 27.5% are presented forselection together with one or more alternative, because the choice is dependent on userpreference rather than on knowledge-based inference - the system simply cannot make adecision. The remaining 3.5% are 'blind' concepts. These are those concepts that, given thedomain knowledge, might be expected to be known by the system as being appropriate foractivation, 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 linearnature of the algorithm used for navigating the domain knowledge.

The content of the domain specification is a representation of the way in which the originatorof the specification apprehends and organizes the concepts relating to the domain. Theimplementation allows the content to be explored and refined by increasing the descriptivepower of the domain specification. Provided that the content is a self-consistent and effectivereflection 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 domainspecification that has the structure and completeness necessary for elicitation and generationof a design requirement that can be used to drive a design, either conventionally or throughautomation. To this extent the system has been shown to be useful.

ICED01-C586/519 89

Motion Requirementsmovement

rotationreorientation

tippingmax_angle: 90 deg

mannerintermittent

sporadicrotate_speed:

variableset_speeds

minspeed: 1 deg/smaxspeed: 5 deg/s

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

9 Conclusion

The generation of a basic requirement is the starting point for all design activity. This work isconcerned with supporting this generation process.

Initial tests suggest that the straightforward concept association method chosen provides aprincipled method for constraining dialogue in a design requirement elicitation mechanism. Indoing so, such things as ambiguity, contradiction, incompleteness and redundancy can beginto be controlled. In addition, the implemented mechanism provides a useful tool forexploration of a number of aspects of design requirement elicitation, including the conceptualcontent of a design domain.

References

[1] Wootton, A.B., Cooper, R. and Bruce, M. "Requirements Capture: where the front endbegins?", Proc. ICED '97, Tampere, vol 1, 75-80.

[2] Smith, P.G and Reinertsen, D.G., "Developing Products in Half the Time", VanNostrand Reinhold, N.Y., 1995.

[3] Ullman, D. G., "The Mechanical Design Process" (2nd ed.), Reston Publishing, Reston,VA., 1997

[4] Hales, C., "Managing Engineering Design". Longman Scientific and Technical, Harlow,England, 1993.

[5] Clausing D., "Total Quality Development". ASME Press New York, 1994.

[61 DOORS. Quality Systems & Software, Inc; URL: http://www.qss.co.uk.

[7] Darlington, M. J. and Potter, S.E.,, "Engineering Design Requirements Formalization:the development of a constrained natural language and an elicitation scheme formalizingaspects of the design requirement". Internal Report No. 041/98, Engineering DesignCentre in Fluid Power Systems, University of Bath, 1998.

[8] Sowa, J.F., "Conceptual Structures: Information processing in mind and Machine".Addison-Wesley Publishing Co., Reading, MA, 1984,

[9] Miller, G. A., Beckwith, R., Fellbaum, C., Gross, D. and Miller, K.J., "Introduction toWordNet: an on-line lexical database", International Journal of Lexicography, 3 (4),1990, pp. 235 - 244. ftp://ftp.cogsci.princeton.edu/pub/wordnet/5papers.ps.

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

© IMechE 2001

90 ICED 01 - C586/519

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

TOWARDS PRAGMATIC APPROACHES FOR KNOWLEDGEMANAGEMENT IN ENGINEERING - THEORY AND INDUSTRIAL

APPLICATIONS

K-D Thoben, F Weber, and M Wunram

Keywords: Knowledge management, KM, pragmatic, methods.

1 Introduction

Corporate knowledge is nowadays well accepted as a decisive asset in most Europeanenterprises. The know-how and expertise of the work-force is an important factor for thesuccess of companies and strongly influences the effectiveness and efficiency of the businessprocesses and their outcome. The concept of Knowledge Management (KM) receives highstrategic attention across multiple sectors. In the engineering area, KM is specifically relevantdue to the knowledge intensive character of the domain. The new product developmentprocess, which is an innovative and a non-repetitive process par se, is especially interested inlearning from the lessons of the past.

However, today's practice in KM still lacks from significant drawbacks and the existingknowledge is captured and capitalised only to a small degree. The reasons for this aremanifold, and one of the most critical factors is time. Though many employees are willing todocument and utilise existing knowledge, they do not have the time to do this in the pressureof day-to-day business life. Consequently, there is a strong need for methods and tools withutmost user friendliness for rapid Knowledge Management.

This paper aims to contribute to this need by discussing the relevance of pragmaticapproaches for KM in engineering. Three cases will serve as an example for presentingbenefits and drawbacks.

2 Pragmatic Solutions in KM - Motivation and Characteristics

Knowledge can be seen as the entirety of cognitions and abilities which are used byindividuals to solve problems. This comprises theoretical perceptions as well as pragmaticday-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 orpractice of creating, acquiring, capturing, sharing and using this knowledge, wherever itresides, to enhance the learning and performing in organisations [2].

As the evolution of KM is driven strongly by large enterprises and consulting companies, theproposed solutions are often rather complex and dominated by information technology (IT).However, Malhotra [3] reports about different studies in which no direct correlation betweenIT 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 andoperate through the social processes of collaborating need more attention. Davenport andPrusak [4] report that some Japanese companies have installed so called "Talk Rooms" inwhich scientists come together to have a cup of tea and talk to each other for about half anhour. There is neither an agenda nor schedule and the only target is to bring these peopletogether to evoke a discussion about their current work and to exchange ideas, thus leavingthe generation of new ideas up to chance.

A similar perspective is taken by the authors in [5]. Extending this statement, the authorswould like to take the position in this paper that small pragmatic solutions are often aseffective as high IT investments. Therefore the aim is to exploit the already existing systemsas 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 phraseswhich 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 probleminstead of a 100% solution. The remaining 10%-20% are either postponed for future activitiesor are not solved at all, because of the undue efforts which are necessary to achieve theneeded 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 largerfollow-up solutions (if felt necessary)

• low costs

Based on a number of projects in the field of KM in engineering design the authors areconvinced that a "controlled neglect" of certain aspects of a problem is reasonable for manyindustrial applications. This controlled neglect is implicitly embedded in the Pareto-principle(better known as the "80/20-Principle"). This principle was recognized by the Italianeconomist Vilfredo Pareto at the end of the 19th century and first published in 1897 [6]. Itbasically says that, out of a given group of elements, already 20% of them will yield 80% ofthe 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 successfullyapplied in others than the engineering domain are given in [7].

3 Cases 1 - KM within the Process Chain of Formed Sheet MetalParts

A pragmatic approach to knowledge management was chosen at a manufacturer of formedsheet metal parts for small series. Figure 1 shows the process chain from tool design until thefinishing of the sheet metal parts: based on the product specs, a tool has to be designed andmanufactured in various process steps: casting, milling, finishing, etc. In the last step the toolis used to manufacture the formed sheet metal parts. As the various process steps needspecialised resources the shop floor is organized according to the process chain into so-calledmanufacturing "cells" or "units". Knowledge about problems and related solutions identifiedduring the process was documented in problem and solution reports according to the needs ofthe individual manufacturing cells. Available knowledge of the other cells as well as the needsof 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 toavoid 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 reducelead-time and increase quality the company had to redesign the information managementalong 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 andrepresentatives from all manufacturing cells involved in the process chain, to discuss themutual needs, the problems, and the challenges of all steps of the chain. Based on a betterunderstanding of each other, inputs and outputs requested from the various cells were definedand the overall process knowledge was structured. In many cases, changes were requiredcompared to the old approach and compromises were made in order to achieve a pragmaticsolution, e.g. people agreed on having a 90 % solution instead of a 100 % solution whichwould have required far more effort.

ICED 01 - C586/526 93

A second pragmatic element in the approach was that the solution was implemented in theshort term as a paper based KM system. Following an incremental approach, the first step wasto start with a so called "tool file", which was handled manually along the process chain fromcell 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" hasstarted, so that in future problems, related solutions as well as other ,,experiences" gained inthe various steps of the process will be documented along the whole chain from tool designuntil the assembly of the sheet metal parts. Even by introducing the paper based, butcommonly agreed tool-file, the number of reliable feedbacks from manufacturing to designincreased significantly.

Table 1. Summary of Case 1

ProblemInsufficient communication and coordinationalong the process chain, caused by theapplication of the so-called"Throw it over the wall"- approach.

Pragmatic ApproachSpecification of rough but commonly agreeddocumentation forms. Incremental Approach:From an early implemented paper basedsolution (80-90% solution) to a databaseapplication. Forms were made accessible forall employees involved in the process chainby an Intranet application.

4 Case 2 - Management of Design Knowledge between Design andAssembly

Considering the time aspect of a production chain, assembly activities are "far away" fromdesign activities. This causes various well known problems in engineering design:

• After the design, a feedback from the assembly is - if ever - available only several weeksor months later.

• As the documentation of problems is time consuming and represents an additional activityfor the people in the assembly area, their motivation is limited.

However, aiming at high quality products experiences gained in the production and assemblyprocess have to be made available for the design of new products. In parallel, the time andefforts needed for documentation have to be minimised and just-in-time documentation has tobe realised. Additionally ideas about optional solutions, anticipated problems, as well asidentified problems have to be described in such a way, that it is easy for the designers tounderstand.

The approach chosen in the company was to create a close link between the designdepartment and the assembly area by installing an Intranet application on the one hand, andby offering various digital cameras to all departments dealing with the manufacturing andassembly on the other hand. Pictures made with the digital camera are stored in a database andare being made available to the design department via the Intranet application. So far a textualdescription has to be typed to describe the problem documented by each specific picture.However, by applying this approach, time consuming documentation activities were avoidedand 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-pragmaticsolutions: The distribution of digital cameras including the instruction to manually typing inthe problem can be regarded as pragmatic because it used a straightforward approach andmature and easy to use technology1. The introduction of technologies like e.g. speechrecognition, automatic picture processing and indexing would have been beyond pragmaticapproaches as these are not yet fully mature and need careful adaptation and fine tuning. Thusthe proposed 80% solution was prioritised compared to the 100 % that would perfectly fulfilthe needed requirements.

Table 1. Summary of Case 2

ProblemInsufficient feedback of problems andexperiences identified in the assembly area todesign department

Pragmatic ApproachEasy to use technologies (digital cameras andIntranet) for a quick documentation ofproblems and failures.

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

The following case provides a brief outline about different pragmatic approaches for KMwhich have been implemented successfully in a R&D department of an organisation with astaff of 150, comprising engineers of various domains, as well as technical and administrativestaff. Major objective of all activities was to reduce the knowledge loss when experiencedcolleagues leave the organisation, to speed up the learning curve for novices, and to increasethe knowledge exchange between the individual, multidisciplinary experts. The measureswere addressing both knowledge about complex engineering issues e.g. methodicalresearch/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 juniorengineer, is assigned to a personnel coach who is responsible for introducing the novice tothe colleagues, the business processes, and the future working domain. The coach musthave already stayed in the organisation for at least 2 years.

• Round Table: The engineers involved in the development process meet regularly (3-4weeks) for exchanging their current design challenges and problems. The round table isaccompanied by smaller means as e.g. a knowledge map of the engineers or an internalnewsgroup for short term problem discussions.

• Common directory structure: All engineers store all their files in a common directorystructure on a server. No files related to a project must be stored on the individual harddisks. The structure comprises predefined directories for e.g. projects, acquisition (bids),old projects, general department issues, or individual users. The structure is predefined upto four levels (for a detailed case description cf. [8]) which was identified as sufficient formost of the projects. A cost benefit ratio for this measure was exceptionally high, alsobecause no IT investment for its implementation had to be made (because servers werealready existing).

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

ICED 01 - C586/526 95

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

All measures are successfully in operation since 2 years (except for the round table which hasbeen implemented only 3 months ago). All measures allow small individual or case specificmodifications and assure short term benefits for the users. Common to all approaches was theutilisation of the existing IT infrastructure. For some of the approaches, also larger solutionshad been in discussion, but these were rejected for the benefit of a fast, flexible and simpleimplementation. Also, all approaches have been planned and implemented by the employeesthemselves.

Table 1. Summary of Case 3

ProblemFlat learning curve of novicesLack of communication of non projectspecific information and knowledgeIdentification of knowledge "hidden" in otherprojects

Time consuming no value adding tasksrelated with project management activities.Frequent disturbance of experts related to tipsand tricks requested by colleagues

Pragmatic ApproachPersonnel coachesProgrammers Round Table

Specification of identical directory structuresup to the fourth level for all types of projects.Further detailing of the structure would havegenerated to high effortsDocumentation and provision of "How to's"on the Intranet

6 Conclusions and Future Activities

The authors have applied the concept of pragmatic approaches for KM considering industrialcases related to engineering design. As described, pragmatic approaches are based on aphilosophy 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 designenvironment 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 maybe tempted to implement the first solution they see without carefully reasoning about itsappropriateness and usability. If KM solutions aiming to support a better cooperation betweendesign and manufacturing fail, it is more difficult to motivate the users to participate in asecond approach. Thus - in contrast to trial and error solutions - the possible error must beavoided as far as possible. Accordingly incremental approaches are far more promising thanlarge 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 ofpragmatic approaches in engineering design.

A general question arising in the context of applying pragmatic approaches, that aim atachieving a 80-90% solution instead of a 100%, is that according to the Pareto Principle themost relevant parameters/elements have to be identified. Thus a major risk when applyingpragmatic approaches is the neglect of vital aspects of the problem to be solved. So far thestarting points in the industrial cases described above were identified in common workshopsaiming at a higher product quality and shorter throughput-times. In order to exploit pragmaticapproaches with a reduced risk, future research should aim to develop methods and tools forKM which allow the identification of the most relevant aspects to be addressed by pragmaticsolutions.

References

[1] Probst, G.; Raub, S.; Romhardt, K.: Wissen managen - Wie Unternehmen ihrewertvollste Ressource optimal nutzen; 3rd Edition; Frankfurt am Main, Wiesbaden;Gabler-Verlag p.46, 1999

[2] Scarborough, H. Knowledge Management: A Literature Review, Institute of Personneland Development, 1999

[3] Malhotra, Yogesh: Knowledge Management for the New World of Business. AsianStrategy Leadership Institute Review, Vol. 6, 1998

[4] Davenport, T., Prusak, L.: ,,Working Knowledge - How Organizations Manage whatthey Know", Harvard Business School Press, Boston, Massachusetts, 1998

[5] Thoben, Klaus-Dieter; Weber, Frithjof: Supporting Decision Making andCommunication in a Concurrent Engineering Environment: Information Technologyand Social Aspects. In: I. Dumitrache, A.M. Stanescu, M. Pallot (Eds.): Preprints of theFirst International Symposium on Concurrent Enterprising, ISoCE'98, 4-6 June 1998,Sinaia, Romania, 1998, pp. 23-34

[6] 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 )

[7] Koch, R.: The 80/20 Principle - The secret to success by achieving more with less.Currency, New York, 1998

[8] Thoben, Klaus-Dieter; Weber, Frithjof: Designing Information and CommunicationStructures for Concurrent Engineering - Findings from the Application of a FormalMethod. In: Lindemann, Birkhofer, Meerkamm, Vajna (Eds): ICED 99, Proceedings ofthe 12th International Conference on Engineering Design, Schriftenreihe WDK,Munich, Vol 2, p. 989-994

Klaus-Dieter ThobenUniversity of Bremen and Bremen Institute of Industrial Technology and Applied WorkScience (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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

EFFECTIVE ABSTRACTION OF ENGINEERING KNOWLEDGE FOR KBEIMPLEMENTATION

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.

1 Introduction

This paper suggests a set of guidelines for the effective abstraction of engineering knowledgefor the application of Knowledge-Based Engineering (KBE). KBE applications have beensuccessfully delivering benefits in reducing engineering design time and cost. However, thecurrent generation of KBE applications is developed with the primary objective of automatingdesign 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 aKBE application during which the guidelines and methods of abstracting engineeringknowledge was developed and tested. The innovation is in the viewpoint of optimising KBErules with the consideration of efficient abstraction and re-use of knowledge. The researchwas carried out during a pilot industrial project in proving the feasibility of using KBE inaerodynamics wind tunnel model. The approach follows on the concept of ReusableKnowledge Component (RKC) proposed previously in the group. KBE applicationsdeveloped with the guidelines shall be easier to maintain and grow due to better knowledgesharing and reuse.

2 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 object-oriented programming environments tightly integrated(or interfaced) with a geometricmodeller.

In contrast to CAD and solid modelling design tools, the key characteristics of KBE aregenerative modelling and integrated modelling. Generative modelling means that the productmodel is generated based on a set of coded rules enabling automated generation of productdata. The starting point of the design is a set of rules rather than a geometric concept. In orderto achieve this, a generic model of the product needs to be created based on a detailunderstanding of the product, in terms of its function, geometry, configuration and all therelevant factors. From this generic model, the geometry and other product data for a range ofsimilar products of similar functional characteristics can be generated automatically. Thespecialisation characteristics of these instances of the generic models can be specified by thedesign end users. For example, if a generic model of an aircraft wing can be defined, a varietyof 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 productdevelopment disciplines and activities can be built into the generic model. Examples ofintegrated modelling are the automatic generation of finite element meshes and machiningtool paths together with product part geometry.

3 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 extendand maintain it conveniently and also to effectively reuse the knowledge collected for oneKBE 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 theapplication level, example project like KOMPRESSA (Knowledge-Oriented Methodology forthe Planning and Rapid Engineering of Small-Scale Applications) [6], aims at developingKBE implementation methodologies for small organisations.

As it has been reported in [6], the lack of standardisation within KBE applications, platformsand systems, requires knowledge sharing and reuse strategies within organisations. A strategyis the re-structuring of KBE applications to produce smaller, generic sub-applications. Thesesub-applications can then be re-configured for future KBE development. These generic sub-components are called Reusable Knowledge Components (RKC). RKC's behave as smallsoftware packages in which knowledge related to solve engineering problems is stored. ARKC accepts inputs and then generate decision outputs accessing to a knowledge basecontaining engineering rules using certain inference method.

4 Developing KBE applicationsThe KBE development process consists of the steps to: capture knowledge; develop theproduct and process models that represent and maintain the captured knowledge; and thecoding of the knowledge using a KBE implementation language. Knowledge abstraction isthe step in formulating the product and process models to be coded. This requires a carefulanalysis of the domain knowledge in which the KBE application has to work and the specificknowledge 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 bebuilt. 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 problemsolving 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 byknowledge engineers whose responsibility is to represent the knowledge and make it explicitfor its coding. The representation is the abstraction of this knowledge in such a way that issuitable 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 mechanismin these systems is rule. In effect KBE technology uses the rule-based knowledgerepresentation technique combined with object-oriented programming.

Thus, knowledge abstraction in KBE can be stated as: "The process in which the engineeringknowledge is analysed for being represented in terms of objects and engineering rules througha computer understandable language". Figure 2. illustrates how design knowledge is handledin 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 attributessuch as weight or density.

• Engineering rules defining relationships among design objects.

Engineering rules are embedded in design objects in most KBE languages. However due totheir 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 theKBE software platform are the subject of current research [9].

The KBE application is the combination of these objects working together in a softwareplatform. The output of the KBE application is the complete or partial solution to the designproblem. This output could be in the form of 3D models, data sets, or other kinds ofdescription fulfilling the requirements of the design problem.

5 Guidelines for effective knowledge abstraction

Most KBE applications have been developed for solving large-scale design problems in theaerospace and automotive industries. The main concern is the functionality needed toautomate 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 istypically more than the cost to develop a bespoke KBE application. The benefits of the re-usable concept are to be reaped from the elimination of redundant knowledge capture and thesystematic build up of a high quality knowledge pool for long term KBE implementation.

The effectiveness of the knowledge abstraction process depends largely on the optimumdecomposition of the design problem to create sub-components able to be shared and reusedamong applications and be maintained easily. Theoretically, object-oriented technologyallows the creation of a KBE application that has only one single object. This object wouldcontain all the part definitions, calculations and engineering rules. Common sense andstructured programming methodologies advise against this approach. The current state ofKBE technology as reported in [4], [8] lacks the tools to support effective knowledgedecomposition due to the ad-hoc character of most KBE applications.

In the industrial project to develop a KBE application for aerospace wind tunnel models, theauthors noticed that many engineering rules collected were generic and could be used againand again, even in the same application package. So the attention had been on how todecompose those knowledge in a fashion that could be reused effectively.

This led to the guidelines and criteria that could be used by knowledge engineers anddesigners for more effective abstraction of design knowledge. The guidelines provided hereare consolidated from the known knowledge management techniques and tested through thedevelopment of the KBE applications in the case study. The resultant knowledge abstractionprocess 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.) thatare often repeated in the problem.

INDEPENDENT. Split large problem into independent problems. A design problem can becomposed of different tasks that are almost independent.

GENERIC. Define generic ways of performing tasks in the environment. A specific approachto solve a problem may not work in other similar cases. A generic way of solving a set ofproblem is more effective.

EXTENSIBLE. Design objects definition must be done with the consideration on the use ofobjects in other design problems in the environment.

The application of these general guidelines is illustrated in the industrial case study.

6 Case study

The authors have been commissioned to build a KBE system to investigate the feasibility ofusing KBE for aerodynamics wind tunnel model design and manufacture. Wind tunnelmodels are scaled down versions of aircraft components. Although computational fluiddynamics simulation is used extensively for the aerodynamic design of aircraft, the testing ofdesign 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 andattachment requirements of the test, as well as maintaining a similar structural behaviour ofthe full size aircraft. Typical wind tunnel test requires the collection of pressure data from apre-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 tothe pressure measuring instruments.

The design problem illustrated here is the automated generation of the tubing design. Itconsists of a set of runners on the surface of an aircraft component. This set of channels linksthe pressure tappings with a pocket feature. Inside the runners, tubes for measuring thepressure 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 2Dplane. In Figure 5 (left), the problem can be stated as:

• Problem statement: Link the pressure tapping points with the pocket using a set of straightrunners.

• Constraints: 1. The runners cannot overlap with each other. 2. The width of the runnermust 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 tosolve 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 isdeveloped. The new design concept is illustrated in Figure 6. The design knowledge has beenabstracted into the three types of objects: primary channels, secondary channels and tertiarychannels. The behaviour of the objects is controlled by a set of engineering rules. An exampleof engineering rules would be the one controlling the behaviour of the primary and secondarychannel. Such engineering rules would decide whether the secondary and primary channel Heon the right or on the left side of the pressure tapping, depending on the position of thesecondary channel. As can be seen in the example, all secondary channels except the one inthe very left side are located at the same side in which the tapings are arranged with respect tothe 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 theprimary runner.

Independent: Design objects are almost independent. Their dependency is based on simplerelationships such as the position of other objects. For example, the position of theprimary channels at the right or left side of the tapings depends on the position of thesecondary channels.

Generic: Objects are defined in a generic way. For example the same object "secondaryrunner" is used when only one tapping has to be driven to the tertiary channel as well as inthe case of ten tapings.

Extensible: The design objects here defined have been used in a nacelle design. They canbe 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 isrepresented 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 differenttype of runners to three. This represents the best concept to connect different pressure tappingpatterns on different models.

Figure 6. Proposed solution for the design problem.

7 Conclusions

This paper illustrates just a small and simplified part of the work developed in theresearch/industry partnership. In its current status, the KBE application has transformed adesign activity that can last more than a week into a two hours process.

The knowledge abstraction approach proposed here has demonstrated its feasibility in theKBE implementation for this industrial problem. The application of the guidelines proposedhere have been useful to prepare the business case for introducing KBE technology to theindustrial collaborator. It is expected that future extension of KBE application to the differentmembers 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 theextension of KBE implementation from design to downstream activities such asmanufacturing and/or assembly procedures. Current KBE systems do not provide clearseparation of design object and engineering rules. A framework that enables this separationand provides the ability to manage both elements would allow better adoptions of the RKCapproach. This framework could be supported by the emerging technology of "softwarereuse" [10] to increase the quality and productivity of the coding processes.

References

[1] Cooper, S., Fan, I. & Li, G. "A Best Practice Guide - Achieving CompetitiveAdvantage through Knowledge Based Engineering", Department of Trade and Industry(DTI), UK. June 1999.

[2] Li, G., Cooper, S. & Fan, I. "KBE application and research in UK". Proc. InternationalConference on Advanced Manufacturing Systems and Manufacturing Automation,Guangzhou, China, 2000.

[3] Fan, I., Cooper, S., Li, G., Sehdev, K. & Grealy, M.T. "Knowledge-based Engineeringas a CE Tool to Achieve Fast Design Iterations". Proc. ISPE International Conferenceon Concurrent Engineering, Bath, 1999.

[4] Sainter, P., Oldham, K. & Larkin, A. "Achieving Benefits from Knowledge-basedEngineering Systems in the Longer Term as well as in the Short Term". Proc.International Conference on Concurrent Enterprising. Toulouse, 2000.

[5] Klein, R. "Knowledge Modelling in Design - the MOKA Framework", Proc.International AI in Design Conference. Worcester, 2000.

[6] Lovett, P. & Bancroft, C. "Knowledge Transfer for Knowledge Based Engineering".Proc. Technology Transfer and Innovation Conference, London, 2000.

[7] Li, G., Cooper, S., Garcia-Fornieles, J.M. & Fan, I. "Knowledge Reuse: ExperiencesGained from Integrating Manufacturing Knowledge into Product Design". Proc.1CED'99, International Conference on Engineering Design. Munich, 1999.

[8] Sainter, P., Oldham, K., Larkin, A., Murton, A. & Brimble, R. "Product KnowledgeManagement within Knowledege-based Engineering Systems". Proc. DETC'00, ASME2000 Design Engineering Technical Conference and Computers and Information inEngineering Conference. Baltimore, 2000.

[9] Lagos, M. "MSc. Thesis: Engineering Knowledge Structuring, Reuse andMaintenance". Cranfield University. Cranfield, 2000.

[10] Hashim, K. & Key E. "A software reusability attributes model". International Journal ofComputers Applications in Technology, Vol. 8, Nos 1/2, pp. 69-77.

Corresponding author

Dr. Ip-Shing FanCranfield 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

NEW TECHNIQUES FOR DESIGN KNOWLEDGE EXPLORATION - ACOMPARISON OF THREE DATA GROUPING APPROACHES

P C Matthews, P M Langdon, and K M Wallace

Keywords: Design understanding; information analysis, classification and retrieval; knowl-edge acquisition; machine learning.

1 Introduction

The overall aim of this paper is to compare the utility of a wide range of data grouping methodsused for the purpose of exploring the inherent structure of knowledge in design databases. Forexample, this could include knowledge about analytical descriptions of the similarities betweenvarious substances in a database of materials or the relationships between pairs of parametersin a database of mechanical designs. Grouping methods have been used previously for ma-chine learning purposes [1], however our main aim is to produce human-usable knowledgefrom such systems. For this purpose, the principal objective is to contrast three different meth-ods 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 effec-tiveness of the techniques as data exploration methods for designers who wish to gain a greaterunderstanding of a specific design space.

The techniques used are examples from our research that represent techniques that are cur-rently available. These include those that are conventional and novel; hierarchical and non-hierarchical; and with differing salience of implementation. The comparison will focus on fourcriteria 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 ofthe 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: param-eters, 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 differ-entiate between three different species of the iris flower [3]. This was a statistical method foridentifying 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 modifythe 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 anon-hierarchical clustering technique that has the advantage of being able to associate any ob-ject with a number of groups. Such non-hierarchical methods were initially investigated withthe aim of generating thesauri [5]. This is a non-hierarchical application as different wordscan 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 methodto type of design data. We summarise three design cases and describe a potentially appropriatetechnique for analysing the given design domain.

3 Clustering applications

For a given design domain, a number of features or criteria are selected that describe thisdomain, and the object collection is grouped according to these. Usually grouping is basedon the notion of 'distance' between objects. This may be calculated in different ways and thechoice 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 theyexist. Selection can then be coupled with the designer's criteria, and selected members used toidentify 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 thisway, explicit knowledge may be extracted from relationships that are implicitly embeddedwithin design databases.

3.1 Non-hierarchical clustering

Most clustering methods generate either exclusive partitions or hierarchies of objects, namelyeach given object belongs to only one 'parent' set. In a non-hierarchical clustering method, itis possible for an object to belong to several parent sets (see Figure 1). This is useful where thedescription 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 objectsbased on a similarity between pairs [7]. This is useful when there is only one measure availableto compare any two objects. The designer decides how much overlap, k, between groups ispermitted. 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 similaritythresholds, without having to repeat the expensive computation.

This method has been applied to design and evaluation parameters from a gas turbine aero-engine combustor. Combustor design is based on empirical methods, which result in slow andcostly design iterations. The aim was to group the design parameters and evaluations (designcomponents) together according to similar types of behaviour, such that further investigationcould be focussed on sets of components that were likely to be related. Traditional correlationand regression techniques were of little use here due to the highly non-linear nature of combus-tor 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 dis-tribution [8]. By analysing the component maps generated by the SOM, it was possible tomeasure the 'behavioural similarity' between pairs of components. A non-hierarchical cluster-ing method is desirable, as it was not known if the components belong to exclusive groups. TheJardine algorithm generated sets of components with similar characteristics. These sets are thenfurther analysed for relationships using more traditional methods, such as scatter plots. Thisrepresents 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 opportunityfor the domain experts to evaluate the relationships for novelty and applicability. Of theserelationships, 65.2% were thought to be accurate, 43.5% were believed to be important for adesigner 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 adatabase 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 groupingsthat are easily analysed. The input format is quite flexible, permitting both quantitative andlinguistic data to be processed, although the direct output from the system does require furtherprocessing to generate suitable human-readable relationships. However, this final process isquite simple. By testing on various subsets of the available data, it has also been shown to bequite robust.

3.2 Hierarchical agglomerative clustering

A standard methodological technique, hierarchical agglomerative cluster analysis, was em-ployed as a novel exploratory technique for the classification of engineering materials. Clas-sification plays a key role in materials science where an understanding and manipulation ofmaterials depends on grouping by similarity and indexing. Designers will rank materials ac-cording 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 criteriaare erroneously biased.

Forty materials were grouped on the basis of eight thermal and mechanical properties such asdensity, thermal properties and hardness and the resulting groupings compared to a conven-tional materials science classification. The same materials set was also clustered on the basisof the aesthetic aspects of their appearance, such as colour, transparency or reflectivity.

The materials were clustered using a hierarchical agglomerative method yielding a hierarchycomparable 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 inputparameters for this analysis were a complete set of quantitative measurements of a number ofparameters or information about the presence or absence of certain features, such as opacityor produced-shape set. Grouping was carried out iteratively with an increasing stress or dis-tance parameter. Grouping was on the basis of a single-linkage method whereby a candidatematerial is grouped with another material or an existing group of materials on the basis of theclosest distance between them. Other linkage methods exist, for example a candidate couldjoin with a single object or group on the basis of the average distance between them or the fur-thest distance. These methods were tried but did not produce great differences in the resultinghierarchies.

The results showed that engineering material properties could be grouped by the method inways 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 exam-ple, the clustering of materials on the basis of conventional engineering parameters producedsimilar hierarchies to science based groupings. However, some materials such as aluminiumfoams were grouped outside of the metals and epoxy/carbon fibre composites were groupedwith 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, acrylicand epoxy group together because of their potential for translucency.

The technique was tested for reliability through the use of a range of grouping methods anddistance metrics with the same materials set. It was found that the analysis was robust overmethods for this data set and for the other sets reported.

This data exploration technique has been applied in a trial [?] and shown promise for extendingthe approach to further sets of material, product or design attributes. It was also concludedthat new material groupings resulting from the use of the method might give rise to new designopportunities.

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 thata detailed understanding of the potential of all individual solutions will be achieved. Thepartitioning-around medoids method implemented a novel method of clustering the solutionconfigurations to reduce the number of solutions that the designer needs to consider. This wasdone by presenting the designer with representative solutions (medoids) that were by-productsof the clustering process, revealing hidden structure.

Given a distance matrix for all objects that is calculated using a generalised Euclidean distancemeasure with both quantitative and qualitative input data, the technique reverses the conven-tional clustering approach and repeatedly partitions the data set to attain the required numberof groups. This is managed on the basis of iterative selection of a set of representative groupmedoids and minimisation of average group member distance to the medoid. The method yieldsstatistics 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 softwareprototype of a user interface intended to allow exploration of generated solution concepts inthe mechanical design domain (see Figure 3). Initial experiments examined a clusterings oftwo sets of around 20 solutions resulting from a synthesis with solutions containing up to fiveelementary 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 agrouping. The planet circles represent the group members. The average distance of membersfrom the centre of the cluster is represented by the diameter of the "sun" circle. The mem-bership 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 clickedon. Different partitions can be generated and the relationship between group size and distancestatistics visually examined. Selection of a solution can be used to initiate the creation of a 3Dvisualisation of the mechanical solution chain.

The results of this method were compared with how designers would classify the same objectsaccording to their engineering experience. These classifications were scored for percentagesimilarity to the classifications generated from a number of different DESYN clusterings ofthe same set. The results demonstrated a 69% agreement for a solution set of 3, 4, and 5clusters 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 randomcluster testing. Hence, this method was taken to generate summaries of a given solution set thatcorrespond to designers' experience. In addition, the method offers an unbiased overview ofthe solution space in the form of the representative medoids, while at the same time allowingdetailed examination of individual groups and solutions.

4 Comparison of methods

Preliminary comparison has been made of three different techniques for data exploration. Thefour criteria that were applied to the three methods were:

1. Does the method require realistic assumptions; and what are the implementation issuesarising?

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 produceoutput 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 de-signer needs to determine the amount of overlap the clusters can have and a threshold distancethat will distinguish when two objects share a class. The algorithm was implemented in MAT-LAB, 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 overlappingrequirements (the case study reported here had 37 dimensions and required about 500Mb RAMand several hours computing time on a 300MHz Pentium class processor to process a 3-memberoverlap). The output generated is a series of sets containing objects that are similar to eachother on the basis of the chosen metric. The non-hierarchical nature of the method means thatit is possible for an object to be in more than one set. This output is strictly dependent on thedistance matrix, and is therefore robust to re-sampling and re-ordering of the objects.

The hierarchical agglomerative method requires conventional assumptions to be made aboutthe data measurements. For example, it is assumed that a Euclidean distance metric adequatelydescribes 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 differ-ent grouping methods. It is further assumed that features used to group objects are weightedaccording to their relative contribution to indexing. This method assumes that group member-ship will be exclusive though fuzzy and overlapping methods do exist. Implementation of theapproach is ubiquitous, available in C and FORTRAN code form or in a variety of commercialpackages, and the algorithm terminates quite quickly (under 1 second on a 300MHz Pentiumclass processor). The input requirements are simple: a tabulated list of measurements or cat-egorical classifications are easy to generate. Output, however, is less straightforward. Themethod 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 clus-ter tree and this representation is not well suited to data interpretation and the investigationof knowledge structure. Reliability and repeatability are easily tested by examining outputstability with the use of alternative metrics and grouping methods or of data re-sampling orreordering.

Partitioning around medoids requires the same assumptions about distance metrics as the previ-ous method. However, the partitioning approach does not require a choice of grouping methodsas 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 casethe method yields statistics for fit that enable the grouping nearest to the natural structure tobe obtained by altering the partition number. Like the previous method, it is also assumed thatfeatures 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 embeddingof 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 Pentiumclass processor. The output of a design synthesis algorithm was automatically processed forinput to the partitioning algorithm and the output was presented to the user in graphical form asdescribed in Section 3.3. The required input to the algorithm was similar to that of the previousmethod and the output took the form of partition membership lists and inter- and intra-groupstatistics. This output format is well suited to investigation of data structure as the partitioningyields 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 au-tomating the process of finding natural partitions. Reliability was tested using known test datasets and by re-sampling of large data sets to test for stability of partitioning.

5 Conclusions

We conclude that (1) non-hierarchical methods may be appropriate where the objects are likelyto belong to more than one group; (2) hierarchical agglomerative methods allow a wide rangeof distance measures and grouping methods to be tried; and (3) partitioning around medoidsgives a useful representative for each group, together with a rich statistical description of thedata. Of these methods, the non-hierarchical algorithm provides a novel means of groupingobjects. The objects grouped by this method are not constrained to be placed in one group, butrather are placed in as many groups as necessary. The number of groups that result from thismethod 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 objectiveof suggesting which method is most appropriate for a given clustering problem. These methodscontribute to the design process by simplifying large databases of design objects. As discussedin this paper, these objects can take several forms ranging from parametric descriptions, mate-rial properties, and functional descriptions. This simplified representation can be used to gainknowledge from the given design domain by presenting the available information in a struc-ture that permits a designer to readily observe both common and differentiating elements fromwithin this domain. A direct result of this understanding is the ability to proceed through thedesign process more rapidly due to identifying the general design region a designer wishes totarget. 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 productdomain.

Acknowledgements

This work is funded by the University Technology Partnership for Design, a collaborative re-search project between the universities of Cambridge, Sheffield and Southampton; and withindustrial partners BAE SYSTEMS and Rolls-Royce. The Materials science data set analysiswas contributed by Kara Johnson and Mike Ashby. Patrick Langdon is an EDC Senior Re-search Associate supported by the UK EPSRC (grant number: GR/M232636).

References

[1] Y Reich and S J Fenves. Concept Formation: Knowledge and Experience in UnsupervisedLearning, 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 me-chanical design solution spaces. In H Bullinger and P H Vossen, editors, 8th InternationalConference 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 ClusterAnalysis. Probability and Mathematical Statistics. John Wiley, New York, NY, 1990.

[5] K Sparck Jones. Experiments in semantic classification. Mechanical Translation, 8(3-4):97-112, 1965.

[6] P C Matthews, K M Wallace, and L T M Blessing. Design heuristics extraction: Acquiringengineering knowledge from previous designs. In J S Gero, editor, Artificial Intelligencein 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 thedesigner: an application for cluster analysis. Materials and Design, 2001. submitted.

Peter MatthewsEngineering 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

COMPUTER-SUPPORTED SYSTEMATIC DESIGN AND KNOWLEDGEMANAGEMENT IN THE EARLY DESIGN PHASE

E Frankenberger

Keywords: Design information management, knowledge management, systematic productdevelopment, product structuring, mechanical engineering industry.

1 Introduction: The importance of information availability andsystematic work in the early design phases

The analysis and identification of the requirements, the search for solution principles and theanalysis and decision of the solution variants are important 'critical situations' in every designprocess [1]. Especially in the early design phases 'task clarification', 'concept' and'embodiment design', the course and main result characteristics of a product developmentproject are determined. For example, a big amount of the later production costs is aconsequence of the decisions for the solution principles taken in the concept phase, whereasthe efforts and costs for design changes increase during the progress of a product developmentproject. In order to make decisions between different solution variants in an early stage of aproject in the most objective way, it is necessary to have access to as much relevantinformation about these solutions as possible. Investigations in industry indicate, that a majorsource 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 industrialproduct development, this empirical result does not surprise: many companies developcomplex products in various series, such as different types of chain-saws, electric tools suchas drill hammers or different format sizes of offset printing presses. Between the product linesof 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 resultsof 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 anearlier 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 theengineering designers. But this 'corporate' knowledge underlies different erosions: Thecapacity of the human brain is limited and the facts which designers remember underlieemotional filters. Moreover the access to the knowledge can be restricted or even can get losttotally: designers are not available because they are out, they are ill, or they retire or leave thecompany due to other reasons. Consequently, the aim must be to safe and to convert theindividual design know-how into company know-how, which is entire, context related andaccessible at any time.

ICED 01 - C586/262 115

It is obvious, that a structured access to relevant information is one key for the improvementof design work. Another success-factor is a flexible but systematic proceeding of the designwork, as indicated by empirical studies [3]: A clarification of the task at the beginning, thestructuring of the overall-problem into sub-problems, the search for solutions for the sub-problems, the analysis of these sub-solutions, their combination to a concept and theevaluation of a solution are common steps in every systematic approach of problem solvingand not limited to design tasks [4]. Results of these steps are a requirements list, a structure ofsub functions, principle solutions with remarks about their characteristics, combinations ofsub-solutions and evaluations according to criteria derived from the requirements. Figure 1shows 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 theinformation, 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 thecapturing and reuse of design knowledge. For implementing this synergy, it needs specialsoftware for supporting systematic work in the early design phases, for compiling designinformation automatically in a structured way and for providing an easy access to it.

2 Situation of computer support in the early design phase

Up to now, computer support in engineering design is focused on the modelling of geometrywith computer aided design (CAD) systems and on providing product related data for thefollowing 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 stepsin the concept phase, for example the tool 'Invention Machine', which focuses on the solutiondevelopment by providing solution principles derived from existing patents or physical andchemical effects [6]. Nevertheless, it can be stated, that engineering designers start their workmostly without an appropriate access to the entire information, which was collected, in formersimilar 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 forlater discussions.

On the process side, there are a lot of theoretical considerations available concerningsystematic design, design methodology and knowledge management in engineering design. Inindustrial practice, systematic approaches in engineering design often struggle with thelimitations of time, methodical education and support from the middle management [7].Unfortunately, practice-oriented software-tools for supporting the daily design work based onsystematic design are nearly not available.

3 Key demands and development of a systematic design andknowledge management tool

The general demands on a practice oriented software tool for knowledge management andsystematic 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, evenin the first hour. It is obvious, that the awareness of the value of compiling information forlater projects will not prevent the designers from switching back to their usual procedures, ifthe new tool would not make the actual working step significantly easier. This means, the toolhas to support the designer in creating the design documents he need to create anyhow, but ina much more comfortable and automated way compared to paper and pencil or office toolssuch as Microsoft Word or Excel. The created documents need to be standardized accordingto norms and should be demanded by the management in order to fulfil standards such as ISO9001. If these demands are fulfilled, working with the tool will be considered as a "quickwin" even in the first time, when there is not the advantage of accessing relevant informationor reusing documents from former projects. Regarding the methodological support, aneducation in systematic design should not be a prerequisite for working with the tool. It has tobe very simple and flexible in operation and obvious in its general methodology.

Driven by these key demands the software tool PROSECCO ('Programm zur strukturiertenErfassung von Konstruktionsdaten', program for a structured compilation of design data) wasdeveloped for the support of the early design phases based on systematic design and designmethodology by Pahl & Beitz [4], Birkhofer [8] and the VDI-Guideline 2221 [5]. Thedevelopment of PROSECCO started in 1994 as a diploma thesis at the Darmstadt Universityof Technology supervised by the author in cooperation with the company STIHL, the famousmanufacturer 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 inGermany, and to the product development departments of 16 installations in companies ofvarious branches.

4 The user-concept of Prosecco

It cannot be the aim of this paper to explain the various functionalities of the software indetail; specific questions are addressed in the handbook [10]. This chapter introduces theconcept for compiling design information in so-called "working-folders" and the structuringof these working-folders of different products and projects. A main idea of the working-folderconcept 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 collectedwith a four-step-procedure in a working-folder with the headers 'Requirements', 'Solutionideas', '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 taskcharacteristics [3], according the checklist following the product life-cycle [8] or according toa self defined systematic. The purpose is to structure the requirements into logic groups and toraise questions for an entire analysis of the task or sub-task. Prosecco also asks for adifferentiation between demands ('musts') and wishes ('nice to have'). This differentiation isimportant for the later analysis, if a found variant is a solution to the problem or not. Thevalues to the discussed requirements can be filled into a template and are thus available forthe system. The requirements can be collected very quickly supported by the tool, either in ablanc new file or by changing an existing requirements list. The formatting work is doneautomatically by pressing a button. Figure 2 shows the template for collecting requirementsand 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 anoption, a decomposition of the problem can be chosen on this level in order to search forsolution variants for each sub-function separately. The solution-variants can be discussed bytheir 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 Proseccographic module from CAD and all major graphic programs. An useful tool for groupdiscussions and presentations is the automatically formatted solution printout. Figure 3 showsthe file 'solution variants' of a variant of the task "lifting jack" and the formatted solutionprintout.

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 overviewof the solution variants for all sub functions. Figure 4 illustrates a morphological matrix withthe 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 lif t ing 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 solutionsaccording the requirements or not. This check is done supported by the requirements list. Ifthere is a contradiction to a demand, the solution is crossed out with a reference to theanalysed reason for the contradiction. If there is only a contradiction to a wish, the reason iscaptured as well, but the variant is still a solution that will be evaluated in the next step. Aninteresting functionality of Prosecco is, that a change of a requirement can raise solutionvariants to be valid solutions again, which where dropped before due to contradictions withthis requirement. Figure 5 shows the analysis of a solution variant with a contradiction to ademand.

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 bediscussed afterwards in the evaluation phase. The evaluation in Prosecco is based on thetechnical-economical evaluation according to VDI-Guideline 2225 [11]. Criteria are definedand the solution variants are evaluated according to these criteria. Figure 6 shows how to putemphasis on specific criteria and the automatically generated strength diagram according toVDI 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 thedocumentation of new projects. The working-folders are saved in a structure compared to aMicrosoft 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, sheetfedoffset printing machines are structured in a function and subcomponent oriented way. InProsecco, any structure can be generated easily. Different product lines containing variousprojects with their product structures are saved in Prosecco. When starting a new project, anyexisting project or parts of it can be taken as a starting copy to speed up the work and toincrease the quality. Thereby, a full text search function helps to find any piece of informationin 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.

5 Experiences and conclusions from industrial practice

At Heidelberger Druckmaschinen, a field test of Prosecco with five designers was conductedfor 6 month in 1998 and 1999. The feedback of the designers was collected by a questionnaireand by a feedback-workshop. The result at Heidelberg was, that this easy structured computertool 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 isexperienced to be easy due to the simple four-step-approach of the program. Designers did notneed an extra training to work with the tool. At Heidelberg, the acceptance of the tool washigh due to a given and well-known function-oriented product structure. Prosecco was alsoused as a tool for compiling design knowledge from colleagues before their retirement. Ininterviews structured by Prosecco, many details on components and sub functions of own andcompetitive solutions from yesterday and today were discussed and collected with theiradvantages and disadvantages. Heidelberg finally bought two floating licences of Prosecco.

An important prerequisite for the successful use of Prosecco is the support of the managementand the integration of the tool into the project management and design review culture of thecompany. This means the implementation of methodical design procedures with standardiseddocuments, which the engineering designers have to create for the documentation of theirconcept decisions. The management has to ask for these documents for tracking the work inthe determining early design phases. In this regard, Prosecco does not only support systematicwork 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 avoidablemistakes 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 ismore or less reduced to the question of social contacts and communication), and PDM-functionalities in the embodiment and detail design. Prosecco can help to compile theconceptual design knowledge and to link it to the further product data management. AtHeidelberg, this task will be solved together with the implementation of a new PDM-system.

References

[1] Badke-Schaub, P. and Frankenberger, E., "Analysis of design projects", Design Studies,20, 1999, pp.465-480.

[2] Badke-Schaub, P. and Frankenberger, E. (1999), "Design Representations in CriticalSituations of Product Development", Proceedings of the 4th Design Thinking ResearchSymposium, MIT, Boston, 1999.

[3] Pahl, G., Badke-Schaub, P., and Frankenberger, E, "Resume of 12 yearsinterdisciplinary empirical studies of engineering design in Germany", Design Studies.20, 1999, pp. 481-494.

[4] Pahl, G., Beitz, W., "Engineering Design", London, Springer, 1996.

[5] VDI-Richtlinie 2221, Methodik zum Entwickeln und Konstruieren technischer Systemeund Produkte. Dusseldorf, VDI-Verlag, 1986.

[6] 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.

[7] Jorden, W., Havenstein, G. & Schwarzkopf, W., "Vergleich von Konstruktions-wissenschaft und Praxis; Teilergebnisse eines Forschungsvorhabens", Proceedings ofICED85. Zurich, Edition Heurista, 1985.

[8] Birkhofer, H. "Hohere Konstruktionslehre", Vorlesungsumdruck. TU Darmstadt, 1993.

[9] Berg, H., "Rechnerunterstutzte Losungsentwicklung komplexer Serienprodukte",Diploma Thesis, TU Darmstadt, 1996.

[10] Berg, H. and Berg, W., "Prosecco-Handbook", Darmstadt, Trigon Software,Berg&Partner Software GbR, 2000.

[11] VDI-Richtlinie 2225, Technisch-wirtschaftliches Konstruieren, Dusseldorf, VDI-Verlag, 1977.

Dr. Eckart FrankenbergerHeidelberger 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

122 ICED 01 - C586/262

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

DEKAS - AN EVOLUTIONARY CASE-BASED REASONING SYSTEM TOSUPPORT 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

1 Introduction

This paper describes a decision support system being developed in conjunction with two UKutility companies to aid the design of electrical power transmission protection systems. Abrief overview of the application domain is provided, followed by a description of the workcarried out to date concerning the development and deployment of the Design EngineeringKnowledge Application System (DEKAS). The paper then discusses the provision ofintelligent decision support to the design engineer through the application of case-basedreasoning (CBR). The key benefits from this will be outlined in conjunction with a relevantcase study.

2 Overview of Protection Scheme Design

The electricity transmission grid transports electricity from the generators (e.g. powerstations) 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 protectthe network and associated equipment from possible damage arising from faults on thetransmission and distribution networks. The transmission network is composed of largenumbers of expensive plant items, and a fault on the transmission network may also lead to awidespread power outage affecting thousands of customers over a large geographic area. Inorder to minimise the damage to transmission plant and the extent of any outages, protectionschemes associated with transmission networks are generally more complex than thoseassociated with distribution networks. This work focuses on the provision of intelligentdecision support to protection engineers during the design of protection schemes for electricalpower transmission networks.

The protection design is dependant upon several factors including, the topology of thenetwork requiring protection, the primary plant type and layout and the interfaces to existingprotection schemes in the surrounding area of the grid. Each protection scheme designconforms to fundamental protection principles applied in conjunction with standard companyprocedures [1]. A common starting point for a protection engineer when confronted with thetask of designing a 'new' protection scheme, is to assess the general protection requirementsof the section of transmission network and associated primary plant to be protected. Thisusually involves the identification of past similar protection scheme designs from whichspecific 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 whenattempting to re-use design knowledge. In addition engineers will draw upon variousreferences such as company standards, repositories containing network details and otherrelevant company resources.

3 The Requirement for Decision Support within the ExistingProtection Design Process

The provision of decision support for engineers involved in the protection design processaims 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 thedesign process. Throughout this process there are many different documents, standardsand databases which the engineer requires in order to successfully complete the design of aprotection scheme. These are stored in both paper and electronic formats, and in a numberof different locations. As a result, presently during the design process a disproportionateamount of time and effort is invested in the search and retrieval of relevant informationrequired to perform the various design activities.

• Harnessing and leveraging the knowledge and experience of protection engineers, accruedover a number of years service within the industry, as a valuable company asset andresource. This also addresses the risk associated with the loss of knowledge and expertiseassociated 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 maybenefit directly from the lessons learned and knowledge captured from their moreexperienced peers.

• Exploiting existing historical design data and information associated with past protectionscheme design projects.

4 Existing DEKAS Functionality and Architecture

4.1 The DEKAS Design Process Knowledge Models

The protection design process associated with each company was captured through anextensive series of knowledge elicitation sessions conducted with protection design expertsfrom each company [3]. The captured design process knowledge was then representedgraphically using the 'task' and 'inference' layers of the KADS knowledge modellingmethodology [4]. These knowledge models illustrate the interaction between the variousdesign process activities through their associated data and information flows. This processknowledge 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 designengineer through the various stages of the design process. DEKAS consists of a databasecontaining links to existing company data and information repositories and resources,providing the engineer with access to all relevant data, information and documentationnecessary to successfully perform the current design activity. These resources can be accessedthrough an 'information' layer, which provides supporting information relating to the use of aparticular resource or a list of pertinent questions to be asked of a particular individual, (notethat 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 particulardesign project to be stored in a single, structured format. This document storage facilitypreviously existed as a paper based equivalent. Although DEKAS does not profess to be adocument management system, however in the absence of a proprietary documentmanagement system some extent of organised structure for document storage is required. Thisenables 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' documentmanagement system at a future date remains a possibility.

5 Intelligent Decision Support Provided by DEKAS

The decision support feature of DEKAS will be greatly enhanced through the incorporation ofintelligent 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 isrepresented 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 similaritybetween individual cases as part of the CBR retrieval process. At the highest level, the CBRcycle 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 theCBR cycle.

This cycle effectively emulates the intuitive reasoning process adopted by protection designengineers at the inception of a design project. At present, knowledge of previous designsolutions 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 designexperience to participate in the protection design process.

The introduction of the CBR facility within DEKAS is intended to broaden and maintain theknowledge base available to design engineers within the organisation. This is achieved byconsolidating individual experiences within a continually expanding case library. For eachcompleted design project, the solutions applied and lessons learned are made accessible to allengineers through the application of case-based reasoning techniques within the existingDEKAS framework. The incorporation of CBR functionality within DEKAS will promote amore formal approach to the retention and dissemination of experiential design knowledgewithin 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 largelydictates the design of its associated protection scheme [1]. Therefore, network areas of'similar' topology and plant layout will generally share 'similar' protection requirements. Abasis for the comparison of different areas of transmission network, associated with currentand previous protection scheme design projects, is necessary to establish any inherentsimilarity between the two. This basis for comparison requires characterisation of the networkarea through a comprehensive list of indexing parameters, which effectively constitute thecase structure. The indexing parameters identified must be comparable across all cases andcontribute directly to the matching process, i.e. they must have some degree of influence ondetermining how similar one case is to another.

The construction of the case structure reflects the physical construction and topology of thetransmission network it describes. Figure 1 illustrates the nested relationship of the casestructures intended to describe an area of network, which is the subject of a protection designproject. 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 indexingparameters. In addition, each sub-case structure effectively represents an indexing parameterof the higher level case structure in which it is embedded. Arranging the case structure in thisway allows each indexing parameter to be placed in the context of the various networkfeatures they describe. This in turn facilitates the matching of the design project on differentlevels of detail (i.e. project level, substation level, bay level, equipment level), without therequirement for separate case bases. The nested case structure arrangement enables a singlecase base to be implemented, eliminating unnecessary duplication of indexing parameterswithin different cases, and providing the flexibility required to accommodate the varyingnumber of substations, substation bays and plant items contained within the network arearequiring 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 theweighting and similarity values associated with the indexing parameter itself and indexingparameter value respectively. The contribution of the weightings and similarities attached tothe complete set of indexing parameters detailed within the case structure, are combinedthrough the implementation of the nearest neighbour algorithm. This provides an overallassessment of the similarity between the network areas associated with a current and previousprotection design project.

The roles of weightings and similarities in CBR are well documented [6]. The weightings andsimilarities applied within the DEKAS case-based reasoning facility have been derivedthrough knowledge elicitation sessions with design experts. During the protection designprocess 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 varydepending upon the current stage or activity of the design process. In instances where theindexing parameter makes no contribution to the overall similarity assessment, the weightingvalue associated with that parameter will be zero. Therefore, each indexing parameter musthave associated with it, a separate weighting value relating to, and defined by each activitywithin the overall design process. The weighting attached to each indexing parameter can thenbe automatically adjusted to a predefined value, depending upon the stage/activity of thedesign process at which the CBR facility is invoked. Adjustment of the weightings in thismanner is more representative of the intuitive approach currently adopted by engineers, than aCBR system implementing a static set of weightings neglecting the changing task objectivesthroughout the design process [7].

Integration of CBR with Modelled Design Process

As previously described, the CBR functionality of DEKAS is responsible for theidentification 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 currentdesign, is unlikely to be the most effective implementation of the CBR functionality for twomain reasons. Firstly, at the beginning of the design process the current 'project' case (Figure1) 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 designengineer with all project documentation risks overloading the engineer.

It is for the reasons described that an evolutionary approach, dependent upon the current stageof the design process, is adopted for the population of a particular case and the return ofrelevant design information (Figure 2). Therefore, as the design progresses, more informationbecomes available which can be used to populate the 'empty' indexing parameters describingthe current design case. This evolving case description enables constant refinement of theCBR search as the design engineer progresses through the modelled design process. Inaddition, only information associated with the similar case identified and relevant to thedesign activity currently being performed by the design engineer is retrieved (e.g. an engineerperforming 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 withfresh challenges and problems, which may require an equally novel approach to derive asuitable solution. While the success of a particular design solution may vary, the ensuinglessons learned are always valuable. DEKAS provides the design engineer with theopportunity to formally document any specific 'lessons learned' associated with the variousdesign process activities performed during a particular project. The CBR facility withinDEKAS then offers engineers facing similar problems the opportunity to benefit from theexperiences of their peers, by first alerting them to potential design problems and returningthe associated lessons learned. This enables the engineer to either directly re-apply or refineand apply a previous solution to a specific design 'problem'.

6 Case Study - Using DEKAS to support the Design Process

This case study illustrates the use of DEKAS to support a protection engineer throughout theprotection design process from start to finish. When presented with a 'new' protection designproject, the design engineer's first activity is to launch DEKAS and register the project. Thiscreates an electronic design file providing a designated location for the electronic storage ofall future documentation created during the design process. The next stage is to navigate fromthe high level task model down to the appropriate design activity. Contained within themodel of the current activity, are links to relevant information sources required to completethe 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 relatesdirectly to the indexing parameters of the case structure. The automatic extraction of theindexing parameter values from the project documentation is transparent to the user, andavoids 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 designfile, the engineer can then navigate to the next activity within the modelled design process. Inaddition, links to project specific information including documents produced as a result of theprevious design activity may also be provided. This is particularly useful when multipledesign 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 byother 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 previouscase(s) to the current design. Through the derivation of this model, it has been identified thata further useful source of information would be to consider technical specifications fromsimilar designs. The current model has identified the type of document required, in this casethe technical specification. This, combined with the CBR which has identified the mostsimilar project, provides access to a similar technical specification stored in the relevantelectronic design file. As the engineer proceeds through each design activity, more indexingparameters become known and the associated weightings will adjust such that relevantdocuments from another previous design project may be retrieved.

Figure 3. DEKAS Architecture

7 Conclusion

This paper describes the application of case-based reasoning techniques in the provision ofintelligent decision support for protection scheme design engineers exhibiting varying levelsof technical experience. The system effectively provides the user with knowledge andunderstanding of the practical constraints, commonly occurring problems, idiosyncrasies andlessons learned encountered during previous designs, and the subsequent design solutionsapplied.

The design of a protection scheme from 'first principles' is a complex task involving theconsideration of multiple constraints and inputs in conjunction with a comprehensiveknowledge of protection design principles. Although circumstances may exist which dictate aprotection scheme should be designed in this manner, adopting this as a standard approach ona 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 designsolutions 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 reliespredominantly on the engineer's capacity for recalling previously designed schemes whichexhibit similar protection requirements to that of the current design project.

While other artificial intelligence techniques may provide some form of intelligent decisionsupport (e.g. rule-based, model-based systems), these may be more aligned with a designapproach from 'first principles'. In contrast, the existing design approach concentrating on there-use of available design knowledge appears more predisposed to the application of case-based reasoning.

This paper illustrates how case-based reasoning functionality can provide more effective andrelevant output (i.e. decision support) when placed in the context of the individual designprocess activities [7]. The evolution of the case structure and the adjustment of associatedweightings, 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 caselibrary. DEKAS therefore offers design engineers access to the right information at the righttime throughout the design process, and promotes the sharing of valuable engineeringexperience retained within a constantly expanding case base.

8 Acknowledgements

The authors gratefully acknowledge the contributions of ScottishPower and National GridCompany to the work described within this paper.

References

[1] Wright, A., Christopoulos, C., "Electrical Power System Protection", Chapman andHall, 1993

[2] Schreiber, Ahhermans, Anjewierden, de Hoog, Shadbolt, Van de Velde and Wielinga,"Knowledge Engineering and Management", The MIT Press, 1999.

[3] Firlej, M., Hellens, D., "Knowledge Elicitation - A Practical Handbook", Prentice-HallInternational, 1991

[4] Wielinga, B.J., Schreiber, A.Th., Breuker, J.A., "KADS: A Modelling Approach toKnowledge Engineering, Knowledge Acquisition", Vol 4, 1992

[5] West, G.M., Strachan, S.M., Moyes, A., McDonald, J.R., "Knowledge Management andDecision Support for Electrical Power Utilities", Proc. KMAC2000, 2000

[6] Watson, I., "Applying Case-Based Reasoning: Techniques for Enterprise Systems",Morgan Kaufmann, 1997, pp. 15-38

[7] Leake, D.B., Birnbaum, L., Hammond, K., Marlow, C., Yank, H., "IntegratingInformation Resources: A case Study of Engineering Design Support", Proc. ICCBR-99, 1999

Graeme WestUniversity 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 DESIGNICED 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.

1 IntroductionNowadays, the growing demand for customisable products involves an increasing number ofproduct 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 beenproposed, such as standardisation, DFX approaches and configuration.

Configuration task and the use of configurator software are becoming more and moreimportant for industrial companies as combining pre-designed components makes up moreindustrial products. The availability and identification of knowledge for product modellingand analysis are very important to satisfy the wide range of customer requirements and reduceproduct design cycle time and errors.

Our objective in this paper is to present an analysis of this knowledge required for productconfiguration.

A configurable product must have a generic model that contains all the knowledge about thepossibilities of adapting the product to customer needs. This model defines a set of predefinedcomponents, constraints on how they can be assembled into a valid product. It also definesconstraints 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 inconfiguration (generic models and configuration processes). Finally, this knowledge will bedepicted and illustrated by an industrial case, underlining advantage and limits ofconfiguration during the design process.

2 Design and ConfigurationBasically, design is the process of giving a product a description that satisfies a set ofconstraints and the customer requirements. The objectives of configuration are alike. In thissection, 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 designeridentifies 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 generatingand evaluating solutions. The product concept is developed in the embodiment design bydefining the complete technical description of the product. Finally, each component is definedby specifying all the drawing details and the manufacturing information. Three types ofdesign 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 thecomponent dimensions.

Many authors define configuration as:

"given:

a generic model of a configurable product able to represent a family of products with allpossible variants and options,

a set of customer requirements,

finding at least one component set that satisfies the customer requirements with respect to thegeneric model".

Generally speaking, configuration generates component list and/or values for attributes,whereas all the components are standard or completely defined by parameters values duringconfiguration and no new components are generated. Thus, configuration can exist in anycustomer/supplier relation when defining the product object of a deal.

The basic configuration problem can be modelled as a constraint problem: the variablesrepresent component properties. Each variable has a set of admissible values. Thecompatibility constraints describe the relation between components properties values (allowedcombination of values).

Constraint Satisfaction Problems (CSP) [4] are adapted to this knowledge: a solution to a CSPis an instantiation of all variables so that all constraints can be satisfied simultaneously. Inorder to match extensions of the basic configuration problem [5], extensions of the CSP basishave been proposed such as, for example:

activity constraints that take into account the existence of components or families ofcomponents depending on other variable value or existence. Such activity constraintsappear in Dynamic CSP [6],

a hierarchical view of the generic model which is useful and can be modelled withComposite CSP [7].

Aldanondo [8] proposes a classification of the configuration problem diversity addingparametric components problem and components spatial layout problem.

From these definitions, it appears that configuration is an intermediate form between adaptiveand variant design: activity constraints are not considered in variant design for example, butthe generic model is a restriction of the adaptive design.

3 Knowledge and ConfigurationProduct configuration requires a great deal of knowledge and skills concerning both theproduct being designed (generic model) and its configuration process. The purpose of thissection is to present the various kinds of configuration knowledge.

3.1 Generic modelMost of the time, a generic model is composed of a hierarchical structure of product functionsand 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 componentscan be standard (attribute values are predefined) or parametric (attribute values can take avalue in a predefined definition domain). The occurrence quantity of each function orcomponent in a configured product is defined with an attribute.

Once the functions and components have been identified, the next step deals with the variousways 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 andinteresting the designer.

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

3.2 Configuration processSome other knowledge can be related to configuration process. Once the generic model isdefined, the way of using it as a designer assistant must be established.

Two kinds of configuration processes can be identified: batch configuration and interactiveconfiguration.

In batch configuration, all the requirements are given in a single step and the configuratortries 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 requiresfrom 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 definitiondomains. In that case, the knowledge referring to how ordering the requirement inputs mustbe identified. In interactive configuration, the progressive configuration process replaces theclassical requirement or variable value assignment by a multi-step reduction of each variabledefinition domain ending with a single variable value. Of course, requirement propagation isachieved between each reduction. This way of configuring requires the configurator user toidentify some knowledge that allows refining his requirements progressively.

In both of these two kinds of configuration processes, requirements are frequently the sourceof conflicts (a constraint cannot be respected). Theses conflicts can be avoided thanks to somemodifications of the configuration process.

4 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 betweencomponents. 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 electricalfunctions. 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: thefunctional structure and the physical structure.

Functional structure

The automotive industry today manages to supply customers with individualised products atlow prices by configuring each vehicle individually from a very large set of possible functionsand components. For example, the Mercedes C-class has far more than a thousand electricalfunctions. Our functional structure distinguishes six functional domains: comfort, security,safety, cockpit, lighting and engine control. Each functional domain contains variousfunctional items that the wiring harness provides to the final user. Each of these items is eithercompulsory or optional, depending on the carmaker and the final consumer desire. A functionitem 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 tosee 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 inFigure 2. As a consequence, components that support a function can be localised in differentareas. A component localisation can be either forced by the carmaker or chosen within an arealist under ergonomical and technical constraints. The car physical structure separates fiveprincipal physical parts: Doors, Cockpit, Underhood, Front part and Rear pan. Each physicalpart contains one or several physical subparts. For example, the cockpit part comprises thedashboard, 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 switchpanel 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, identifyingswitches, sensors and activators positions, defining connectors and fuses and giving wirerouting into the car. A hierarchical bill of material makes the process complete.

In these examples, we illustrate two generic models that consider two specific electricalfunctions: Side-view Mirror and Window Lifter.

The description of each electrical function can be modelled with a DCSP framework usingvariables 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. non-existence) requires the existence of another variable.

We get the two function specifications using their Dynamic CSP models that compose theconfiguration 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 pulsemode, the window lifting starts and ends with an impulsion on the switch. In the optionalautomatic mode (continuous and pulse lifting), the window lifts as long as the switch isactivated. When both pulse and continuous modes are selected, there are two technicalways of obtaining the function: either one switch supports both modes or one switch isneeded 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 passengerwindow but the driver door panel switch area does not allow locating four windowswitches,

- 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 electricallymanaged.

In any case, switches that activate the function can be localised either on the door panelswitch area or on the central panel area of the dashboard. Moreover, when two mirrors aremanaged by the function, there can be one mirror adjustment switch with a mirror selectionswitch or two mirror adjustment switches, one for each side-view mirror. The left part of theFigure 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 ineach Dynamic CSP model as variables.

The same kind of DCSP model can link variables from higher levels of the two structures. Forexample, the model of the Figure 4 expresses that the Side-view Mirror requirement levelmust be less or equal than Window Lifter one.

Such constraints exist when packages of functions are desired or when a function depends onanother 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 bythe 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 activationdepends on other affectation of other variables. The user cannot affect a value to a variable aslong as this variable is not active. Then, the DCSP model propagates impacts of the choiceson all the variables belonging to the generic model.

Nevertheless, there are numerous ways of leading the configuration process. Anteriorityconstraints enable to specify variable instanciation orders during the configuration process. Asa 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 specifysuch anteriority. But they refer to anteriority due to physical or functional characteristics ofthe product. Conversely, the other anteriority constraints refer to knowledge on how toconfigure 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 whoseaim is to fix variables that limit thesearch space as much as possible. Such astrategy means affecting first variablesthat appear in numerous constraints.

For example, in Figure 4, an anteriorityconstraint is added between variable "Side-view Mirror Level" and "Window LifterLevel". Then, the discard of the value "low"for the "Side-view Mirror Level" variableeliminates the value "low" for the variable"Window Lifter Level". As a consequence,the variable "ECU Power" is activated andits domain is reduced to {"Medium";"High"}. Such a reduction is not possible ifthe anteriority constraint is reverse.

This example corresponds to a progressive

Figure 4. Constraints between Side-view Mirrorand Window Lifter functions

configuration. Here, the anteriority constraints are used to structure the configuration andprogressively reduce the definition domain of the remaining variables.

In batch configuration, there is no need of anteriority constraints between the variables thatexpress the user requirements, all these requirements being given at the same time. Whenother variables are not instanciated after the propagation, the configurator needs to fix them avalue, and anteriority constraints can be used in order to reduce the search space.

5 ConclusionIn this paper we have presented the required knowledge for product modelling and analysis ina 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. Thefunctional and physical structures identify variables. Product knowledge appears inconstraints between these variables and is introduced in the configuration generic modelthanks to the Dynamic CSP framework. In addition, we have discussed the knowledge on howto lead the configuration process adding anteriority constraints that guide the design.

Configuration, in product design, enables a better representation of knowledge for productfunctional specifications, components selection and its ergonomical location. It is notefficient 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 theconfiguration generic model. This underlines a need of cooperation with a traditional CADtool.

The knowledge of design conflicts has not been studied in this paper: the Dynamic CSPframework enables to get explanation of design conflicts by tracing back variables that justifyconstraints violation. Capitalising these explanations in order to help the designer to formalisehis knowledge and make a more robust generic model is a perspective of this study.

References

[1] Pahl G. and Beitz W., "Engineering Design: a Systematic Approach", 2nd Edition,Springer-Verlag, London, 1996.

[2] Caillaud E. "Knowledge engineering for concurrent engineering", International CIRPDesign Seminar. Kluwer, 1999, pp. 229-238.

[3] Brown D. C., "Intelligent Computer Aided-Design", Encyclopedia of Computer Scienceand Technology, Eds. Williams J.G. and Sochats K., 1998.

[4] Mackworth A.K., "Consistency in Networks of Relations", Artificial Intelligence, vol.8, pp. 99-118, 1977.

[5] Lippold C., Welp E.G., "Multi-Domain Configuration System for Analysis andSynthesis of Mechatronic Conceptual Designs", The 12th International Conference onEngineering Design ICED, Germany, 1999.

[6] Mittal S., Falkenhainer B., "Dynamic Constraint Satisfaction Problems", Proceedings ofthe Ninth National Conference on Artificial Intelligence AAAI, pp. 25-32, 1990.

[7] Sabin D., Freuder E.C., "Configuration as Composite Constraint Satisfaction",Proceedings of the Artificial Intelligence and Manufacturing Research PlanningWorkshop, AAAI Press, pp. 153-161, 1996

[8] Aldanondo M., Moynard G., Hadj Hamou K., "General Configurator Requirements andModeling Elements", ECAI Workshop on Configuration, Berlin, August 2000.

[9] Veron M., Aldanondo M., "Yet Another Approach to CCSP for ConfigurationProblem", ECAI Workshop on Configuration, Berlin, August 2000.

Jacques LamotheDRGI - Ecole des Mines d'Albi CarmauxCampus Jarlard Route de Teillet, 81013 AM CT Cedex 09FranceTel (33) 5 63 49 31 50Fax (33) 5 63 49 31 83Jacques.Lamothe@enstimac.fr

© IMechE 2001

138 ICED 01 -C586/571

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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.

1 Introduction

A design process can be viewed as a sequence of actions, which comprise the transformationfrom an initial state, comprising the design goals, to a final state detailing a new product orservice and how it should be created [1]. Commonly, a design process is seen as a knowledge-based exploratory and evolutionary process. Many models of a design process recognizephases of analysis and conceptual design [2], [3]. There is a variety of sub-activities in adesign process and in this paper we concentrate on the conceptual construction of anarchitecture of the artefact to be designed (ATBD). The architecture forms the skeleton for allsubsequent design stages; design support systems therefore require a representation of thisarchitecture [4]. The fact that design problems are under-defined and open-ended complicatesarchitectural design [5]. Even at the end of the architecture phase many alternatives are leftopen. It is often necessary to consider several of these alternatives and then to compare theirsuitability.

The problem we want to study is how the designer can be assisted in maintaining arepresentation of the ATBD during the early design phases, where he1 has to generatealternatives and to make conceptual architectural decisions. Nowadays, design supportsystems (DSS) are used in this phase. DSSs aim to help designers to maintain complexstructures of requirements, context, alternatives of an ATBD architecture, etc. According to[6], DSSs have to provide support for exploration, evolution, cooperation, integration, andautomation throughout the design process. In order to perform these tasks, many DSSscontain domain-specific models for design knowledge representation and administrationduring a design process. These models, however, may cause a bias towards certain designstyles. This may sometimes interfere with the intentions of the designer, or restrict his creativefreedom.

In this paper we will therefore consider a model for design knowledge representation thataims to be as empty as possible, whereas it should still be useful in taking the administrativeburden off of the designer's shoulders. Also, our model tries to help designers integratecontext, requirements, and alternatives for the ATBD architecture at hand. Furthermore, asour model invites the designer to think in terms of well-defined relations between the variousconcepts he uses, we think that our model also stimulates cleaner thinking about the designproblem. Using the model it is easy to express ideas, but also questions, doubts andalternatives. The model allows documentation in a uniform way by means of well-definedsemantics.

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

ICED 01 - C586/574 139

2 Related Work

Several authors address the issue of (formally) representing design knowledge in multi-disciplinary contexts. Our work is similar to, and partially inspired by, Fujii et.al., [15] in thesense that a state transition model of a design process is used, and properties of the ATDB areexpressed in predicates; transitions are defined by their effect on these properties. Theunderlying modal logic in [15] is based on the work of Brazier [16] et. al. Our model featuresless advanced automated reasoning, since we allow attributes (functions) of concepts that arenot restricted to truth-values; hence we cannot apply formal logic manipulations to the sameextent as [15] and [16]. (See 3.1). Some knowledge, however, that we do represent andmanipulate explicitly comprises various forms of hierarchy. Our model caters for the varioustypes of hierarchical relations that designers use in all stages of design. (See 3.3) Severalauthors explain the role of hierarchies in designing: according to Simon [10], hierarchiesincrease evolution speed and allow the decomposition of the ATBD. Douglas describes how adesign problem can be reduced to a hierarchy of decisions or alternatives [5]. Therefore themachinery behind our model uses hierarchical relations from Object Orientation (OO) [7],extended with some operators to express intentional relations, together with notions fromspreadsheets [8] and symbolic manipulation [9]. (See 3.1) Numerous models of designknowledge representation are based on hierarchical approaches. Such models can be dividedinto 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 setof ISO [11], [12], [13] standards, which provides the exchange of engineering product databetween databases and CAD systems. STEP is built on an information modelling languagethat can formally describe the structure and correctness conditions of any engineeringinformation. The library consists of several parts, each consisting of a hierarchy of instancesof entities in a data model. Examples of parts are classes of physical objects, classes ofaspects of physical objects, etc. Classes of objects have a textual definition but also anintentional definition via a class of properties. Each class has to be associated to another classby types of associations (is-a, used-in, part-of, connected-with etc.). STEP does not supportthe design process of the ATBD. Alternatives to an ATBD architecture can only be partiallyexpressed using optional associations with other classes. There is no computational engine topropagate 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 tomaintain a representation of the design process not only as a historical record of thedevelopment of a design artefact, but as an "active" repository of information. Alternatives arerepresented in the form of the space of design alternatives (SDA). There is also the space ofdesign objectives (SDO) related to SDA. The SDO is used for both generation and evaluationof alternatives in SDA. The model allows the designer to keep track of several designalternatives at a time; evaluating an alternative design against a set of design objectives; andtransparently 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 stillunder development. Still, we think that it is worthwhile to explore a model that has bothdescriptive and prescriptive sides.

3 An operational model for design processes

We propose a model for design processes that should allow denoting design processes for thesake of exercising, researching and teaching cross-disciplinary design skills. Here, 'cross-disciplinary' refers to design situations where several designers with substantially differentbackgrounds have to co-operate. We assume that therefore no single discipline-related designmethodology is available, and both technological and non-technological issues should betaken into account. Our model typically relates to early design stages, when majorarchitectural decisions are taken without the ability to rely on the detailed knowledge that isonly available in later stages. We want the same model to govern requirements, context andarchitectural issues. The model should cope with administrating (the consequences of)alternatives for design decisions, and it must be possible to postpone decisions or revokeearlier decisions. If our model proves to be adequate (which is still to be assessed), it shouldbe possible to give automated support, e.g. to ensure, as far as possible, consistency amongvarious decisions. It should, to a large extent, take the administrational burden from thedesigners 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 kindsof design situations

• the notion of a spreadsheet, as this is a familiar device for incremental 'what-if' -analysisin many disciplines

• the notion of partial and symbolic evaluation (see below), as this allows decisions to bepostponed or revoked. Notice: traditional spreadsheets don't allow cells to be non-evaluated: they cannot propagate expressions, but only the (numerical, logical or alpha-numerical) 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 withpre-defined meanings. Also, the propagation of these meaningsto other cells is well defined. This means that, if the designerdefines or changes the value of one attribute, the values forrelated pre-defined attributes can be updated automatically.The pre-defined attributes come in two sets of 5 (=4+1). Thetwo sets are each other's inverses, in the sense that 'has-a' isthe 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 pre-defined attributes are defined for classes only. They are depicted in the above diagram. Someexamples illustrate these pre-defined attributes: is-a(table) -> furniture; specializes-as(furniture) => table; has-a(table) -> legs; part-of(legs) => table; instantiates-as(my-favourite-chair) -> chair; classifies-as(my-favourite-chair) => chair; needs-a(lamp) ->electricity; causes-a(lamp) -> light; et cetera. The expression after the arrows indicates thecontents of a cell in the table. The user enters expressions after single arrows (->); theexpressions after double arrows (=>) follow automatically from the meaning of one of the pre-defined 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 representsthe 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 (see3.2), evaluation is only partially possible. Indeed, the contents of cells can be more involvedas we will explain below. With our tables, consisting of rows, columns and cells, we representthe design process as a state transition machine. The initial state is a table with 10 columnsand 0 rows. A state transition can be one of: adding a concept (=adding a row); adding anattribute (=adding a column), or modifying the contents of a cell. It is assumed that themodification of a cell immediately invokes updating other cells if the pre-defined semantics ofthe 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 withthe 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 cellsmay contain operators. Operators include: BOTH, ALT (abbreviation of 'alternative'), OPT(abbreviation of 'optional'), IF, ITE (abbreviation of if-then-else), IN, AND, OR, and otherobvious relational operators for Boolean and numerical types. We illustrate some of theseoperators with examples:

• has-a(chair)->BOTH(seat, backrest, legs) gives rise to part-of(seat) => chair; part-of(backrest) => chair; part-of(legs) => chair.

• needs-a(electric-lamp)->ALT(battery,220V). Notice that in this case no automaticdeduction of allows-a(battery) or allows-a(220V) can take place. Also notice that theentries 'battery', '220V, and all other constants are left unevaluated unless the designerconsiders it worthwhile to identify concepts with these terms for further elaboration. Oursystem does not contain any ontological information about the domain; it onlyadministrates 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 aconcept '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 ofITE 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 inthis 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)' doesnot 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 is-a(chair) in other expressions (which may or may not be evaluated in turn). The assignmentof a definite value to any attribute may take place at any time; its effect will immediatelypropagate to all cells that depend on it. Similar, a definite value may be withdrawn at anytime, 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, times-used(room)),lamp) evaluates to 'lamp'. So the operator IN(x, y) is used to check if xoccurs in (the expression) y. If y in turn is a conditional expression, depending oncondition 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 canautomatically deduce A(y)=>E(y). This is consistent with the concept of inheritance fromObject Orientation.

3.3 Transitivity, hierarchies and architectures

The 10 pre-defined attributes, has-a . . . is-caused-by, aretransitive relations between classes. Transitive relations,such as (multiple) inheritance, are at the heart ofhierarchies as they occur commonly in all sorts ofdesign 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. Thenwe can simply write part-of (S1)->S; part-of(S2)-> ALT(S,S1). This allows further argumen-tation where both options are left open for a while. In a similar way, transitivity can be used todeduce about fulfilment of requirements or side effects. For instance, from causes-a(p)->r andneeds-a(p)->s and causes-a(q)->v and needs-a(q)->r we may automatically deduce thatneeds-a(v) => s and causes-a(s) => v. Obviously, these argumentation patterns occurfrequently throughout most design processes. Indeed, design is about the fulfilment ofrequirements, and it is crucial to assess if at a certain stage all requirements are fulfilled. Ourmodel provides a natural mechanism to integrate these argumentation patterns (that involvestakeholders and their attributes and other terms from the context) with argumentation abouttechnological or architectural aspects of the design.

In the next section, we present a 'hand-made' example of a small design process that makesuse of our model. For more realistic examples, a software implementation is indispensable. Atthe end of section 4 we comment on the current status of our prototype.

4 Example

As an example of a system to design we chose a prototype of a dynamic board (d-board.) Themain 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 ordraws on the board synchronously with his oral presentation. Therefore, a snapshot of a boardwith 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 forlater 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 existingboard instead of building a completely new system. The first concepts introduced in the tableare 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 doubtsabout a board size can be expressed as alternatives. For instance, we restrict the board area tomedium (m) and large (1), because these are commonly used in lecturing (step 7). Theauxiliary devices, namely the Marker and the Eraser, are used as tools. Using the IS-Aattribute they are generalized into the more generic concept Tool (steps 8-9). Any latermodification of the Tool will cause automatic modification of both the Marker and theEraser. For instance, adding an attached Wire to the Tool (step 10) causes automaticpropagation of the Wire to the Marker and the Eraser. Notice that all the concepts wehave 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 11we introduce the concept of Understandability, which is of a different kind. It does nothave a specific instance and furthermore it describes a requirement. Despite these bigdifferences we treat all concepts in a similar way. The Understandability will increaseif both video and audio components are present (step 12). After thinking about differentalternatives we came up with the Microphone (Mic) to provide audio and the twoalternatives, namely Camera and Digitizer, to provide video (steps 13-18). In steps19-20 we decide to use a Camera for medium-sized boards and to use a Digitizer forlarge boards. For our purposes a Digitizer needs a special Interface (Int-ce) anda built-in Microphone (step 21). The Interface of the Digitizer can be either wiredor wireless (step 22). However, we know that a wireless interface is more expensive then awired one. To express this knowledge, we add a new attribute Price and assign a value to itthat 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 maintainsconsistency and computes that a Board has a Digitizer with a WirelessInterface; 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 systemto automate the administration of such tables. The core of this system is a parser, anexpression evaluator, and an engine to propagate expressions between cells based on the pre-defined attributes. The first two components are now operational. In order to propagateexpressions, thereby taking the semantics of pre-defined attributes and conditions intoaccount, we propose to use, in every cell, an internal normal form. Such a normal form is alist of all possible return values of a cell (constants or concepts), where for every entry in thelist we administrate the condition for which this value results. This normal form facilitatesmerging 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 interactiontechniques 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 ranknumber; 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 fromthe first to the second entry. Numbers with prime (e.g. 6') result from automatic propagation; in this case step 6gives 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 designsituations where no dedicated design theory or methodology is available. Our approach ischaracterised 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 ideasand using them in test cases with practitioners in order to show their practical usefulness.

References

[1] Banares-Alcantara, R. (1991). "Representing the engineering design process: twohypotheses." Computer-Aided Design 23(9): 595-603.

[2] Hubka, V. "Design for quality and design methodology." J. Engang Des., 1992, 3(1), 5-15.

[3] French, M, J. "Conceptual design for engineers", 1st edition, The Design Council,London, 1971.

[4] Smithers T. "AI-based design versus geometry-based design, or why design cannot besupported by geometry alone." Computer-Aided Design 21, 1989, 141-150.

[5] Douglas, J.M. "Conceptual design of Chemical Processes", McGraw-Hill chemicalengineering series, 1988, 5-20

[6] Banares-Alcantara R. "Design support systems for process engineering. I. Requirementsand proposed solutions for a design process representation." Computers & ChemicalEngineering 19, 1995, 267-277.

[7] Booch, Grady. "Object-Oriented Design with applications." Benjamin/Cummings, 1991

[8] Microsoft Corporation, "a handbook for Excel", Edition 5, Ireland, 1994

[9] Stephen Wolfram, "the Mathematica Book", third edition, Cambridge University Press,1996

[10] Simon, H.A. "The Science of the Artificial", The MIT Press Cambridge, MassachusettsLondon, England, second edition, 1981.

[11] ISO 10303-41, PART 41: "Integrated Resources: Fundamentals of Product Descriptionand 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 processengineering. II. KBDS: an experimental prototype." Computers & ChemicalEngineering 19, 1995, 279-301.

[15] Fujii, H. and Nakai, S.: "On Formal Representations of Multi-Disciplinary DesignProcess." Third International IFIP WG 5.2 Workshop on Formal Design Methods forCAD, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

A COMMON LANGUAGE FOR ENGINEERING DESIGN PRACTICE ANDRESEARCH

A Samuel, J Weir, and W Lewis

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

1 Introduction

This paper is about the language of engineering design. It builds on and extends the evidence andargument 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 asany other spoken language, namely to provide context based interpretative reasoning. This rathercavalier approach to the fundamental tool of design, namely "codified reasoning based onlanguage" has tended to relegate design to a soft discipline. In stark contrast, engineeringscientists have long recognised the need for communicating messages in codified languagedistinguished by the consistent use of concepts, e.g. shear stress, strain energy, angularmomentum in mechanics. Codifying information in clear and unambiguous terminology results ina 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 andconcepts, so that there is then established a common currency of communication betweendesigners and researchers internationally. In the paper examples are given to demonstrate that inthe absence of such a language discordant communications occur which retard research effort andimpair intellectual progress.

The authors have therefore embarked on a programme to develop a common language - aunilateral initiative at this stage but to be extended in the future to invoke the collaboration of theinternational 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 whichdefinitions have been offered for international critique on our web site. The paper then identifiessome of the paradoxes and difficulties which are inherent in this research.

ICED 01 - C586/095 147

2 Characteristics of a Design LanguageStructure. In engineering science it is commonplace for ideas and concepts to be developedin a sequential manner over a period of time. In mechanics, for example, one can construct aconcept 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 amap is dominated by a characteristic flow of ideas. Design concepts, on the other hand, lack thissequential development, as is evident when a concept map is constructed to show the inter-relationships between the terms identified and listed in [1]. It cannot be too strongly emphasisedthat the absence of a dominant sequential flow is a fundamental difference between the languageof 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 andresearchers, but also for recording the results of research for posterity.

Influence of related disciplines. The presence of overlaps and borrowings of concepts fromother disciplines is a complicating factor. Engineering design is a young, emerging discipline andas such must inevitably borrow terminology from other established related disciplines. Suchborrowings must be continually monitored to ensure that the focus and integrity of engineeringdesign as a discipline in its own right are not debased or downgraded. The need for suchmonitoring is one of the major themes of this paper.

Multilingual Background. The engineering design research community is international, andrecords its deliberations in a range of languages. Important fundamental concepts in engineeringdesign have often been first enunciated in languages other than English. Given that shades ofmeaning are difficult to transmit with precision between different languages, the task of clearlydefining and exemplifying the meaning of terms in design multilingually presents an on-goingchallenge to researchers.

A paradox of language used in design research . Researchers seek precision in the expressionof ideas and argument and in the presentation of results, whereas imprecise thinking is embeddedin the practice of designing The designer lives and works in an uncertain world - the designer hasto cope with inherent uncertainties about the exact nature of the client's needs and whether his/herresponse will deliver the outcomes predicted. The very business of creation is imprecise. DeBono has drawn attention to the way creative people use "porridge" words to keep thinking goingin an intellectually murky environment when confronted by an apparent dead end [3]. Designresearch demands consistency of definition, consistency of logic; design practice acceptswhatever is required to achieve progress towards a satisfactory solution [4].

3 The CADENCE Project: Desirable Attributes of a UniversalDesign Lexicon

Our primary objective in this exploratory article is to develop a collective ownership ofterminology (nomenclature and concepts) within the design community. We seek to engenderopen 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 DesignEngineering 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 waythat will reduce noise and the invention of new and unnecessary terminology in ourcommunications.

We have argued that it is important that design researchers have access to definitions that areexchangeable across linguistic barriers, and whose meanings are demonstrated by multipleexamples. We consider the requirement for exemplified definitions to be crucial to the successfulcompilation of a lexicon of engineering design terminology. The CADENCE project atMelbourne seeks to embody the following desirable attributes:

1. Exemplified - each definition should be accompanied by several examples, preferably drawnfrom diverse fields of engineering design practice;

2. Simple - in accordance with the advice of Niels Bohr that "You should never speak moredearly than you think", the definitions should remain as plain and straightforward aspossible. 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 bewidely accepted;

3. Extensible- additional terms are easily admitted ;

4. Web-based - access to the lexicon, both for reference and for proposal of new terms, shouldbe through the world-wide web;

5. Commonly agreed - building of the lexicon should occur collaboratively through argumentand agreement between peers;

6. Scholarly - definitions should identify the proposing authority, with examples of usage fromthe engineering design literature;

7. Harmonised - where divergent usage of a design term is noted, or where multiple terms are inuse 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 allowsmultilingual definitions and cross-references to be added in collaboration with theinternational design community;

10. Moderated - definitions moderated by the lexicon maintainers so as to maintain structure,consistency and order.

4 Design reasoning as language translationWhen travelling abroad, people make use of several language devices to permit communicationwith the natives of foreign countries. One often learns common phrases or words in the foreigncountry's language to allow one to communicate even simplest of requirements, such as "whereis the bathroom?" or " I need some butter". English speakers have been spoiled by the fact thatmost 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. Tobreak 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 needsinto design requirements. We essentially spoil our clients by trying to speak their language ratherthan our own. In doing so, however, evaluative designers must be especially aware of the dangersof 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 thanthe performance of it) is precise design communication. If at all possible, we need to avoid themany experiences of "Chinese whispers" either imported from other disciplines or developedwithin 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 designrequirements. The terminology used to fill in the product planning matrix is "translating from thewhats to the hows". We conjecture that the commonly agreed design code for the "hows" iscriteria, 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 designpidgin has a lot to do with the apparent formal coding offered by QFD. In reality there is nothingmysterious about QFD. Yet the use of invented terminology to descripe its concepts andprocesses 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 totechnically 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, thatdepartment of metaphysics which relates to the being, or essence of things, or to being in theabstract.

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 senseof classification of domain specific knowledge. Some examples follow:

With an ontology, keywords and database concepts can be organized by capturing the semanticrelationships among the keywords or among the tables and fields in databases. The semanticrelationships provide an abstract view of the information space for offices [6].

Ontology annotation ... the organization and representation of such experiences must be definedin 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 ofknowledge.

Clearly the term has been adapted into design from the AI community, with whom we havesubstantial common ground (see for example [8]). Equally clearly, the AI community and someusers within the design community have some agreed meaning assigned to this term. Yet its newagreed meaning is so divergent from its original interpretation, and so unnecessary that it justadds noise to an already noisy channel of communication in design.

150 ICED 01 - C586/095

Axiom - from the Greek a£iwua - 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 substantivedeductive argument, exemplified by the development Euclidean geometry.

Axiomatic design [9] seeks to establish some self evident truths (axioms) that will lessen thecognitive load of the designer in delivering (mapping) from designand to designal. Two typicalaxioms 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 thatno substantive deductive argument has resulted from "axiomatic design". One can certainly adoptclear and unambiguous observations about design. Calling these observations "axioms " tends toadd further confusion to the agreed language of the discipline.

5. Constraints on commonly agreed design terminology and conceptsInvariably design proceeds from a need, through many conflicts, to some comprehensivestatement 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 criticallyimportant human-directed aspect of designing that ultimately determines the majority of thefeatures of the design result.

The whole process is moderated by the level of wisdom the designer has about the domain ofknowledge within which the design proceeds. Gaining wisdom in engineering design, whetherdomain-specific or general, is a process that is low in procedural content and is often difficult toarticulate.

This is the portion of the whole design experience least subject to rational analysis. Broadlyspeaking, the engineering design discipline is an embodiment of current engineering culture. Inthat sense, it encompasses the current practices, ethics and linguistic character of all that existsand 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 thedevelopment of the rest of the concepts and terms that grow from them. These "atomic" buildingblocks of words will permit free translation between concepts and terms expressed andexemplified by design researchers in their deliberations. One of the key objectives of theCADENCE project is to provide these translations in a clear and unambiguous way. In thesemantic representation of knowledge [11] a "zero order" theory is a building block used todevelop higher order theories.

A major obstruction to clear communication is the lack of differentiation between design the verband design the noun. In other languages there may be some useful distinction (in German wehave Konstruktions and Konstruieren), but in English there is a clear need to distinguish betweenaction and subject. As a possible set of identifiers we offer the following definitions:

Designand: the collection of goal, requirements, criteria constraints and wisdoms (heuristics) thatrepresent 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 ofintegration we have a "subject of integration", the integrand, the integration process that acts onthe integrand and the result which is the integral. The terms designand, design and designalmirror 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 withdesignand, designal and design as the fundamental entities from which the whole compendium ofdesign code might be constructed.

We consider the following terms the most basic, "zero order" representation of design knowledgefrom which other higher order knowledge representations may flow (in approximatelyhierarchical order):

• goal (design goal): the primary functional objective of the designal (usually expressed interms of a design need).

• need (design need): expression of a means for solving a problem, without reference toembodiment (e.g. "a means of removing dirt from clothing", instead of "a washingmachine ").

• objectives: desired features, or characteristics of the designal, that determines its ultimateeffectiveness or suitability for a given task (e.g. the driver's seat should be comfortable; thecan opener should be safe, cheap and portable).

• conflicting objectives (also, occasionally, competing objectives): design objectives thatnegatively influence each other (e.g. low mass coupled with high strength, large volumecoupled with small surface area; high reliability coupled with low cost).

• compromise: arbitration between conflicting objectives (e.g. accepting an increase in mass fora 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 haveseen various meanings ascribed to this term including objective, requirement and evenconstraint. A criterion is a clearly identified scale or measure associated with a designrequirement. It may be subjective (e.g. comfort may be evaluated on a subjective survey scaleor, in the case of the bed of a quadriplegic, by the number of bedsores generated per unittime) or concrete (e.g. maintainability measured by mean time to failure or mean time torepair).

• constraint: mandatory requirement to be fulfilled by the design (e.g. must be manufactured inAustralia; must meet Federal Drug Administration Authority requirements, must beconstructed in stainless steel).

• restriction(in fact, a relaxable constraint): non-mandatory, flexible, designs limit (e.g. "thecost 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, butindirectly determined by the values of the design variables) that describe the performance of asystem 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 aproblem (e.g. material property limitations —"required yield strength = 1 GPa; requiredoperating temperature = 2000°C"). As a degenerate example of discordance, the perpetualmotion machine is a very (intractably) difficult problem because of the irreconcilablediscordance between its requirements (that the system is closed and energy is to becontinuously extracted from it) and physical reality (the first and/or second laws ofthermodynamics).

As an example of how we may use these "zero order" terms to develop and exemplify higherorder concepts consider QFD as described above.

QFD seeks to use a formal procedure to translate from a design need to design objectives, withinthe specified set of constraints. It also seeks to identify and resolve conflicting objectives andestablish precise restrictions and criteria.

5 ConclusionsThe adoption of an agreed, codified terminology is essential for the advancement of engineeringdesign as a scholarly discipline. A programme to develop such a terminology has been initiatedby the authors and a set of 100 definitions proposed as the basis of a Commonly Agreed DesignEngineering Nomenclature: Concepts and Examples (CADENCE) project. The 15 most basic ofthese terms are discussed in this paper.

It is further essential that proposals for inclusion in the CADENCE lexsicon, whether from theauthors or from other researchers, be critiqued by the community of design practitioners andscholars. To this end the web site <http://www.mame.mu.oz.au/eng_design/language/> has beenestablished to ensure that as wide a cross-section of the design community as possibleparticipates, agrees to, and so owns the results.

There are similarities and differences between the proposed CADENCE lexicon and the acceptedlanguages of engineering science. Similarities arise from the common need for clarity andprecision, but there is one significant difference: the sequential flow of ideas which is inherent inscience and dominates scientific language is absent in engineering design. It may be conjecturedthat this is a major reason why engineering scientists have difficulty in accommodating theirthinking to the complexities of engineering design.

An equally important objective is to harmonise the communication protocols adopted by designresearchers in a way that will reduce noise and the invention of new and unnecessary terminologyin our communications. Progress towards this aim can be achieved by various means includingthe following:

1. contributions to the CADENCE project by the design community;

ICED 01 - C586/095 153

2. a monitored web site fully accessible by all. The Melbourne website has a starter list ofapproximately 100 design terms and concepts. Additions and modifications from thedesign community are welcomed;

3. written contributions by snail or e-mail to design@unimelb.edu.au. All contributions mustbe accompanied by examples, and all contributions will be published and discussed;

4. contributions to design journals and proceedings should be to be monitored by the editorsto 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.

[2.] Geldenhuys, A.E., van Rooyen, H.O. and Stetter, F. Knowledge Representation andRelation Nets. Boston:Kluwer, 1999.

[3.] De Bono, E. Practical Thinking. Penguin Books, Harmondsworth, 1976.

[4.] Simon, H.A. Sciences of the Artificial. Cambridge, Mass: M.l.T. Press, 1969.

[5.] Clausing, D. (1993) Total Quality Management. New York: ASME Press

[6.] Huhns, N.; Stephens, M.; IEEE Internet Computing v3 n5 1999 IEEE Piscataway NJUSA p 85-87

[7.] Landes, D; Schneider, K; Houdek, F; Int. J. of Human Computer Studies v51 n3 1999Academic Press Ltd London Engl. p 643-661 1071-5819

[8.] Gero, J. S. (ed.) (2000b) Artificial Intelligence in Design'00. Kluwer, Dordrecht, 719pp

[9.] Suh, N. P. (1988) The Principles of Design. Oxford:The University Press[10.] 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

[11.] Minsky, M. (1975) A Framework for Representing Knowledge. In The Psychology ofComputer Vision. Ed. P. Winston. New York: McGraw Hill

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-8784aes@mame.mu.oz.au

(c) IMechE 2001

154 ICED 01 - C586/095

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

USING SITUATION THEORY TO MODEL INFORMATION FLOW INDESIGN1

Z Wu and A H B Duffy

Keywords: design information management, information representation, ontology

1 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, ourvery 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 empiresare 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 appropriateinformation is required. Sonnenwald [2] identified 13 communication roles that emergedduring four multidisciplinary design situations in the USA and Europe. She stated thatparticipants from different disciplines, organisations and cultures come to the design situationwith pre-existing patterns of working activities, and specialised work languages. Differentmethods to represent information flow activities are used, varying in different companies,different disciplines, and different teams, which may cause misunderstandings particularlyamong design teams composed of different organisations. In this sense, it is important topresent information flow in a rigorous way. Eastman and Shirley [3] developed a model ofdesign information flow. The model dealt with design information management, reflectingentities, constraints, design states, design document accessed modes, transactions, andversion identifiers. But, the development of their model was not based upon a theoreticalfoundation. In this paper, we develop an alternative model to present information flow indesign based on a foundation of situation theory. The model may serve to analysis designinformation system and provide a basis for investigating the situatedness of designinformation flow.

To be able to represent information flow we should firstly study its phenomena. Based onSim's formalism of design activities [4], the theory of Speech Acts [5,6], Computer SupportedCooperative Work (CSCW) [7], and other works [3, 8, 9] studying information flow, anexample model for information flow in design is developed. A discussion of the strengths andweaknesses of this representation method is carried out.

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

ICED 01 - C586/185 155

2 Situation theory

Situation theory has been described as a mathematical theory designed to provide a frameworkfor the study of information [1]. It grew out of work on semantics of natural language byBarwise 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, temporallocations, 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 computersystem, or machine) that hold, or link together specific numbers of, certain otheruniformities; denoted by P, Q, R...

• spatial locations - regions of space; they may overlap in time or space, or one location maywholly 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), andIND (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 inthe 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 includingspatial and/or temporal locations), and 1 or 0 reflect that individuals a0, ..., an do (1), or, donot (0), stand in the relation to R. Infons are 'items of information', which are not things thatin themselves are true or false. Rather a particular item of information may be true or falseabout a 'situation'. Given a situation, s, and an infon, a, we write s ||= a to indicate that infon ais 'made factual by' the situation s, or a is an item of information that is true of s. Thus, ssupports a. In future work, the criteria will be defined to evaluate whether s supports a.

3 A example model for information flow in design

Design is concerned with processing information [8]: external information is in the form ofcodes of practice, design guides, product specifications, etc., that is used, along with theknowledge of the design team, to create another "internal" information set which forms thedesign. Within the context of collaborative design, Sonnenwald [2] explored thecommunication roles in the design process. She stated that different specialists build on theirpast 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 integrateknowledge about the current (and evolving) artefact context, design context, and technical andscientific knowledge, and create new artefact, technical and scientific knowledge, and designexperience [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 differencebetween knowledge and information. They defined information as processed data, andknowledge 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 thatknowledge in agents change while participating in information flow.

In the domain of CSCW, there is considerable work studying information flow in design. Theword "co-operation" suggests two or more participants communicating with one another.They carry out studies from different perspectives to improve the performance ofcommunication. However, there is no generic model for information flow reflecting thephenomena of knowledge increment. This paper attempts to develop a model of informationflow reflecting the phenomena of knowledge increment in agents, with consideration ofsenders and receivers, input information, goals and the knowledge state changes (See figure2).

Sim developed a formalism for design activities based on the corpus of published researchwork (see Figure 1) [4]. In his formalism, design knowledge, domain knowledge andknowledge 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 modifiedor generated. The general goal of the design activity (Dg) is to reduce the complexity of thedesign problem. But, Sim's work focused on only a single agent. Information flow involvestwo or more agents. Sim's formalism for a design activity does not generalise the phenomenaof information flow in design. However, it can provide a starting base. During the process ofinformation flow, both sender(s) and receiver(s)2 may provide information to each other, andafter interaction, their knowledge states may change. In a collaborative design context, bothsender(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 communication3 alone, but ascommunication with a purpose. That is, goals exist in agents in information flow. It issuggested that not only there should be a goal or a need for interaction4, but also goals for

2 After receiver(s) get the information from sender(s), reply(ies) may bo required in some occasions and may notbe 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 withthe concept used in Sim's model, and interaction is a broader concept than "information flow".

ICED 01 - C586/185 157

agents to participate in the interaction. Take for example during the design process agent a, adesign agent, receives information from agent b, a manufacturing agent, and agent c, adisposal agent. Both agent b and c provide their need or goal to the product design. In thiscase, agent a, b, and c's goals are to provide an optimal design in the perspectives of productdesign, manufacturing, and disposal, while the goal of interaction is to providing an overalloptimal product design with consideration of these three perspectives. It is suggested thatthere 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 betweenagents, output knowledge (known as the change of knowledge states in agents) may beproduced. In this example, the senders are agent b and c and the receiver is agent a. They havetheir own goals. The goal of interaction is fulfilled by compromise of its participants' goals iftheir goals conflict. Given this, a simple model of information flow can be developed asshown Figure 2. The model includes input information of sender(s) (Iis), input information ofreceiver(s) (Iir), interaction between agents (INTa), output knowledge of agents (Ok), the goalof interaction (Gint), the goal(s) of sender(s) (Gs), and the goal(s) of receiver(s). Outputknowledge 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, inter-organisational 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 oftraditional engineering design. Through their work [2,8], it can be concluded that participantsin 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 inputinformation based on the theory of Speech Acts [5, 6], which studies the philosophy oflanguage. In studying the problem of how many ways of using language, Searle found thatthere 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 astate of affairs or a statement.

• Declarations. Brings about the correspondence between the proposition content andreality. For example, if a designer successfully performs the act of finishing the design of acomponent, then the component has been designed.

Based on these basic categories of illocutionary acts, we can categorise the input informationof both sender(s) and receiver(s) (Iis, Iir), the goals of sender(s) and receiver(s) (Gs, Gr,), thegoal of interaction (Gint), and the change of knowledge that may be derived from them (seeTable 1).

4 Representation of information flow with Situation Theory

In this section we use situation theory to represent information flow based upon the modelpresented in section 3. As there are five illocutionary acts in conversation, every agent'scommunication with other agents may fall into such illocutionary acts. Suppose there are agroup of agents (more than two) involved in a communication then the representation ofinformation flow with situation theory may be summarised by a formalism as shown in Table2, from which other representations may be derived. For example, the expression "Agent a1believes 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 thatagent 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, wecan 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 inlocation l.

Thus far, we have presented a representation of information flow in the design process basedon a well-founded method, situation theory. Such an approach may help minimisemisunderstanding in the research community when studying information flow in the contextof 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 flow5

Input informationSender(s)

Iis

• Assertives

• Directives

• Commissives

• Expressives

• Declarations

Receiver(s)Iir

• Assertives

• Their (its)capability

• Evaluatesender(s)intention

• Expressives

• Evaluationto thedeclarations

Goal of sender(s)Gs

• Input assertives

• Assigning theright tasks to theright agents.

• Informingintention(s)

• Providingexpressives

• Sendingdeclarations

Goal of interactionGint

• Compromisingdifferentassertives

• Optimisingassignment oftasks

• Sharing andevaluatingintention(s)

• Compromisingdifferentexpressives

• Sharingdeclarations

Goal of receiver(s)Gr

• Evaluate or/andinput assertives

• Informingsender(s) itscapability

• Knowing sender(s)intention andprovidingevaluation to its(their) intention(s)

• Providing its(their)expressives orevaluatingsender(s)expressives

• Sending feedbacksto the declarations

Knowledge change

• New assertives

• New knowledge oftask assignment

• Sharing intention(s)

• Sharing expressives

• Knowledge of thechanging designenvironment

5 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 adesign 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 agentb, 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. Representation of information flow with situation theory

Illocutionary ActsAssertives

Directives

Commissives

Expressives

Declarations

Representation«assert, a1, a2,

«direct, a1, a2, . . ., an,

«commit, a1, a2,

«express, a1, a2,

«declare, a1, a2,

. . ., an, si,

b1, b2, . . .

an, t1

. . ., an, dl

. . ., an, c1

S2, .

, bn,

, t2,

, d2,

, C2,

. ., sn, 1»

t1, t2, . . ., tn, 1»

. . ., tn, 1»

. . ., d3, 1»

. . ., cn, 1»

MeaningAgents 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, . . .,

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

d2, . . ., d3.Agents a1, a2, . . ., an declare changes of the

environment c1, c2, cn.

5 Strengths and weaknesses

Situation theory is a formal tool to study information flow in linguistics. The advantage ofusing this theory is it provides a well founded way to model information flow in design. It canserve as a tool to minimise misunderstandings of design information flow. It may also providea way to represent and analysis an information flow system. Such a representation system mayprovide a clear understanding of the input and output knowledge of the agents and where theknowledge comes from and goes to. What's more, it serves as a basis for investigating thesituatedness 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 toits situation. With consideration of time t, location l and situation s, the information flowchanges as time, location and situation change. One situation may support certain type ofinformation flow. But another situation may not support the same type of information flow. Itis intended that the relationships of situations will be studied and the links between the changeof situations and the change of information flow developed.

Although the method of situation theory may bring some benefits, a weakness of this methodis also identified: the theory is not widely known. Situation theory is originally developed inthe 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 designpractice. But, it is suggested that the model and theory developed in this paper may act as aconceptual framework for modelling information flow and developing CSCW systems.

6 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 efficientmanagement of information flow can play a vital role to ensure a successful productdevelopment. In this paper, a method, situation theory, is used to represent information flow indesign, and provides a more formal and well-founded method for representation ofinformation flow, with the purpose of minimising misunderstandings, a means of analysisinformation flow. In this paper, based on Sim's formalism of design activities, the theory ofSpeech Acts, CSCW, and other works studying information flow, an example model forinformation flow was developed.

ICED 01 - C586/185 161

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

7 Acknowledgement

We are indebted to Professor John Gero, Key Centre of Design Computing, University ofSydney for bringing to our attention his work on situatedness in design which stimulated ourinterest in this area.

References

[1] Devlin, K., Logic and information. 1991, Cambridge University Press.

[2] Sonnenwald, D., Communication roles that support collaboration during the designprocess. Design Studies, 1996, 17: p 277-301.

[3] Eastman, C., and Shirley, G., Management of Design Information Flows, inManagement of Engineering and Management Perspectives, S. Dasu and C. Eastmaneditors. 1994, Kluwer Acacemic Publishers. p255-277

[4] 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.

[5] Searle, J., Expression and meaning: studies in the theory of speech acts. 1979,Cambridge University Press.

[6] Searle, J., Speech acts: an essay in the philosophy of language. 1969, CambridgeUniversity Press.

[7] Dix, A., Computer support cooperative work: a framework, in Design Issues in CSCW,C.H. Duska Rosenberg editors. 1993, Springer-Verlag. p. 9-26.

[8] Morse, D., and Hendrickson, C., A communication model to aid knowledge-baseddesign systems. AI EDAM, 1990. 4(2): p. 99-115.

[9] Macleod, A., and McGregor, D., Accessing of information for engineering design.Design Studies, 1994. 15(3), p 260-269.

[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 Situationtheory and its application, Vol 3, David Israel, Peter Aczel, Yasuhiro Katagiri, StanleyPeters editors. 1993, Stanford University, p 213-264.

[12] Giarratano, J., and Riley, G., Expert Systems: Principles and Programming. 1998, PWSPublishing Company.

Zhichao Wu

CAD Centre, DMEM, University of Strathclyde, 75 Montrose Street, Glasgow Gl 1XJ, UKPhone: +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 DESIGNICED 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

1 Introduction

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

2 Analysing Vague Shape

To pattern match and cluster vague shapes we must firstly identify the types of vagueness thatmay occur during geometric sketching. Then the criteria for identifying a cluster must bedefined. Various methods address the problem of shape analysis as summarised in Tables 1and 2. However, these methods consider precise shapes and are not appropriate for vaguegeometry. The following types of vagueness in conceptual geometric shapes cones in avariety of ways, as identified below [3].

• Vague position of a line segment - In figure 1, because the line positions are not clearlyexpressed, we encounter two types of vagueness. Firstly, the open/closed status of theshape type is vague. It also includes the uncertainty of whether the ends of two lines meetto form a vertex. Secondly, the size of each element (i.e. a line segment) is vague. Forexample, the size of the right vertical line of the sketch in figure 1 will be determined bywhether 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 andshade, recognising a vertex as a 3D convex or concave shape from 2D sketches can bedifficult. This type of vagueness occurs frequently in 2-D sketches of 3-D objects becauseof 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 thanone feasible interpretation of the shape. For example a line element may be interpreted asa 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, thedistance between this and another object is vague. Figure 4(a) shows the possible relativespatial 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 maximumboundaries, the intersection status between two objects can be recognised as vagueintersection, intersection and non-intersection. In addition, a sketch representing 3Dspatial 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 berecognised 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])

Shapeboundary

points

Boundary (external)algorithm

Global (internal)algorithm

numeric or non-numeric Scalartransform technique

Information preservation

Shape boundaryFourier transforms of the boundaryMedial axis transform (MAT)Moment based approachesShape decomposition into other primitive shapesVarious fourierMoment-based approachesAllows an accurate reconstruction of a shape.

Table 2. Summary of the existing visual perception methods (summarised on the basis of [5])

Theory Classification

Tra

diti

onal

Mod

ern

Gestalt theoryGibson's theory

NeuropsychologicaltheoryFractal geometryHigh curvature pointsLowe's system

Marr's paradigm(shape from x)Morphogenesis

Polygonalapproximationof shape

Symmetry-Curvaturetheorem

The principleof transversality

NoteA non-computational theory of visual form.Concentrated around perceiving real three-dimensional objects asreal 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 viewpointsand single two-dimensional images.Extended as Shape from shading, contour, texture, stereo, andfractal geometry.A procedure for morphogenesis based on multiple levels ofresolution has been developed.Applied as- Combination of high curvature points and line segmentapproximations.- 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 eachother, the meeting point is a boundary point of concavediscontinuity of their tangent planes.

3 Clustering and Customised Viewpoints

Computational clustering is performed using machine learning techniques. According toReich [1], machine learning can be considered as explanation-based learning (EBL) orsimilarity-based learning (SBL). Because the ill-structured nature of design often precludesformalised theories of synthesis it has been suggested that SBL is more suitable forconceptual design [1]. There are two primary classes of machine learning techniques in theSBL approach: supervised concept learning and unsupervised concept learning. Supervisedrequires the user to support the learning process whereas learning is automatic inunsupervised.

As Gordon [6] argued, markedly different results can be obtained when the same data set isanalysed 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 beinginvestigated.

Manfaat [2] presented an approach, Customised Viewpoint-Spatial (CV-S), to support theeffective utilisation of spatial layout design experience by generalising past spatial layoutdesign cases and abstracting a single case into hierarchical levels of abstractions according tothe designer's needs. He argued that the layouts of a space can be hierarchically clustered intogroups based on the measures of similarities between the layouts. An example of differentviews 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 theactivity of matching patterns with the aim of finding similarities between them for the purposeof 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 thegroup members to reflect knowledge common to all in the group.

4 Multiple Clustering of Shapes

4.1 Clustering Vague Shape

A vague geometric shape can be identified by a hierarchy of shape probabilities ([3]). A child-element 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 isthrough using probability. Consider an object in a sketch that has n elements (see [8]). Thevarious possible alternative interpretations for each child-element can be represented in ahierarchical 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 bymutiplying the probability of the element belonging to the appropriate group at each levelleading down to the primitive in question. For example, in Figure 6, the (n)th element ofobject A has a 0.2016 probability to be a Closed-Polygon-Triangle derived from itsprobability 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. Forexample, if a designer needs to analyse a sketch stroke as abstracted symbols, rather than ageometric shape element, they could change or add some levels and specific classes. Also, thelevel of the hierarchical structure could be extended to represent a compound object that ismade from more than one object. A distinct advantage of working in this way is that thecomplex task of analysing the shape type is reduced to a relatively simple and manageableone through determining the probability at each level, regardless of how complicated theobject, and, ultimately the whole sketch, is.

This classification hierarchy may provide clustering criteria of a vague geometric model asshown in Table 3. However, this requires further investigation.

ICED 01 - C586/273 167

Table 3. Classification Criteria for Clustering

Criteria

Main

ca

cb

Cc

cd

Ce

cf

Sub

Ca-1

Cb-1

Cb-2

Cc-l

Cd-1

Ce-1

Ce-2

Ce-3

Definition

:= has child elements

= has a number ofchild elements= has sub-objects= has a number ofsub-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 aprimitive.:= 1st level primitives

:= 2nd levelprimitives:= 3rd level primitives

:= has a relativespatial relationship

Description of Criteria

Classify an object by a presence of child elements. If anobject does not have any child element, the object is mostlikely a primitive shape.Classify an object by a number of child elements if theobject has any children.Classify an object by a presence of sub-objects.Classify an object by a number of sub-objects if the objecthas 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 objecthas three-dimension. A number of surfaces are analysedby the status of edges.Classify an object by the probabilities of each primitive.

Classify an object by the probabilities of 1st levelprimitives such as "closed" and "open".Classify an object by the probabilities of 2nd levelprimitives.Classify an object by the probabilities of 3rd levelprimitives.Classify an object by the relative spatial relationshipsbetween sub-objects.

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 asmany 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] insistedthat 'discovering hidden features in a representation without being fixated to a singleperspective of viewing' is one of the crucial acts in creative activities.

Vague shapes may also be clustered differently depending on different viewpoints. Considerthat objects A and B have various properties {Al Ca, Cb, Cc, C d }and {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 beclassified in a different cluster.

4.3 Shape matching

SPIDA matches topological patterns of layouts and the combined topological patterns andgeometric shapes of layouts [2]. To illustrate the system's functionality Figures 6 and 7 eachshow 4 past design layout (cases), the former for topological matching and the latter forcombined 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 readeris invited to determine which cases best match the required layouts. You should attempt todecide the order of similarity of the layouts by determining for topological matching the casesthat most reflect the required layout, where space B is adjacent to space C which is adjacent tospace D, etc. For the geometric shape matching you should consider the overall shapes of thespaces and how they are related.

The results of the topological matching between each of the past design cases and the requiredlayout are shown in Table 4. In this table, for each case, the layouts are ordered from themost to the least similar. This order is based on an analysis of corresponding spaces. If thereare more than one layout case that has the same number of corresponding spaces, they havethe 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 thecases 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 arethen ordered based on a shape dissimilarity measure. The lower the measure the more similarthe layout case is to the required.

Table 4. Results of Topological Pattern Matching Table 5. Results of Geometric Shape Matching

Orderedcases

Case 1Case 4Case 3Case 2

Number ofcorrespondingspaces

7

64

Orderedcases

1234

Number ofcorrespondingspaces

4

3

Shapedissimilaritymeasure

0.000.470.230.29

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

5 Conclusion

Shape matching is a of key element in clustering geometric shapes. In this paper, wediscussed about the clustering, customised viewpoints, and pattern matching regarding ofshapes. 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 desiredto define the shape type of the geometric object. Work is on-going to develop the techniquespresented in this paper and for a system to support the re-use of past design shape cases.

References

[1] 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

[2] Manfaat, D., A.H.B. Duffy, and B.S. Lee, "SPIDA: Abstracting and generalising layoutdesign cases", Artificial Intelligence for Engineering Design. Analysis andManufacturing (AI EDAM). 12: 1998, 141-159

[3] 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 theInternational Journal of Artificial Intelligence in Engineering, 2001. (to be published)

[4] Pavlidis, T., "A Review of Algorithms for Shape Analysis", Computer Graphics andImage Processing. 7: 1978, p243-358

[5] Loncaric, S., "A survey of shape analysis techniques", Pattern Recognition. 31 (8): 1998,p983-1001

[6] Gordon, A.D., "Hierarchical Classification, in Clustering and Classification". 1996,p65-121

[7] Manfaat, D., A.H.B. Duffy, and B.S. Lee, "Review of pattern matching approaches",The knowledge Engineering Review. 11:2: 1996, p161-189

[8] Lim, S., A. Duffy, and B. Lee, "Intelligent computational sketching support forconceptual design", International Conference on Engineering Design (ICED'0l).Glasgow, UK. 2001 (submitted)

[9] Howard-Jones, P.A., "The variation of ideational productivity over short timescales andthe influence of an instructional strategy to defocus attention", Proceedings ofTwentieth Annual Meeting of the Cognitive Science Society. 1998

[10] Duffy, A.H.B. and S.M. Kerr, "Customised Perspectives of past designs from automatedgroup 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 discoverhidden features in sketches", Visual and Spatial Reasoning in Design. 1999.

S W LimCAD 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

THE PRODUCT DEVELOMENT PROCESS ONTOLOGY - CREATING ALEARNING RESEARCH COMMUNITY

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

Keywords: Research Cumulation, Classification, Indexing Research

1 Introduction

In a prior paper, we argued that the inherent complexity of product development research, andthe variation in research methodologies and settings result in the lack of qualitativecumulation of research findings, and advocated the need of applying an ontological approachto overcome the problem [1]. Specifically, we developed an initial ontological framework tofacilitate the sharing and comparison of methods, variables, and results. Furthermore, weillustrated our approach by feeding the findings of published studies into the proposedframework as concrete examples. Our data set consisted of the findings from 19 paperspublished as the Delft Protocol Workshop [2].

In this paper, we test and develop our initial ontology further by applying it to a much largerdata set: all of the papers published in the proceedings of the International Conference onEngineering Design, 1999. Naturally, the broader and more comprehensive scope of the newdata set challenges our assumptions and framework. In this study, our goal is to devise arepeatable validation method that improves the initial ontology. Our ultimate goal is to applythe resulting validation method repeatedly in order to make the ontology comprehensive andconsistent.

2 The Ontological Approach

An ontology can be defined as the specification of a conceptualization [3]. That is, anontology 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 anabstract, simplified representation of the area of interest. In our context, an ontology becomesa specification medium accessed by researchers for making ontological commitments. Itsaffordance is the consistent communication in a domain of discourse without necessarilyoperating on a globally shared theory.

The term "ontology" is mostly applied in the development of large, enterprise-wideinformation systems to support consistent product development across a geographicallydistributed organization. This is achieved through the use of a pre-defined ontology thatenables enterprise-wide consistency and commonality through the interoperability ofprocesses, 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 forexample functional concepts [5].

Ontologies are often equated with taxonomic hierarchies of classes, however, ontologies neednot to be limited to these forms. Within the field of product development, several attemptshave been done to apply a taxonomic approach. Our initial attempts at composing aframework were built on a similar taxonomically understanding. However, after preliminaryanalysis of data, we decided that an ontological approach would give us more freedom inachieving our goal due to the looser and pragmatic structure it entails.

3 The Initial Ontology

The examples mentioned above are all characterized by a high degree of formalization due totheir focus on computer integration. We intend to apply the idea of ontology in a lessformalized way because we are interested in a conceptual representation of productdevelopment 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 researchgroups from several countries enabled us to formulate an initial structure of objects, mainattributes, and sub attributes cf. table 1.

Table 1. Initial Ontology for "Product Development Process".

ObjectsActors

Activities

Information

Artifact

Environment

Main AttributesSkillsKnowledgeRoles

MotivationValuesEmotionsClass ParadigmCognitive Information processing

Problem-solvingDecision-making

Function-evolutionProblem-solution interaction

Social Mediation

Information sharingPhysical Object-engagementRepresentationLevel of detailLevel of abstractionSourceInterpretation (context)

PropertyPerformancePositionOrganizationPhysical layout

Sub Attributes/Thesauristructural, discursive, expertexperience, common sense, explicit, implicit, episodicchair person, monitor, summarizer, note taker, time-keeper, expert, chief designer, project manager, designercommitment, goalsviews, preferencestensionActiongathering, recognizing, accessing, visualizing, perceiving,reviewing, managingadopting, referring, proposing, structuring, generatingexamining, analyzing, synthesizing, reasoning, inferring,deducingdecomposing, reinforcingevaluating, checking, testing, monitoringcontrolling, conflict handling, negotiating, persuading,arguinglistening, speaking, documentinggesturing, moving, touching, riding, wearingverbal, graphic, textual, physicalambiguousabstract, concreteinternal, externaldecision, alternative, criteria, arguments, problem,solution, concept, methods, constraints, intentiongeometry, materialfeature, function, structure, behavior, stateappearance, feel

172 ICED 01 - C586/361

The conceptualization of the phenomenon "Product Development Process" has stronganalogies to the problem of modeling processes in general. This is particularly the case whenthe aim is to simulate processes. In particular, we have got inspirations from the developmentof 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 aconceptual 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, theroles, the knowledge, or more likely, to some "Sub Attribute" describing for example thespecific skills of an actor. In essence, the lack of an explicit framework is what makescomparison between different research findings so difficult.

Our initial analysis of the Product Development Process topic consisted of a number ofiterations where empirical sub attributes were identified and structured. The objects and thestructuring of the main attributes were products of theoretical considerations; they were ourown interpretations. The sub-attributes appeared explicitly in the published material andconstituted the data. Although the structuring effort was rather labor-intensive, we believe thatthe richness of the manual procedure we employed proved to be more effective in makingaccurate distinctions than the employment of an automated approach.

However, the identification of sub attributes and the categorization of main attributes are notenough to construct an ontology; that would yield a taxonomy. An ontology differs from ataxonomy by highlighting the non-linear relationships and dependencies between theidentified categories. Therefore, the structure presented on Table 1 does not quite constitute anontology. Our conceptualization of the Product Development Process contains manyundetermined links (Figure 1).

Figure 1 The undetermined links in the conceptualization of the Product DevelopmentProcess

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

ICED 01 - C586/361 173

4 Analyzing the ICED99 papers

Given the amount of work such a test would require we decided to limit the analysis toinclude only the "Actor" object. That is the aspect of product development processes relatedto humans and the attributes associated with humans.

The proceedings of the Conference on Engineering Design 1999 included 381 papers coveringthe broad field of product development processes. Apart from providing an ideal updatedempirical basis for this study, the proceedings confirmed the need we advocated for anontology: The 381 papers all have a title and three to four keywords, and are divided intopredefined themes. However, it is difficult to pinpoint the papers with overlapping researchinterest.

We analyzed the papers by using a number of different text analysis tools. We concluded thatmany of the available text analysis tools were too detailed to provide the digest type ofinformation that we need. The most efficient type of tool turned out to be the indexing toolsutilized 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 ill-defined. A term like "Knowledge" was associated more with information and data than withknowledge of an actor. The ability to make such distinctions requires an additional syntacticdimension analyses. We have been applying such methods in prior studies [8], and based onthese 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. Thenew sub attributes are derived from the initial sub attributes. However, they are considered tobe more generic and less ambiguous.

Table 2. First version of refined Ontology for the Actor object in "Product Development Processes". Theasterisks signals that any derived words would be included

ObjectsActors

Main AttributesSkillsKnowledgeRolesMotivationValuesEmotions

Sub Attributes/Thesauritalent*, 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 thepapers 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 automatedsearch 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 informationexchange tools, etc, and that they indeed did not cover the Actor object.

Table 3. Number of papers covering the Actor main attributes.

Main Attributes:Number of papers

Skills158

Knowledge194

Roles130

Motivation61

Values13

Emotions13

Of particular interest were the papers covering three or more main attributes. These papersaccounted for 21% of the total number of papers. A manual review showed that the papers hada significant focus on the Actor object - only 4 papers out of 89 can be questioned accordingto their classification. This roughly translates to a 93% automated search accuracy in theActor object.

Table 4. Number of main attributes covered per paper.

Number of MainAttributes Covered:Number of papers

60

(0%)

54

(1%)

415

(4%)

360

(16%)

2105

(28 %)

199

(26 %)

098

(26 %)

The review also revealed that our original suggestion of classifying the Organization attributeas a part of the Environment object was questionable (see table 1). Following our originalempirical material [2] this seemed obvious, but the review of the larger and much morediversified empirical material [7] revealed that there was a link between the organizationobject and the Actor object. In particular, the applications of teams in product developmentprocesses are closely related to the Actor object. We shall elaborate this relation further in ournext review. Secondly, the review showed that it was appropriate to aggregate some of theattributes. The application of the attributes Motivation, Values, and Emotions in the papershad conceptual relationships. We therefore suggest that the three should be aggregated intoone attribute.

The attributes Skills, Knowledge and Roles seemed to coexist to a large extent. More than57% of the papers with three or more attributes covered includes all the three and 91% coverat least two of the three. We therefore suggest that the three should be aggregated into oneattribute.

5 Implications and discussion

Based on the results, we refine the Actor object in "Product Development Processes" byincluding 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 thatany derived words would be included

ObjectsActors

Main AttributesSkills, Knowledge, Roles

Motivation, Values, Emotions

Sub Attributes/Thesauritalent*, 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 theproduct 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 suchempirical 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 thehighest 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 thevolume number of the proceedings and the page number in the volume. The papers in bold are the ones thatappears in more than one main attribute.

Skills, Knowledge,RolesMotivation, Values,Emotions

Paper ranked by best quantitative match1-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-01892-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 ofdifferent ways of interpreting table 6. First, it is possible to identify researchers that shareprofessional interest within a particular area. For example, figure 2 shows a cluster ofresearchers in the skills-knowledge-roles main attribute.

Figure 2. A cluster of researchers working in the area identified by the main attributes - skills-knowledge-workbased 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 paperand the average of papers or a selected group of papers. For instance the results in table 6indicate that the two papers 1-0195 [9] and 2-0793 [10] provide a comprehensive view of thetwo first main attribute of the Actor object. A closer review reveals a significant overlap inresearch interest although the two papers are to be found in different volumes of theproceedings which corresponds to different research areas and share no keywords (see table7). 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.

Skills, Knowledge, Roles

Motivation, Values,Emotions

Eckert et.al. [10]Keywords: Expertise, Creativity,

Design Psychology, AestheticDesign

Differences between expert andnovices;Different types of knowledge;Experts, novices, innovatorsPersonal challenges; Burnout andstaleness

Ritzen et.al. [11]Keywords: Change Process, Key

Factors, ImplementationActivities

Adopting new methods;Acquiring knowledge about newmethods;Role of managementWillingness to chance;Commitment to environmentaltasks; Resistance

176 ICED 01 - C586/361

6 Conclusion and further work

This paper reported the findings of the second stage of a continuing effort for developing aproduct development processes ontology. So far, our findings indicate that productdevelopment research results can be catagorized by the application of a taxonomy and thatthis 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 theontology by accounting for the relationships between objects, and the dependencies betweenthe content of the objects. Secondly, we need to consider more effective and illustrative waysof representing the results. We strongly invite our peers to contribute to the framework as wesee cross-validation and community participation as a crucial step in taking our work beyondits initial phase.

References

[1] Eris, O., Hansen, P., Mabogunje, A. & Leifer, L., "Toward a Pragmatic Ontology forProduct Development Projects in Small Teams", Proceedings of the 12th InternationalConference 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 ToolsAffect Team Performance" in Carley & Prietula (Eds.), "Computational OrganizationTheory", Lawrence Erlbaum Associates, 1994

[7] Lindeman, Birkhofer, Merkamm & Vanja, "Communication and Cooperation ofPractice and Science, Proceedings of the 12th International Conference on EngineeringDesign", Technische Universitat Munchen, Munchen, 1999

[8] Mabogunje, Ade, "Measuring Conceptual Design Process Performance in MechanicalEngineering: 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 DevelopmentProcess", Proceedings of the 12th International Conference on Engineering Design",Technische Universitat Munchen, Munchen, 1999

First authors name: Poul Kyvsgaard HansenInstitution/University: Aalborg UniversityDepartment: Department for ProductionAddress: Fibigerstraede 16, 9220 Aalborg OECountry: DenmarkPhone: (+45) 9635 8935Fax: (+45) 9815 3030E-mail: kyvs@iprod.auc.dk

© IMechE 2001

ICED 01 - C586/361 177

This page intentionally left blank

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

THE APPLICATION OF AN AUTOMATIC DOCUMENTCLASSIFICATION 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 andretrieval, taxonomies

1 IntroductionIt has been estimated that engineering designers can spend as much as 30% of their timesearching for and accessing design information, particularly 'informal information' [1].According to Sutton [2], only ~15% of an organisation's documentation is stored instructured databases that can be easily searched and retrieved. Companies working in'knowledge intensive' industries therefore require improved tools and applications to allowthem to organise and manage access to the intellectual capital contained within all of theirinformation assets. An influential study within a large automotive company [3] found thatengineers 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 technologieshave led to an 'explosion' in the quantity of relevant information that is available to engineersboth within and external to organisations. Keyword based search tools can be used to performspecific queries, however often the results tend to be indiscriminate (with users provided withan overwhelming number of 'hits' or no 'hits' at all). Browsing search strategies provide acomplement to keyword searches, however they require the pre-classification of documentsinto meaningful categories. Kanapan and Taylor note that company Intranets (and Extranets)have been seen as a means of engineering organisations gathering and sharing informationwithin and between organisations [4]. However, "...the organisation of the sharedinformation is usually ad-hoc and is not designed to efficiently serve the diverse informationneeds of workgroups". The manual classification of documents is obviously one option,however the authors have observed from previous informal studies with practising engineersthat attempts to raise the level of manual organisation for documents are often unpopular andineffective. The use of computer systems to assist in the organisation of informal informationis therefore considered to be an important challenge in building improved informationsupport systems for engineers.

1.1 Scope of the paperThis paper can be read in two ways; in one sense it describes the application of an existingautomatic classification approach to the organisation of engineering information intotechnical topics on the basis of the textual content of documents [5], however it also providessome 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 papersis 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 associatedwith these themes for the ICED'0l conference. Following on from this is a description of theoperation and review of the performance of a computer system that is used to automaticallyclassify documents into categories, according to their textual contents. Next, the applicationof the system to the classification of abstracts submitted to the ICED'0l conference ispresented. 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 workreported in these papers describe design document learning systems [6]/[7] and LatentSemantic Indexing approaches [8] to document indexing and retrieval.

2 Survey of the use of keywords in ICED'99 and TMCE 2000The rationale behind the analysis of the use of keywords by authors of engineering designpapers is to aid the grouping of the papers into useful combinations, particularly by having anintegrated and prescribed list of keywords and themes. As sources of data, the authors of thispaper extracted the keywords from 390 documents published in the 12th InternationalConference on Engineering Design (ICED'99), and a further 73 documents from the 3rd Toolsand Methods in Concurrent Engineering Symposium (TMCE 2000). These were consideredto be representative of a broad and a more limited technical domain respectively. Uniquekeywords and phrases were initially identified from those used by paper authors and then thefrequency of these terms was determined. Note that those differing only in terms ofcapitalisation, plurals, punctuation or UK/US spelling variations were merged. The resultsfrom 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 andpractitioners within the engineering design domain. Some argue that such a lack of aconsistent terminology is a constraint on the ability of design from maturing into a scientificdiscipline [9]. Whether or not this is the case, the lack of consistent use of keywords certainlyreduces their effectiveness as an aid in information retrieval. In the particular context of thispaper, the keyword analysis was used to generate a recommended keyword list for theassociated conference themes (totalling 247 recommended keywords). The themes arepresented 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) CurrentIssues (44).

3 Outline of the automatic classification system

3.1 Classification system outlineThe system adopts a standard constraint-based classification approach, in which pre-codedsets of constraints are used to relate the textual content of documents with particular technicaltopics 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 meansto allow the combination of multiple sets of constraints. For the classification of ICEDpapers, the nine conference themes represent the categories into which papers are classifiedand the prescribed keywords provide the evidence of whether papers should be associatedwith a particular category (note that both UK and US spelling variations of the constraintswere 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 casesuch 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 suchwords. A diagrammatic outline of the experimental system is presented in Figure 2.

Figure 2. Outline of the constraint-based classification system

3.2 Measuring performancePrecision and recall are extensively used to evaluate the performance of classificationsystems. Perfect system performance would be indicated by a precision of 1.0 for all valuesof recall. In practice there is a performance trade-off and system precision inevitable falls asrecall increases. As previously noted, the system processes a series of classification heuristicsagainst a set of documents to determine appropriate conference themes. There are two subsetsthat are used to calculate the precision and recall. The computer system generates an answerset of suggested conference themes (the SUG set). There is also a set of assigned themes thatrepresent the 'correct' answers that an expert has decided as being actually relevant (the ASSset). 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 thispaper (i.e. so that precision-recall 'curves' are non-increasing). The results are rankedaccording to measures of the degree to which documents can be associated with theconference 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 thethemes. Note that this approach does not take into account that some terms are moreindicative of a particular theme than others. More complex ranking measures can includeterm weightings and means of accounting for the relative scarcity of terms both withinparticular documents (which will be a factor of the length of documents) and in a collectionof documents as a whole. However, the authors found that the ICED collections analysed inthis paper are relatively insensitive to the choice of ranking algorithm (due to the similarlength of papers and also the relatively small size of the collection). Therefore the resultspresented in this paper are based on ranking using a simple measure of the frequency ofoccurrence of theme constraints.

4 Testing the systemThe full papers from the proceedings of ICED'99 (totalling 390) were used for the purpose ofinitially testing the classification system. To a large degree, the performance of theclassification system is dependent on the 'quality' of the theme constraints (i.e. howaccurately the constraints reflect the particular document themes). This issue is discussed insection 5 in relation to the classification of ICED'0l papers into the relevant conferencethemes previously identified (and using the recommended keywords as constraints). Anadditional factor that is independent of the definition of the constraints, and discussed in thissection of the paper, is a consideration of the location of the occurrence of constraints withinparticular zones or sections of a document.

4.1 Experimental methodologyA 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 sectionheadings used within documents), introduction & conclusions (a combination of theintroduction 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 ofconstraints within different document zones will provide different degrees of evidence ofwhether a document is related to a theme. To test this proposition, 'zoned' papers from theICED'99 conference were classified into the nine ICED'0l conference themes. Note thatprior to indexing the papers, a series of document pre-processing steps were carried out onelectronic versions of the papers. Documents were all converted into HTML with paper titleand keyword fields identified as <meta> tags and, where appropriate, the document headingsconverted into <hl>, <h2>...<hn> tags. The determination of the assigned set for the 390ICED'99 documents was carried out manually by the authors of this paper by makingjudgements as to the relevance of documents against the conference themes. Papers wereassessed as either relevant or not-relevant to each of the various themes and hence wereassociated with any number of multiple themes. The results for each of the nine themes werethen combined into a single average figure for each document zone. Whilst the classificationperformance for each of the themes can vary considerably, the average plots provide a meansof isolating the effect of zoning.

4.2 Document zoning resultsFigure 3 illustrates the results comparing the performance of the classification system forvarious different document zones. The 'whole paper' line represents the baseline plot againstwhich 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 theclassification into themes that match the human assignments. This confirms the expectedfinding 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 incomparison with the baseline. Whilst it is expected that the body text would be a less richsource of theme constraints than the baseline (which is indeed the case), it is perhapssurprising 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 useparticularly descriptive headings within documents. If the results for the ICED'99 papers canbe generalised to represent technical reports (i.e. expository text), this suggests thatautomatically generated tables of contents might not necessarily provide a good source ofsubject descriptors with which to browse documents.

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

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

5.1 Experimental methodologyThe assigned sets for the ICED'0l collection were chosen by the actual authors of theabstracts. When submitting abstracts, the authors were asked to choose a single conferencetheme that they judged the be the most appropriate match for their paper. From the 375abstracts invited to submit full papers, 334 of the abstracts included at least one suggestedconference theme (292 papers were associated with a single theme and 42 with a choice ofeither two or three themes that authors considered to be relevant). Abstracts which did notinclude an assigned theme were not included in the following analysis. For the documentsassigned to multiple themes, it was assumed that they were partially associated with each ofthe multiple themes (i.e. a document assigned to two themes was considered to be 'halfassociated' 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 choiceof ranking algorithm (and hence the simple term frequency similarity measure was used). Inaddition, document pre-processing was carried out in a similar manner to that previouslyoutlined in section 4.1.

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

184 ICED 01 - C586/433

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 areused to associate the abstract with the particular themes. It is apparent that the Current Issuesand the Engineering design in industry themes perform particularly poorly, providing someevidence that the keywords used in the prescribed list do not match well to the content ofabstracts. In section 2 it was noted that the Current Issues and the Engineering design inindustry themes were associated with 36 and 44 keyword-constraints respectively, which is alarger number than for the other themes. All things remaining equal, the expected effectwould be to increase the classification recall at the expense of precision. This does not appearto be the case in comparison with the other themes, indeed, the Current issues theme has thelargest number of constraints but also the poorest recall. This certainly suggests that thesetwo themes are not adequately represented by the recommended keywords. Anotherimportant factor is undoubtedly the less 'concrete' nature of these two themes. Authors wereasked to select only a single conference theme to be associated with their abstracts. It wasobserved that, where possible, authors had a tendency to choose the more technical topicsfrom 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 asecondary theme.

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 Currentissues and Engineering design in industry. This theme also has a large number of associatedrecommended keywords (35), although it provides the best classification results. It isconsidered that this can be attributed to higher 'quality' nature of the constraints (that areeasier to define due to the more 'clear-cut' nature of theme).

When considering the conference themes that are automatically suggested by the system, itwas found that when using the entire abstract, ~60% of abstracts are 'correctly' assignedwhen 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% ifeither 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 recommendedkeywords associated with the selected theme. The results for the classification of the abstractbody text collection (i.e. excluding the title and keywords) determined that ~42% of abstractsare 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%. Thisis 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 anabstract into multiple categories is permitted (as is the case in an electronic classificationsystem where an electronic document can be virtually classified into multiple locations).

6 ConclusionsThe initial stark conclusion shown is the lack of an agreed terminology by researchers andpractitioners in the engineering design domain. One of the implications of this lack ofconsensus is a reduction in the effectiveness of 'un-prescribed' or freely chosen keywords asan aid in information retrieval. The results demonstrate the effectiveness of a conceptuallysimple textual constraint-based document classifier in organising ICED'0l abstracts, using aprescribed keyword list developed from the initial keyword use survey and a set ofassociated/integrated conference themes. An analysis of the effect of document zoningindicates 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 beassociated with a theme. Most notably the title, snippet and keywords provide the mostsignificant evidence, with the textual content of document headings being a surprisingly poorindicator of a document's content. The classification approach has been shown to beparticularly effective in well-defined technical subject areas, although inevitably lesssuccessful in conference themes that are less distinctive (e.g. the Current issues andEngineering design in industry themes).

Note that the techniques described are currently being used with a very much expandedhierarchically decomposed set of design related research topics. This is to facilitate theassignment of papers into specific technical areas and to assist in the identification of sub-topics and paper groupings for the preparation of the programme for ICED'0l.

7 AcknowledgementsPart 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

[1] Court, A. W., Culley, S. J. and McMahon, C. A. "Information Access Diagrams: ATechnique for Analysing the Usage of Design Information", Journal of EngineeringDesign. 7, 1996, p. 55-75.

[2] Sutton, M. J. D. "Document Management for the Enterprise: Principles Techniques andApplications". 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: StructuringHypermedia Information in Engineering Development Projects", Proceedings of ASMEDETC, Sacramento, California, 1997, DETC97/EIM-3721.

[5] Paijmans, H. "Comparing the Document Representation of Two IR Systems: CLARITand 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 Rolesfor 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: ImprovingAccess 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. EDC2000. Brunei, UK, 27-29 June 2000, p. 439-448.

[10] MacLeod, I. A., "Storage and Retrieval of Structured Documents", InformationProcessing and Management. 26. 2, 1990, p. 197-208.

Chris McMahonUniversity of Bristol, Department of Mechanical Engineering, Queen's Building, UniversityWalk, 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

186 ICED 01 - C586/433

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

ANALYSIS AND CLASSIFICATION METHODOLOGY FOROBJECTIFICATIONS IN COLLECTIVE DESIGN PROCESSES

A Verbeck and K Lauche

Keywords: Information analysis, classification and retrieval: taxonomies; co-operativedesign; empirical study

1 Introduction

Objectifications or artefacts such as sketches, documents, CAD models or tools play animportant role in the design process. They help the designer to externalise ideas and alsofunction as a means of communication within teams and as objects for knowledge manage-ment in organisations. As collective design processes highly depend on the successfulexchange of ideas and information during meetings and in distributed teamwork, it is vitalthat objectifications are employed in a way that actually supports the design process. As aresult of our interdisciplinary design research, this paper introduces a taxonomy to diagnosethe use of objectifiactions. It covers the individual function, the benefit for the team and thecontribution to knowledge management of any given document. If a range of relevantdocuments is diagnosed with this tool, the results can be used to give feedback about theforms of communication and documentation within the R&D process. In this paper, weexplain the importance of objectifications and our theoretical approach, describe the tool andgive an example on how it was applied.

2 Importance of objectifications for the R&D process

We understand the process of designing as a constant dialogue between the mental processethinking and the outward expressions. Perceptions of the outward world are internalised andbecome part of the mental representation. They are then externalised into drawings, sketchesor physical models [1]. Experiments showed that participants instructed to sketch their ideasspent more time on sketching but arrived at better results at an overall shorter time than thecontrols [2]. The reason for this is seen in the limited human mental capacity: The sketchworks as an external buffer and thereby frees higher order mental capacities. Also thesketching itself helps to find a form by "thinking with the hand". This manual part ofdesigning is particularly effective in early phases for rough sketches. From his studies offreehand sketches in a conceptual design experiment, Pache [3] suggested to so see sketchesas a script of the designer's dialogue with his product representation. By combininggeometrical elements, symbols or written terms, the sketch tells a technical story to someonefamiliar 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-relationalcontext. Form this dialogue and the visual perception during sketching, creative, unintendedmechanisms 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 andat the same time relate to existing objects around them. Every design starts within a world ofalready existing artefacts and produces new elements for our material culture. Activity theoryhas emphasized the role of objectifications in the individual development of mental capacityand in the historic development of a culture [4]. Figure 1 shows the theoretic framework ofobjectifications 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 orthe team, and their object, the task, and they mutually influence each other. Beyond thisindividual function, there are also elements of how a community, which might be a companyor a professional body, communicate. The use of artefacts is influenced by the rules andconventions such as a methodology. Their role for the exchange of ideas and knowledge alsodepends 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 amongteam members. It implies that the more time a team spends generating and modifying anartefact, the better for the social process. This will be vital for co-operation but may not bedesirable form an economic point of view. A knowledge management approach wouldrecommend that documents should be accessible and understandable for a wide range ofpeople but would not suggest that everybody should be involved. This dispute is not resolvedin this paper. However, the tool gives an account of all the different aspects for acomprehensive diagnosis. From the results, actions can be derived that take the specificcontext 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

3 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 socialand organisational aspects. Protocol analysis normally does not deal with artefacts for morethan one situation, and social sciences offer — apart from interviews and questionnaires — onlycontent analysis of elicited statements. However, much information can be obtained fromexisting documents. Therefor, for developing this tool, we draw on our theoreticalunderstanding of objectifications and on ethnographic approaches. We combined documentanalysis for descriptive features and content with questioning involved people about thebackground 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 andthe benefit for knowledge management. It can be used to study collective design processes asa supplement or substitute for extended observations. The tool can also be applied todiagnosis of use and storage of collective knowledge and its materialisation for practicalpurposes. It provides the basis of an assessment of how documents and models fit the needs ofthe design process or conform to a certain knowledge management approach. The entire set ofall 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

2. Localisation inprocess

3. Individual function

Criteria

content and people involvedtype (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 ofconcepts, choice of concepts, evaluation, decision

analysis- storage

evaluationsolution findingcommunicationdocumentationinternal exerciselegal requirement

Source

SystemsEngineering

Hacker, Sachse,Schroda [2]

Pache. Romer,Lindemann,Hacker [3]

1CED 01 - C586/456 189

4. Team function

5. Organisation

generation- usage

effort neededfurther developmentmaintenance

by cither one / two / several or / all memberswith cither the same or different disciplinarybackgroundfrom either the same or different departments

Knowledge management function:transparency, acquisition, sharing, development,use, storage of knowledge

Retrievalindividual, collective store, effort and restrictionsof access

UsefulnessInformation contained, problem specific, solutionoriented, iterations needed, cost-benefit ratio,readability to others, generalisations to otherproblems

Weber [5]Lauche, EhbetsMuller, Grote [6]Verbeck, Lauche.Weber [10]

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

!

Table 1. Sections and criteria for the classification tool

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

3.2 Individual function

The tool contains an introduction into the concept and function of objectifications and aninstruction to the classification guidelines. The application combines the description offeatures and interview questions. First, an artefact is characterised by its content (what isshown 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 involvedwith it, is the localisation within the product development process and in the problem solvingcycle. The individual function is categorised according to observation or interview informa-tion.

So far, research suggests that simple models are mainly used for task clarification and solutiondevelopment. For these stages, CAD programmes were seen to offer only little help as theydemand exact decisions and are not as intuitive as sketching [4]. Complex models andprototypes are mainly used in later stages. The function for the individual design process andthe 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 problemsolving. 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 ateam transfer their individual knowledge and experience in a joint action into a materiallyshape. By exteriorisation, the members make their knowledge available to others. Theythereby create a shared meaning within and between the disciplines [6]. The members can usethe collective knowledge and improve the objectification continuously.

For the team building function, it is crucial which parts of the objectification were madetogether. The more an artefact is used and transformed by the group, the bigger are its impacton social bonds and the team identity. Weber showed that for teamwork in manufacture, thenumber and quality of collective objectifications correlates with co-operative attitudes in theteam [5]. Therefore, objectifications can be used as an indicator for team cohesion. Followingthese results the usage of an objectification is classified for its team-building function. It isdistinguished whether one, two or several members or the whole team create, use, modify ormaintain an objectification and if these people are from the same or different professionalbackground and department. The scale from 0 to 4 implies that the unifying potential is higherif more diversity is integrated into the artefact and if more collective effort is put into it. Theteam scales are defined in fairly behavioural terms so that they can be observed or recalledeasily.

From our observations on the use of artefacts for developing a common language in teammeetings, we have seen that it is important to remain the visual image used in the meeting forthe protocol [6J. It will be easier to recall what was actually presented, and the unfinishedlayout stimulates further brainwork on the topic better. Any transformation into word pro-cessing or CAD may be helpful for presenting results but always implies an interpretation. Apublic protocol has also helped to keep meetings more structured and to integrate differentideas 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 andbecome an issue for knowledge management [7]. They serve as a memory of the organisationthat thereby acquires, develops, shares and stores knowledge of its members. From thisperspective the transparency and re-usability by any other person is most important. In theprevious sections, the focus war on the process, the result was only of secondary interest. Inthis section, we look at the corpus of abstracted knowledge that has been extracted from theactivity of designing. It is not necessarily decontextualised but it has to be available andaccessible 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 Probstet al. [9]. Transparency refers to overviews of external and internal knowledge. Acquisitionmeans that existing knowledge is imported by the organisation whereas development refers tothe generation of new knowledge within the organisation. Within the organisation, knowledgecan be shared, used and stored. The document is classified to serve one or more of thesefunctions. From our experience, we would also like to emphasize that the storage of informa-tion 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 wholeR&D process. An institutionalised character of the other tasks can be of great usage andtherefore 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. Foreach person, it is listed whether the artefact is in their individual store or in a collective driveor place. It is also noted who is allowed to access it and how much effort it takes. The last stepis the evaluation of the business profit of the particular artefact for the value of the informa-tion contained, the task adequacy, the effort for reuse and retrieval, the cost-benefit ratio, thetransparency for other people and the transferability for other problems. These economiccriteria need not conform to the psychological criteria for the design or the team process.

4 Example

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

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

192 ICED01-C586/456

In the first step, the two engineers arrange existing material and draw on a big sheet of paperand thereby discover where they had different concepts of how the interface should be. Theresult is still rough and flexible; it invites to take part in the discussion. The artefact mirrorsthe collective design process. It scored high for team scores but low for readability to othersand retrieval. In the second picture, the sketch has become a printed file. One of the engineerstook 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 theoriginal sketch. Other members of the team used the second artefact as a result withoutdeveloping it further. Hence, the team score went down. The file would have been easy tochange but it was not available to the other team members. Therefor, the score for knowledgemanagement 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 onresearch methods for social science students. The students were given the backgroundinformation and two objectifications. They successfully work according to the instruction andreceived similar results.

5 Conclusions

We suggested a research methodology that can be applied not only to the individual sketchingand modelling, but also to objectifications made and used by a group of designers. Theclassification draws also on the readiness for knowledge management systems. The toolproofed helpful to access to the history of former developments that we analysed for criticalsuccess factor in the upcoming project. It also provided a token to start an interview in acomfortable atmosphere as some designers feel more at ease to show an object than to give averbal description of their work. However, the tool cannot be applied for pure documentanalysis as not all information requested is static and readable from the document or objectitself.

A detailed instruction makes the tool available for academic research as well as for know-ledge management assessment in industry. The pilot use in social science education suggeststhat the analysis of objectifications is a promising method for empirical research not only indesign studies. However, we believe most benefit is achieved when interdisciplinary researchteams share their research methods and their understanding of artefacts. The tool is intendedto turn our experience into codified knowledge for the design research community.

References

[1] Leont'ev, A.N., Activity, Consciousness, and Personality, Englewood Cliffs: Prentice-Hall, 1978.

[2] Hacker, W, Sachse, P. & Schroda, F., Design Thinking - possible ways to successfulsolutions in product development, In: Birkhofer, H. Badke-Schaub, P. & FrankenbergerE. (eds.), Designers - The Key to Successful Product Development. London: Springer,1998.

[3] Pache, M., Romer, A., Lindemann, U., Hacker, W., Mechanismen und Strategien beimEinsatz von Handskizzen in friihen Konstruktionsphasen. Kongress der DGPs. Jena2000.

1CED01-C586/456 193

[4] Engestrom, Y., Miettinen, R and Punamaki, R. (eds.). Perspectives on Activity Theory.Cambridge, UK: Cambridge University Press, 1999.

[5] Weber, W.G., Collective Action Regulation, Common Task Orientation, and CommonObjedifications in Advanced Manufacturing Systems, Proc. of TEA'97. p. 283-285,1997.

[6] Lauche, K., Ehbets Muller, R. & Grote, G., Collective Conceptualisation in EarlyPhases of Innovation Processes. Proc.of Design 2000. Dubrbvnik, 119-124, 2000.

[7] Konda, S., Monarch, I., Sargent, P. & Subrahmanian, E., Shared Memory in Design: aUnifying Theme for Research and Practice, Research in Engineering Design, 4, 1992, p.23-42

[8] Reich, Y., Konda, S., Subrahmanian, E., Cunningham, D., Dutoit, A., Patrick, R., Tho-mas, M., Westerberg, A.W. and the n-dim group, Building Agility for Design Infor-mation Systems. Research in Engineering Design. 11, 1999, p. 67-83.

[9] Probst, G., Raub, S. & Romhardt, K., Managing Knowledge. West Sussex: Wiley, 1999.

[10] Verbeck, A., Lauche, K. & Weber, W.G., Objectifications and sociotechnical featuressupporting integrated R&D teams to cooperate, Proc. of ICED 99. p. 217-222, 1999.

Dr. Kristina Lauche Dr. Alexander VerbeckDepartment of Psychology ESEC S AUniversity of Aberdeen Hinterbergstrasse 32Aberdeen AB 24 2UB CH-63 3 0 ChamScotland UK SwitzerlandTel. +44(0)1224272280 Tel. +41-41-7495111Fax +44 (0) 1224 273211 Fax +41-41-749 52 50k. lauche@abdn.ac .uk Alexander. Verbeck@esec. com

©IMechE2001

194 ICED01-C586/456

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN1CF.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

1 Introduction

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

2 Modular Design and Re-use

Modular design involves the creation of artefact variants based on the configuration of adefined set of modules. Modules are commonly described as a group of 'functionally' or'structurally' independent components clustered such that 'interactions are localized withineach module and interactions between modules are minimised' [1]. The principle aims tocreate variety, reduce complexity and maximise kinship in designs and across productfamilies. Due to the fact that individual module functions and/or structures must eventuallycombine to realise the overall function/structure of the artefact, the modules can never truly beindependent 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 successfullyconfigured to meet overall system requirements

In exploring why modular design so readily maps to the 're-use' perspective we considersome of the major benefits of the approach, including: efficient upgrades; improved designunderstanding; improved knowledge structures; improved knowledge management; improvedknowledge utilisation; reduction in complexity; reduction in costs; rapid product development[2,3,4].

These benefits support increased utilisation of experiential knowledge for new productdevelopment 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 researchissues' [3] and 'modularity has been treated in the literature in an abstract form' [5]. That isthere is a need for approaches 'to determine modules, represent modularity, optimise modulardesign and assess the impact of modularity on the design process' [5].

ICED01-C586/046 195

3 Supporting 'Design for Re-use'

There is a current drive towards modular structuring of products, motivated by the body ofevidence as to its benefits. Despite significant correlations between the two, currently nomodular design methodology specifically emphasises support for 're-use'. In the 're-use' fieldstudies have shown 'design for re-use" can have a significant impact on the realisation of 're-use' related benefits [6], Since it suffers from the most notable lack of support, of all the re-use processes [7], the potential for a modular design methodology/tool to support this processis 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'sdifferent 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 andfacilitating a mapping between each to optimise module definition and design.

• Supporting the re-use of generated modules and their associated knowledge through theprovision of an explicit formalism for design knowledge, dependency knowledge andmodule definitions.

• Facilitating the exploration of 'design by re-use' by mapping potential designchanges/decisions onto the previous modular solution and its associated developmentknowledge.

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 canbe grouped into 3 distinct categories: those based on function, on the potential means ortechnical 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 functionalcriteria of a design. The component/part view and its inter-relations are the focus of Sosale etal [1], and Kamrani [10]. Here termed, 'structural modularity' its focus is predominantly onlater-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 onmodularity for recycling and disposal whereby well defined physical parts are grouped intomodules 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 'functionalto technical nature', cannot meet the constraints of later stages of design. Likewise, it can alsobe argued that due to the nature of 'structurally' orientated modules they fail to capture and/orexplicitly represent knowledge from earlier conceptual phases of design or more generalisedknowledge. 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 topromote 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 themultiple viewpoints of design within a coherent and integrated structure [11-13]. Viewpoints,within the context this research, represent structured views of 'engineering design' requiredby 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 generatedthrough this 'for re-use'. Secondly, we define a life-cycle objective to be the expression of arequired and/or preferential need with respect to an individual or group of artefactstakeholders from various stages of the entire artefact life (of which the 'design process' canbe 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 productdesign, design problems, production systems, or all three'. Thus acknowledging the need tosupport 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 benefitsare neither expressed nor attained until late in the design process. Thus abstract knowledgeimportant for the maintenance of knowledge for re-use [15], is not supported, normodularised, 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 othersconstitute alternative stages in the life cycle of a product. However, their "views" areindependent in that issues relating to different business functions are dealt with in differentviews.

4 A Modular Design Methodology for Re-use

Current approaches do not adequately formalise, nor maintain, the knowledge behind definedmodules nor facilitate mapping between different viewpoints of the 'engineering designprocess' and consequently they are too inflexible to fully support 'design for re-use'. Theauthors' proposed approach focuses solely on views in the 'design process' with the intentionof furthering our understanding of relations and constraints within, and across, viewpoints toaid the realisation of modularity from project inception. By developing methods to define andmanage modularity from the higher level 'functional' view to Mower level' parts, geometryand physical characteristics, we aim to take into account life-phase modular needs duringdesign 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 beincorporated at project inception' [16] and be evident throughout the product developmentprocess and beyond. The difficulties in achieving this support include the notion thatmodularity is not a constant property (what is modular in one viewpoint may not be inanother) and that modularity can be achieved in different forms (different modular structuressupport 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 aidin the management of such difficulties. Relations are far more complex than the 'functionaldependence' or 'physical link' of relations utilised in current approaches to modular design.There are complex dependencies involving functional, mechanical, information, energy andmaterial relations and constraints.

4.1 The components

The following presents novel 'modular design methodology for re-use' which aims to addressthe previously outlined issues and inadequacies of modular design support. The methodologyconsists 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 currentworking design knowledge and knowledge related to the domain. Thus, it has the ability tosupport and formalise knowledge of an evolving design over the viewpoints inherentlyadopted by the designer as shown in figure 1. As we are predominantly concerned withsupporting 'design for re-use', a process carried out during design itself, our initial focus is onthe 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 onthe concept and attributes; see Figure 2a) and relations between concepts (Figure 2b). Conceptconstraints indicate application conditions whilst attribute constraints represent dependenciesbetween individual attributes. Between concept relations can have a type (Has-kind, A-kind-of, 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 acausal link relation across viewpoints, Figure 1.

Figure 2 (a) - Concepts, attribute and constraints

Relation (type, direction)

(b) Relations between concepts

198 ICED01-C586/046

This formalism is utilised as it supports the evolution of a design whilst definingrelation/dependency knowledge between concepts both within and across viewpoints ofdesign.

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 onmatrix interpretation rules and other grouping/clustering techniques (element 3), and moduledefinition.

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 themodule design and optimisation process. The techniques are required to support moduledesign 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 andcapture knowledge of the evolution of the modular design solution. The mapping mechanismis a key element of the methodology's 'design for re-use' support as it allows capture of boththe 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 mechanismwould also support analysis of the effect of a change in 'modularity' focus i.e. change ofconstraints, life cycle objectives and/or module size/number. Further, when utilised in a 'byre-use' scenario the mechanism could allow analysis of the impact of design changes andsupport 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 applicationloop which supports the generation of modules as the design evolves from the abstract to theconcrete 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 conjunctionwith BAE Systems Marine Ltd (Forward Design Group) and Alenia Marconi Systems. Themarine field was chosen based on the findings of a previous study in the area whichhighlighted a significant correlation between support for the process of 'design for re-use' andthe achievement of 're-use' related benefits [6], More specifically, we focus on the potentialmodularisation 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 asignificant redesign which results in easier access to documentation on previousgeneration consoles, and the ability to analyse the results of the methodology's applicationagainst both the new console design solution and the process undertaken to achieve it.

• Sufficient Complexity: The console's requirement to integrate a number of differingfunctions, mechanisms and technologies is expected to result in the development of amore robust methodology.

• Embodiment of Ship Design Issues: The console must take into account a number ofship design issues, including:

Ship Class Maintenance, which requires that all previously designed ships in that classmust be of similar outfitting to ensure adequate integration of all ship systems. As thedesign and manufacture of a naval ship class can span decades this is an especiallypertinent issue in the design of a console which embodies technologies subject to rapiddevelopment (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 withinthe 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 ofcomponents and the minimisation of retrofit requirements of individual ship systems.

Thus, these issues provide a case with significant life-cycle objectives on which to basethe development and analysis of the methodology.

5 Conclusion

The correlation between the principles of modular design and the requirements of 'design forre-use' has been presented. The main issues that attribute to the inadequacy of currentmodular 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 iscurrently being developed in a bid to provide better support for the relatively neglectedprocess of 'design for re-use'.

References

[1] Sosale, S., Hashiemian, M., and Gu, P., "Product Modularisation for Re-use andRecycling", ASME, Design Engineering Division, DE, Vol.94, pi95-206, 1997

ICED01-C586/046 201

[2] Miller, T.D., "Modular Engineering of Production Plants", International Conference onEngineering Design, ICED '99, Munich, August 24-26, 1999

[3] 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.

[4] Muffato, M., "Introducing a Platform Strategy in Product Development", InternationalJournal of Production Economics, Vol. 60, p!45-153, 1999.

[5] Huang, C.C. and Kusiak, A., "Modularity in Design of Products and Systems", IEEETransactions on Systems, Man and Cybernetics - PartA: Systems and Humans, Vol.28No. 1, January, pp 66-77, 1998.

[6] Duffy, A.H.B., and Ferns, A.F., "An Analysis of Design Reuse Benefits," inProceedings of the International Conference on Engineering Design, Munich, 1999.

[7] Smith, J.S., and Duffy, A.H.B., "Product Structuring for Design Re-use", Proceedingsof the 5th WDK Workshop on Product Structuring, February 7-8, Tampere University ofTechnology, Tampere, 2000

[8] Chang, T., and Ward A.C, "Design-in Modularity with Conceptual Robustness",ASME, Design Engineering Division, DE, Vol.82, Part.l, p493-499, 1995.

[9] Erixon, G., "Modular Function Deployment - A Method for Product Modularisation",Doctoral Thesis, Manufacturing Systems, The Royal Institute of Technology,Stockholm, 1998.

[10] Kamrani, A.K., "Modular Design Methodology for Complex Parts", 6lh IIE AnnualEngineering Research Conference, Miami Beach, Florida, USA, p391-396, May, 1997.

[11] Jarventausta, S., and Pulkkinen A., "Enhancing Product Modularisation with MultipleViews of Decomposition and Clustering", Proceedings of the 5th WDK Workshop onProduct Structuring, February 7-8, Tampere University of Technology, Tampere, 2000

[12] Jiao, J., and Tseng, M.M, "A Methodology of Developing Product Family Architecturefor 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 forModularity", Robotics and Computer Integrated Manufacturing, Vol.15, p319-329,1999.

[14] Kerr S.M., "Customised Viewpoint Support for Utilising Experiential Knowledge inDesign", 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 Construction", PowerEngineering, Vol.102, Part.l, January, p20-22, 1998.

[17] Zhang, Y., "Computer-based Modelling and Management for Current WorkingKnowledge Evolution Support", Doctoral Thesis, DMEM, University of Strathclyde,UK, May, 1998.

Joanne S SmithCAD Centre, DMEM Department, University of Strathclyde, M209, James Weir Building, 75Montrose 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

CAPTURING AND CLASSIFYING INFORMATION INUNDERGRADUATE DESIGN TEAM PROJECTS

P A Rodgers

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

1 Introduction

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

2 Design Rationale Methods

Design rationale generally includes not only the reasons behind a design decision but also thejustification for it, the alternatives considered, and the argumentation leading to decisionsmade. However, as Shipman and McCall [3] point out, design rationale can be viewed in threedifferent ways:

• Communication: capturing and retrieving naturally occurring communication (e.g. designdiscourse) among members of a design team. The recording of design communication isnot 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. Thisincludes both the reasoning of the individual designer and the discourse among teammembers in a design project.

It has been suggested that the more structured argumentation perspective of design rationalehas the potential to solve many of the acquisition and classification problems associated withdesign 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 argumentationproposed by Rittel et al. [5, 6]. This approach to design rationale is based loosely around fourorganisational 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 theiropinion, expertise, training and so on. To justify their positions, they support or object themwith arguments. To strengthen their arguments, they cite references. The four atoms or nodesdescribed above can be connected by a variety of links to produce an IBIS network such asthat 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 ofthe term design rationale and utilises Rittel et al's IBIS framework for capturing and indexingthe design discussions made during the student design team project.

3 Capturing and Indexing Design Rationale: A Case Study

The case study described here involved second year undergraduate interdisciplinary designstudents 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 projectincluded the students working in small teams of three to four, on the redevelopment ofselected 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 ancillarystaff) 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 parkingsystems, a concept for a transportable bag/ desk/ chair, and the redevelopment of both interiorand 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 theirdiscussions and decisions using the IBIS framework outlined earlier in Figure 1. Each projectteam was asked to propose issues, state positions, raise arguments, and cite references as theirdesign progressed over the course of the project.

Figure 3 illustrates a small section of the design rationale framework for the student team'ssecure bicycle parking system project which is described in greater detail in the followingsections.

3.1 Case Study Project: Secure Bicycle Parking System

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

3.2 Bicycle Parking System Issues

After consultation with the school caretaker and the pupils in particular, the design team setout to design a new secure parking system for bicycles. A number of initial issues, whichwere identified by the design team, are shown in Figure 4. The key single issue of how bikesare 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 bikessecurely. The IBIS framework produced by the design team has highlighted this single issueas significant in the development of the secure bicycle parking system. A selection of theimportant positions (concepts) developed to resolve the issue of how best to attach the bikessecurely 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 otherswere raised by the design team during the project. These are described in more detail in thenext 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 bedifficult" (Ma).

ICED01-C586/118 207

Although many of the students' arguments were not backed by official documents that theymay have cited, several arguments posited were strengthened by references to experts in thefield (i.e. school janitors, local architects, engineers and so on).

A process of iteration followed in the secure bicycle parking concept with several variationson issues, positions, and arguments being discussed and recorded until the design teamdeveloped a final scheme to present to the school. Figure 6 shows one of the final presentationscale models for the secure bicycle parking system developed by the team. The main ideabehind the design solution shown in Figure 6 is that each site-specific secure bicycle parkingsystem would comprise any number of individual modular units. For instance, the systemshown 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 HighSchool (near Edinburgh) are in discussions with the student design team concerning greaterdevelopment of the scheme. The intention is to finance the completion of at least one site-specific modular unit within the school. The student design team are currently addressingissues regarding the materials' specification, manufacturing limitations and budgetaryimplications.

4 Conclusions and Results

Although it has been suggested that the argumentation-based "design rationale" technique ofIBIS offers a natural framework to record design information as structured arguments, it canbe difficult to acquire design information using this representation effectively [8]. Generallyspeaking 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 initiallywith the terminology used in the IBIS framework, and encountered problems overcategorising their deliberations.

Furthermore, the majority of students involved in this study indicated specifically on severaloccasions that the structure of IBIS was "too restrictive" and was interfering with theircreative design activities such as generating solutions. Also they noted many times that theywere overly preoccupied recording the design rationale of the group and not spending enoughtime designing. In an effort to alleviate this problem, a couple of the design teams attemptedto audio record their deliberations as they worked. However, this was not successful as theamount of background noise heard on playback hindered complete translations of the decisionmaking and argumentation that had occurred. Generally speaking the design teams relied ontheir collective memories and tended to rely on retrospectively recording their designrationale throughout the duration of the project.

In summary, although the end results of the design rationale exercise (using the IBISframework) were fairly impressive the procedures adopted by the students weredisappointing. Specifically, the retrospective manner in which the design teams captured theirdecision-making rationale. This may be due, in part, to the relative inexperience of thestudents involved in the case study (i.e. 2nd year undergraduate design students). Future workon this theme may include the utilisation of final year design students during their majorproject.

5 Acknowledgements

The author would like to thank everybody at Penicuik High School who were involved in thisproject. In particular Paul Beards, the head of the Design and Technology department, for hisco-operation and support. The author would also like to acknowledge the dedication anddiligence of the 2nd year BDes Interdisciplinary Design students throughout this very fulfillingcollaborative project.

References

[1] LEE, J., "Design rationale Systems: Understanding the Issues", IEEE Expert. 12 (3),1997, pp. 78-85

[2] Burge, J. and Brown, D.C., "Reasoning with Design Rationale", in J.S. Gero (Ed.),Artificial Intelligence in Design 2000. Kluwer Academic Publishers, Dordrecht, TheNetherlands, 2000, pp. 611-629

[3] 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

[4] MacLean, A., Young, R., and Moran, T., "Design Rationale: The Argument Behind theArtifact", Human Factors in Computing Systems. CFfl '89 Conference Proceedings.Austin, Texas, 1989, pp. 247-252

[5] Kunz, W. and Rittel, H., "Issues as Elements of Information Systems", Working Paper131. Center for Planning and Development Research. University of California.Berkeley. 1970.

ICED01-C586/118 209

[6] Rittel, H., "On the Planning Crisis: Systems Analysis of the First and SecondGenerations", Bedriftsokonomen. 8, 1972, pp. 390-396

[7] Cao, Q. and Protzen, J.P., "Managing Design Information: Issue-Based InformationSystems and Fuzzy Reasoning System", Design Studies. 20, 1999, pp. 343-362

[8] Grant, D., "Argumentative Information and Decision Systems", Design Methods:Theories. Research. Education and Practice. 26, 1992, pp. 1524-1588

Dr Paul A. RodgersSchool of Design and Media Arts, Department of Design, Napier University, Merchiston, 10Colinton 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

INCORPORATING INCENTIVES INTO DESIGN DOCUMENTATIONTOOLS

T Lloyd and L Leifer

Keywords: Motivation, incentives, documentation tool, survey.

I Introduction

There is a critical flaw with the current design documentation tools that inhibit them frombeing effective. Many documentation tools focus on reducing a designer's effort toperform documentation, while leaving the responsibility of motivating the designer toperform documentation solely to the company employing the tool. If the company is intune enough with its designers to know what kind of incentives, such as monetary orrecognition awards, motivate them to comply to management wishes, then thecombination of effort reduction and incentives can be quite effective. For example, Fordhas built an easy to use on-line database of more than 2,800 proven automotive bestpractices worth an estimated $1.25 billion [1]. Ford's Best Practices Replication Processuses a high profile recognition system that publicly scores the knowledge contribution ofeach plant as an incentive to support knowledge sharing and design documentation.However in the absence of such compliance incentives, reducing design capture effortalone is often insufficient motivation to do documentation.

At first it may appear that capturing design knowledge because it will be advantageous tofuture designers working on the project, would be sufficient incentive for designers to dodocumentation. However for designers who are under pressure to meet project deadlines,juggle several design tasks at once, and still perform documentation for potentiallysomeone else's future benefit, this incentive falls short [2].

In the absence of incentives for documentation compliance, designers naturally prioritisethe tasks that give them immediate benefit over documenting. In companies that lackstrong rewards for design capture and knowledge sharing, the designers' value to thecompany 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 toget done first, then if the designers have time, they consider the tasks that will have long-term 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 anopportunity cost associated with the documentation effort. When the opportunity cost isperceived to be higher than the benefits of documenting, designers will not willingly paythe price to document. For instance, De Long and Fahey take note of a printed circuit-board design team that refused to document their lessons learned per management ordersbecause the time spent reflecting on their experiences would ultimately cost the team somebillable hours. It was not until management established an account for charging time spentin collecting lessons learned that the team followed orders [3]. The team perceived theirvalue 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 teamdid not comply with management's wishes.

In essence a documentation tool's success or failure depends on the potency of thecompany's documentation compliance rewards. In order to attenuate the tool'sdependency on company culture, it is necessary to incorporate documentation incentiveswithin 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 willincrease by enabling design capture to have a more immediate impact on the success of theproject. A documentation tool that not only captures the design process, but also givesmeaningful feedback to the designer, will encompass viable documentation incentives.However, which of the many potential feedback tools available through documentationwill a designer find particularly rewarding and motivating? Perhaps the answer is found inthe understanding of why designers are motivated to do design work in the first place. Forit may be possible to build upon these 'pre-existing motivations' to establish an incentivethat is already known to have some weight or rather pull with designers.

As an initial effort into incorporating incentives into design documentation tools, thispaper 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 offeedback designers might find rewarding as incentives;

3. examine the importance of several design activities to determine which activitiesdocumentation tools should supply feedback; and

4. explore the challenges for designers to record design rationale to establish key areasfor documentation effort reduction.

2 Methodology

To investigate the ideas presented here, an exploratory survey was completed on 31mechanical engineering design students and on 35 engineering professional designers. Thesampled students were all Stanford University students enrolled in a graduate-level 30-week long project design course that attempts to model an accelerated research anddevelopment cycle. The course requires an extensive project status report every 10 weeksand documentation is approximately 30% of the student's final grade. The survey wasconducted about 22 weeks into the course on 17 students (a response rate of 81.0%) andthen it was repeated about 14 weeks into the course on the following academic year on anew set of 14 students (a response rate of 46.6%), thus totalling 31 students. The averagedesign experience of the students was 3.15 years from school projects plus 1.12 years frominternships and professional experience.

The sampled professional designers all worked at a Palo Alto, California design consultantfirm called IDEO Product Design. There was only a 36.8% response rate. Of theprofessional designers 51.4% are solely in the mechanical discipline, 17.1% are ofmechanical and product disciplines and the remaining where solely industrial (8.6%),interaction (8.6%), and other (14.3%) disciplines. The average professional designexperience of the professional designers was 8.9 years with 42.9% having had 2 or moreyears of management experience.

212 1CED01-C586/472

The survey was self-administered and contained five core questions and a set ofbackground design experience questions. Figure 1 shows the five core questions stated inthe professional survey. The first and second academic versions differ from theprofessional version when requesting percentage of time spent on design activities, themajor column divisions are for the course experience and for professional experiences. Inaddition, 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 leasteniovable.

Identifying - problem identificationBrainstorming - idea and concept generationBenchmarking - users and existing designs and concepts investigation.Decision making - idea and concept selectionPrototyping - prototyping concepts and componentsDocumenting - capturing the design rationaleEvaluating - getting feedback on brainstorming, benchmarking, decision making, mock making

and or documentationReflecting - looking back on the design process and evaluating what went well and not so wellOther

2. What percentage of time do you typically spend on the design process from your experience at your currentcompany and from your experience at your previous companies?

At Current Company At Previous CompaniesIdentifying IdentifyingBrainstorming BrainstormingBenchmarking BenchmarkingDecision making Decision makingPrototyping PrototypingDocumenting DocumentingEvaluating EvaluatingReflecting ReflectingOther 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 Recording your design rationaleKnowledge about previous relevant designs Observing the potential user

^Communication with co-workers Generating a variety ot ideasTime management Other

_Knowledge about venders and manufacturers

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

The survey was designed to gain insight into four main issues. The first core question asksthe subjects to rank the enjoyability of a series of typical design tasks. The purpose of thisquestion is to establish a baseline for how the subjects feel about documentation. Thehigher the task ranking the more enjoyable and thus motivating the task is likely to be. Bycomparing the sampled data to other case study data, the second core question along withthe background questions are used to check for possible abnormalities in the sampled dataset 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 theirthoughts on their design motivation and their challenges to documentation. The purpose ofthese questions is to test the variability of design motivation and to succinctly get at theheart of the documentation problem. The fifth core question extracts what is important todesigners by asking them to rate typical information centered design activities.

A coding scheme is required to statistically analyse the third and forth core questions sincethey are open-ended. Table 1 and 2 show the coding scheme used in the analysis. Thecoding 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 andchallenges 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?"

CodeCreate

CreativeFunHelpSocial

Solving Problems

A response was marked as the code if the subject's answers...Included reference(s) to prototypes or the end product, or includedvariations of the word create, such as inventing, creation, or buildingIncluded the word "creative" or "creativity"Included the word "fun"Indicated meeting needs or improving situations or someone's lifeIndicated interaction with people, such as teams, co-workers, or customersIncluded a variation of the phrase "problem solving" or references the endsolution (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 recordingyour design rationale?"

CodeOpportunity CostFormat/Medium

DetailsSkill

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 formatIndicated level of content detail or precisionIndicated personal inability at a skill such as drawing, writing, orcommunicatingInclude the word "time"

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

3 Survey Findings

3.1 Checking Sampled Data for Cultural Bias

As this survey did not select its subjects randomly from all possible designers, but sampledonly a small subset of the designer population designing in northern California, thefindings may have an inherent bias due to the clustering of the sample pool. To investigatethe extent of this potential bias, the subjects were asked for the percent of time spent onvarious 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 culturalvalues would be the most likely source of bias error. Since this study is concerned aboutdeveloping conclusion for documentation tools, a documentation cultural bias would havethe largest impact on the survey findings. Comparing the sampled data to previous designresearch data revealed that the average percent of time spent documenting for the studentsand professional designers sampled were statistically similar to a study performed byCrispin 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 studentdesigners surveyed.

3.2 Establishing the Baseline of Documentation Motivation

Figure 3. Comparing the enjoyable nature of design tasks as an indication of designers' motivation towardsthe 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 shownin Figure 3, the results indicate that documenting is the least enjoyable task with anenjoyability score of 0.2. As motivational theories suggest, task enjoyability is an indicatorof motivation to perform the task, higher enjoyability corresponds to higher motivationand lower enjoyability corresponds to lower motivation [5]. As designers work through thedesign 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 documentationmotivation relative to other design tasks. As documentation tools incorporate incentives,the relative rank of documentation enjoyability changes in accordance to the power of theincentives.

3.3 Designers' Motivation and Design Activity Importance

As noted in the introduction, the possibility of forming incentives that are aligned withdesigners' pre-existing motivations to do design work might be a powerful way tomotivate designers to do documentation. However, in order to take advantage of these pre-existing motivations within a tool's framework, there are two prerequisites. First, the pre-existing motivations have to be fairly common across designers and second, thesecommon 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 adesigner's pre-existing motivations from a multitude of possibilities. The secondprerequisite is necessary to ensure the tool's incentives are independent of the companyculture in which the tool is deployed.

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

The survey asked, "What motivates you to do design work?" and the percent of subjectsexpressing a particular motivation are shown in Figure 4. There is some variation in thepercent of shared motivation between the students and professionals, but there is asubstantial agreement that the ability to create something motivates them to do designwork as 37.5% of the combined responses were coded as such. Only 10.9% of all theresponses could not be codified by the six categories and is a good indication that the firstprerequisite of motivation commonality is satisfied. The second prerequisite is harder toevaluate from the findings alone, but each of the high frequency response categoriessuggest a viable point to start exploring incentives that will have a wide appeal todesigners. Since designers already have an appreciation for the categories, meaningfulfeedback 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 theintroduction, designers prioritise tasks that have an immediate impact on the project'ssuccess. The survey asked the subjects to rate the level of importance of 8 typical designactivities 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 ofimportance, which is possible an effect of the question's low resolution. Designersconsider communication with co-workers and generating ideas of high importance, whileconsidering recording design rationale of only medium importance.

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

Using the top designer pleasing results from design motivation and design activityimportance, it appears a documentation tool that rewards documentation by providingfeedback related to enhancing the designers ability to create the end product from thedesigner's correspondence between co-workers would encompass a powerfuldocumentation incentive. However, it is important to remember the tools ultimateeffectiveness not only depends on the potency of its incentives, but also on the lack ofeffort required to do documentation. The next section looks at the primary areas thatdocumentation tools need to address so that incorporating incentives into the tool will havea 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 theprimary areas requiring documentation effort reduction.

1CED01-C586/472 217

In order to get a better understanding of the obstacles associated with documentation, thesurvey asked, "What do you feel is most challenging about recording your designrationale?" For these responses developing a coding scheme was more difficult than forthe 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 hinderingcapturing design rationale followed by undeveloped personal communication skills suchas writing and drawing at 19.3%.

Summary and Conclusions

By building documentation incentives into the documentation tool, the tool's dependencyon its environment can be attenuated. Understanding designers' pre-existing motivationsto do design work may point to the kinds of feedback designers find rewarding whengeared towards important design activities. This coupled with documentation effortreduction, may be the path to inventing effective documentation tools. Towards exploringthis idea, the survey results established a list of designers' pre-existing motivation to dodesign work, and how common each motivation is between designers. It also determineddesigners' perspectives on the importance of design information activities and the majorchallenges to documenting design rationale. The next step towards incorporatingincentives into documentation tools is prototyping several incentives developed fromdesigners' most common pre-existing motivations and design activity importance.Following this, the next step is incorporating these incentives into an existingdocumentation tool that exhibits high levels of documentation effort reduction. Followingthe advancement of these steps, the prototype will be tested using both student andprofessional interactive focus groups.

References

[1] Stewart, Thomas A., "Knowledge worth $1.25 billion", Fortune, 142 (13), 2000,p302

[2] Grudin, Jonathan, "Why CSCW applications fail: Problems in the design andevaluation of organisational interfaces" , Proc. Conference on Computer-SupportedCo-operative Work. ACM, 1988, pp. 85-93

[3] De Long, David A., Liam, Fahey, "Diagnosing culture barriers to knowledgemanagement", The Academy of Management Executive, 12 (4), 2000, p113-127

[4] Hales, Crispin, Analysis of the engineering design process in an industrial context.2nd Ed., Gants Hill Publications, England, 1991,p28-32

[5] Chung, Kae H., Motivational Theories and Practices. GRID Inc., Columbus,Ohio, 1977

Tamsha Lloyd and Larry LeiferStanford 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 , URL-http://www-cdr.stanford.edu/CDR/cdr.html

©IMechE2001

2is 1CED01-C586/472

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

SCALING-UP DOMAIN KNOWLEDGE REPRESENTATION IN THEDEVELOPMENT 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-cycledesign, knowledge based system scaling, design reuse

1 Introduction

Various product realisation tasks have been traditionally arranged to take place as a sequenceof activities carried out by different groups of engineers. This obviously leads to a longproduct development lead-time and high cost. Research work under concurrent engineeringtheme has improved the product lead-time by promoting concurrent task execution of majortasks in product realisation. This has made significant contribution in reducing product lead-time and cost due to re-work caused by a lack of foresight of downstream implications ofdecisions and a lack of activity co-ordination among different engineers. This concurrentengineering philosophy has made important impacts on manufacturing companies inproducing variety of products with shorter lead-time and lower cost. This approach largelyfocuses 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 promotingconcurrent consideration of a product as well as product realisation systems at early designsynthesis stage [1], This is based on the finding that 70% or more of a project total cost iscommitted at the design stage. It is only through intensive exploration of decision space that aengineer can be sure that an optimum design solution has been generated at the end of thedesign stage. This intensive exploration should be carried out for both solution space of theproduct itself and more importantly exploring the solution space of product realisationsystems. Through such explorations, the influence of any product realisation systems on theproduct can be clearly predicated fully considered at the design stage. There is an increasingtrend that a designer has to consider product life issues such as design for manufacturab;7/fyand "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 todistinguish the approach taken in this project. Unlike more traditional design for multi-X, thisapproach 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 after-design-analysis approaches. The results of these analyses are rather late as the design solutionhas already been generated. The analysis also has a segmented viewpoint as often each ofthese analyses is carried out from only one perspective e.g. design for manufacture etc. Thisresearch argues that through an intensive exploration of solutions spaces using productrealisation process knowledge usually available downstream, a designer is better supported tomake more informative design decisions, hence optimum solutions.

ICED 01-C5 86/664 219

From the viewpoint of knowledge intensive CAD system development, the successful furtherdevelopment of such systems has often been hindered by the following factors:

1) the knowledge representation method adopted for a particular domain knowledge mightnot be suitable for scaling-up the system into other domain knowledge representations;

2) increasing number of rules and new types of knowledge represented introduce newdifficulties in integrating them with the existing rules and knowledge represented.

These factors need to be analysed carefully to extend the scope of functionality of aknowledge intensive CAD (KICAD) system from one design domain to others.

The overall project aim of this research is to develop a systematic and rigorous knowledge-intensive CAD approach to proactively supporting designers in generating "life-oriented"solutions through the exploration of design alternatives using life-cycle knowledge derivedfrom concurrent modelling of the product being designed and life-cycle systems. To achievethis aim, a formalism of knowledge representation has been developed, and subsequently thishas been applied and tested in a chosen application domain- thermoplastic. Scaling up theknowledge representation into other application domains is then required to evaluate thesuitability of the formalism. Through such an extensive research and evaluation, the proactivedesign support approach based on KICAD can be further developed to incorporate widerapplication knowledge and to extend its scope of functionality. This paper discusses part ofthis much large project by focussing on the aspect of scaling up knowledge representation intosheet metal component design. Specifically the paper focuses on the concurrent modelling ofsheet metal component design and its realisation systems and lessons learned through theproject about scaling-up of KICAD system FORESEE [2],

2 Formalism and knowledge representation

To provide this research with a rigorous foundation, a semi-formal formalism has beenestablished to ensure that the knowledge representation method derived initially for theresearch can also be extended easily to other application domains. The successfuldevelopment and evaluation of the FORESEE system for thermoplastic component design hasconcluded that the proactive design synthesis approach implemented within the FORESEEprototype made designers aware of life-cycle consequences caused by an early designdecision. These consequences could be intended or unintended, good or bad. This proactivedesign support encouraged designers to explore alternatives to maximise preferredconsequences and minimise unintended consequences, resulting in desirable life-cycle designsolutions. 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 theformalism briefly in table 1. Examples of applications of the formalism both in thermoplasticdomain as well as in sheet metal component design are given in the table to illustrate that howthese 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 designand they have been successfully used to model primarily thermoplastic component design.This was used to model life-cycle consequence knowledge found mainly for thermoplasticcomponent design and the set of notation has prove to be effective in the development of firstversion of FORESEE system [1], This study extends these representation to sheet metalcomponents 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

notation symbols associaTea'wim their relationships nave been lound to be consistent withthermoplastic components and can be scaled-up to model sheet metal components. Howeverthe elements for each manipulatablc design feature have to be re-generalised from the sheetmetal components. This generalisation has proven to be easier with the defined notation.

3 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 ofdesign decisions, if not more, that need to be made during a product design. In mechanicalaspect of product design, designers make decisions on manipulatable parameters of productsfrom the following five categories: structure, form, material, dimensions, surface quality. Inthe process of making the above decisions, synthesis, analysis and evaluation always re-occuras key activities.

Design decisions are also known to have implications or consequence, on down streamproduct realization activities, intended or unintended, good or bad [3]. This is known as apropagation effect that could span over multiple life-phases. More specifically these designdecisions influence the performance of manufacturing and assembly in terms of measures

ICED 01 -C5 86/664 221

Symbol

{}

a e baA ba vba e b

a = > b

a«-»ba -* b

_,a > — b

LaJMFFa

P

D{0}

dH{0}

S<phase>i

[]

Theoretic Modelling Meaninga 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 materialsa material selected

a form featurean assembly feature

a technical process featureDecision proposal concerning

a set of options {O}an explicit synthesis decision

commitmenta space of decision proposals

life-phase 'i1

designate a chosen option ofmaterials .nrnr,p<5« ptr*

Example{[Aluminium] v [Copper] v [Stainless_steel]}

[ABS] ^{ LNon-ConductiveJ ALNon-MagneticJ}LFerrousJ A l_2*thicknessj

LNon-FerrousJ v LNon-MagneticJCutting-Operations c. Sheet-Metal-Operation

(df:{P} = Injection Moulding) => (ManufactureConsequence,,, = '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 = AluminiumDesign feature selected is a slot, F= Slot

Assembly feature is snap-fit, [FJ= Snap-fitA 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) => (MACni = 'Weak bond'S={what diameter? A what depth? }

Life-cycle phase under consideration ismanufacture, <phase>manufacture

Referring to a process [P] = Turning

such as cost, quality and time. In this paper, this observation can be formally stated as thatthose design decisions give rise to Manufacturing and Assembly Consequences (MACs).Based on a study of design decision making models and extensive research case studies, twofundamentally 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 manymanipulable primitive elements generalised from past designs. These chosen elements can bestructured into a particular configuration suitable for the design requirements. This paperadopts the axiom that there exist many design primitive features (elements), termed in thispaper as Product Design Elements (PDEs), that can be generalised and captured in a KICADsystem. 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. Inaddition, a component is processed by many systems, termed in this paperManufacturing/Assembly Tool Elements (MATEs), examples being bending tools, cupdrawing 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 metalcomponents 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 insheet metal component design. All together five punched form features, four bend formfeatures, five blank form features and four cup-drawing form features have been identified.Associated with these PDEs, relating tooling features, machine features, and product propertyfeatures have also been generalised. Detailed information can be viewed in [4].

Based on the identified PDEs and MATEs, it is possible to elicit decision consequenceknowledge both in non-interacting and interacting forms. Collectively these form the basis ofan enhanced KICAD system knowledge intensive base. In this research an extensivecollection of consequence knowledge represented in the form of rules/methods have beengenerated. These design rules/guidelines can be used for proactive design synthesis ofcomponents. These rules are coupled with the consequences that are likely to occur duringmanufacture and assembly phases of product development due to violations. Theclassification of Form, Tooling and Machine features resulted into a Knowledge Modelshowing 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 tothe designer's decision of adding & form feature onto a sheet metal component is shown infigure 1.

3.3 Consequence generation during concurrent modelling

In order to help designers to foresee design decision consequences through the understandingof interactions of several life-cycle phases during design stage, this research argues that amulti-life-cycle phase modelling approach is desirable. Specifically this paper focuses on animportant life-cycle phase - manufacturing/assembly and discusses the concurrent creation ofproduct models and manufacturing and assembly models. This approach will not only supportthe study of design decision consequences during design decision makings, the approach alsoprovides a framework to encourage designers to explore different design alternatives. Basedon the understanding of Manufacturing/Assembly consequences (MACs), it is possible toelicit them extensively and convert MACs explicitly into a form which can be codified in acomputer system for design re-use. By providing relevant MACs at an appropriate timeduring the design synthesis of the component model, it is feasible to build componentmanufacturing/assembly models at the same time that a component model is being built. Thisobservation can lead to an important change of the design process model from traditionalsequential design process followed by manufacture process design, to concurrent componentand manufacturing design and modelling. This is the key to this new product developmentparadigm that this paper describes.

4 System architecture and implementation

Based on the above understanding, a 'Knowledge of Life-Cycle Consequences' (KICC) systemarchitecture to sheetmetal component'Design Synthesis forManufacture/Assembly'has been developed (Fig.2). The extendedKICAD systemFORESEE comprises aknowledge base,working memory andinference engine.Knowledge basecontains detailedrepresentation ofreusable synthesis PDEsand MATES features inits knowledge base.Working memory storesthe information about theconcurrent synthesis ofcomponent model duringexecution of software Figure 2 System architecture of extended FORESEE for sheetInference engine is the metal component design

ICED 01 -C5 86/664 223

domain knowledge independent reasoning mechanism, containing rules/knowledge to reasonwith the information stored in the knowledge base. Knowledge base further consists ofInference knowledge, containing design consequence knowledge, and Reusable ElementsLibrary.

A set of tools has also been designed to facilitate the communication between a user and theKnowledge Base. These include: a Component Model Viewer to visualise the co-evolvingmodel of component, a Form Feature Editor to add or modify form features, a ConsequenceBrowser to see the consequence that would occur during product development caused bydesign decisions, an Alternative Design Solution Viewer in order to avoid bad consequenceand a Tooling/Machine Parameter Viewer to see the design parameters required tomanufacture a form feature.

The architecture has been implemented using MS Visual C++ version 5 on Windows NT anda new prototype system has been coded to demonstrate the scaling-up of the FORESEEsystem. Section 5 provides some description of the use of the system through screen dumps.

5 Case Study of Sheet Metal Design

A case study is presented here to demonstrate the capabilities of the improved version ofFORESEE, i.e. designing of sheet metal component through knowledge of life cycleconsequences. The case study involves adding a form (bend) feature to a sheet metalcomponent. The process of adding bend feature and getting corresponding consequencesknowledge 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 inFigure 3. The component properties as well as form feature properties are defined through theForm 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 designeris 10mm. This information together with bending operation and thickness of sheet metal

Figure 3 Desired unequal length Figure 4 Screen Capture of Foresee Dialog boxes tobend on a flat sheet metal component define Unequal Length Bend

224 ICED01-C586/664

Figure 5 Screen Capture of Violation(a), corresponding Consequence(b) and AlternativeDesign Solution/Suggestion by FORESEE (c )

triggers a piece of design decision consequence knowledge embedded in the knowledge baseof the system. As this knowledge states that the minimum leg length must be greater than 2.5xthickness + 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 throughViolation/Consequence Browser as shown in figure 5(a), which can be further expanded to theview details and explanations of violation as shown in figure 5(b). The inference engine thenuses 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 foreseethe problems that are likely to occur at the later stages of product development. This has beenshown in the above case that manufacturability of the component is not guaranteed usingcurrent bending machine to produce the bend feature specified by the designer. The extendedFORESEE system not only detects inappropriate design decisions using the consequenceknowledge, but also suggest possible remedies to avoid undesired consequence by generatingautomatically alternative design solutions/decisions. This has taken a step further toproactively support a designer to explore design alternatives for an optimum solution. Thishas also been demonstrated for the above design scenario. The extended version of FORESEEcan exhibit this proactive support feature of suggesting alternative solutions in order to avoid"Difficult to Bend" situation during manufacturing of component. The suggested solutions fordesigner to explore are shown in figure 5( c ).

This case study illustrates that the proactive design synthesis approach implemented inFORESEE helps designer in anticipating manufacture/assembly consequences of their designsolutions. In addition, this research also revealed that this consequence knowledge could befurther used to support manufacturing/assembly process design. Whilst a component model isbeing constructed during design synthesis, it is also possible and desirable to constructmanufacturing process model and tooling model. Through the interplay of a sheet metalcomponent model and its manufacture process and tooling models, a designer can gain betterinsight into the life-cycle design issues, be made aware of decision consequences todownstream activities, and more importantly be encouraged to explore design alternatives toproduce optimum design solutions [4].

6 Discussion and conclusion

This research has investigate the feasibility of extending an approach using knowledge ofconsequence phenomenon modelling into another different engineering design domain - sheetmetal 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 sheetmetal component design?" "Is the knowledge classification still suitable for the new domainknowledge?" "How can a domain specific knowledge intensive CAD system become evenmore knowledge intensive in a wider scope?" "How can such a system be extended to becomea true knowledge intensive engineering system?"[5]

Many successful prototype systems derived from research projects often have a relativelynarrow 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 extendthe 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 andeffective for the new domain -sheet metal component design and it proves that a wellestablished model is very important for knowledge intensive CAD to be extended towardsknowledge intensive engineering;

• the life-cycle consequence knowledge representation, based on the semi-formalformalism, 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 metalcomponents, 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 wasinitially thought. There is still a need to elicit domain knowledge and life-cycleconsequence knowledge in a new domain though this has proven to be easier than theoriginal knowledge acquisition for the first domain - plastic component design, due to theformalism adopted.

References

[1] Borg, J, Yan, X. T. and Juster, N. P. "Exploring decisions' influence on life-cycleperformance to aid 'design for Multi-X'", Artificial Intelligence for EngineeringDesign, Analysis and Manufacturing: 1999, 13, 91-113.

[2] Brown, D. Which way to KIC? IF IP TC5 WG5.2, In International Conference onKnowledge Intensive CAD, Vol. 2, Carnegie Mellon University, Pittsburgh, PA, USA,Chapman & Hall, 1996, .pp. 291-295.

[3] 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 ForConcurrent Engineering', Manchester, UK, 1998, pp. 169-184.

[4] Rehman, F. "An investigation into the use of metal component manufacturingknowledge to support product and process design synthesis ", MSc Dissertation, CADCentre, The University of Strathclyde, Glasgow, UK, September 2000.

[5] Tomiyama, Tetsuo, "A manufacturing Paradigm toward the 21st Century", IntegratedComputer Aided Engineering, Vol. 4, pp. 54-61, 1997 John Wiley &Sons, Inc.

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

©With Author 2001

226 ICED01-C586/664

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

RE-USING KNOWLEDGE - WHY, WHAT, AND WHERE

J S Smith and A H B Duffy

1 Introduction

Characteristically designers do not 're-invent the wheel' every time a new design instancecalls for one, their natural response is to glean from past experience and 're-use' previouslyacquired knowledge. Gao et al, [1] estimate that '90% of industrial design activity is based onvariant design' and in such a redesign case '70% of the information is re-used from previoussolutions' [2]. We see the concept of 're-using' as inherent within the natural process ofdesign. The origins of formal design re-use are found in the realms of software engineeringwhere re-use became a realistic solution to problems caused by 'increasing complexity andtime-to-market pressures' [3]. Similarly, such pressure's on engineering companies hasresulted in an increased focus on support for 'formalised re-use'.

Previously the 're-use' focus has centred on specific and/or standard parts, more recentlyhowever, '[standard components] are being developed...to enable both the re-use of the partand 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 existingshape for a different function, or may re-use a feature from another design'. Reinforcing thisnotion we currently consider 're-use' to reflect the utilisation of any knowledge gained from adesign activity and not just past designs of artefacts.

Our research concerns the improvement of formal 're-use' support and as such we haveidentified a need to gain a better understanding of how design knowledge can be utilised tosupport 're-use'. Thus, we discuss the requirements of successful 're-use' and attempt toascertain 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?

2 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 followingprovides 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 ofsoftware 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 forSynopsis 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 chipdesigners who fail to take advantage of 'formal design re-use' practices face 'unsustainablecost 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 inthe engineering design sector [7]. The study concluded that the potential benefits to anindustrial company, of applying an overall re-use approach, far exceeded the benefits theycurrently received from relying on designers' natural inclination to re-use. Figure 2summarises 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), showsthe benefits received from current 'ad-hoc' re-use practices. These provide greatest benefit totime and performance whilst the costs benefits are almost half at only 6%. The second columnin each category indicates the foreseen benefits of a formal approach to 'design re-use' whichcan be expected to provide overall benefits to time, cost, quality and performance in theregion of 20% to 28%. For instance, this can be translated into an improvement in terms ofcost benefits, over current practice, of around 360%.

Thus, it can be argued that there is significant value in re-using knowledge and experiencerelated to existing designs to support future design. The study substantiates the need forformalised approaches, methodologies and systems, in order to achieve the considerablepotential 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' arepossible and additionally how we can 'identify [re-use] mechanisms which are typical fordesign but independent of a specific design system?'. Similarly, in addressing this issue, thereseems to be only one such generalised 're-use' model, namely, the 'design re-use processmodel' [9]. Other reviewed models were, as suspected by [8], either highly dependant on theindividual 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, andits limited focus on mainly representation and recall issues, negate this as comprehensivemodel 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 agiven task, often takes much more than 1% of the effort needed to create the design in the firstplace to patch it to fit, cancelling so much of the advantage of reusing it that it may be easierto 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, thecomplex and rich design related knowledge, and (ii) providing solutions to the problems ofpartially re-using previous design solutions and their associated knowledge to effectivelysatisfy new design requirements. Accordingly, to obtain the maximum benefits of formal 're-use' requires that we optimise support for this rich and complex knowledge resource,appreciate the source, nature, and growth of design knowledge, and successfully manageknowledge acquisition, maintenance and utilisation for 're-use'. Thus, supporting re-userequires that we can ascertain: what knowledge can be re-used; how it can be maintained tomaximise its applicability; and where and when it can be utilised in new design.

3 What can we re-use?

Previously design knowledge has been referred to as complex [ 1 ] but what do we understandby the term complex, and what are the implications of this for the re-use of designknowledge? Firstly, we must consider the factors contributing to design knowledgecomplexity and secondly how these effect it's ability to be re-used. The notion of complexityis one topic that has received great attention, from mathematicians, scientists, and engineersalike, due to a lack of common definition and concrete theories. Duffy defines the factorsinfluencing 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 aspectsimpinging on the design, and knowledge and sources used and generated. Moreover, theissues affecting each of these factors further compound complexity. We can now appreciatethat even the simplest artefact is associated with a complex array of factors, which shape theactivity 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, thispresents a complex problem in terms of modelling knowledge for 're-use'. A problem furtheramplified by the differences in terms of characteristics, types, sources, forms and origins ofdesign related knowledge. If we now consider that formal support for 'design for re-use' relieson an ability to identify, extract and explicitly represent re-usable fragments of knowledgeduring design itself we gain an perception of the difficulties of supporting such complexdesign knowledge for 'exploration', and subsequent utilisation in 'design by re-use'. Tofurther complicate matters, design related knowledge can be considered from manyviewpoints 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 thedesign process'.

'Design by re-use' relies on the availability of appropriate knowledge sources. Thus, toachieve this we require a suitable knowledge modelling mechanism to support 'design for re-use' which would require to capture knowledge from differing 'sources' and 'viewpoints' andrepresent their evolution through the design activity. Thus, formal knowledge modellingmechanisms which adequately support 'design for re-use' must be capable of defining'knowledge elements' while capturing the 'relationships' between these both within andacross different 'sources' and 'viewpoints,' and the 'behaviour' of these relations as theartefact definition evolves. This would facilitate a deep 'understanding' as to how and whydesign knowledge had developed into the final artefact definition and provide the designerwith 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 'designknowledge' throughout the design activity, 'typically the only formal documentation is thefinal set of drawings' [5]. Additionally, current design tools have the effect, on the practice ofengineering design, of emphasising 'those parts of the process that were well understoodand/or easily systematised (e.g detailed design, analysis, machine path planning), whileminimising those parts that were less well understood (e.g, problem definition, synthesis andconceptual design)'[5]. Thus, without a shift in working practice/culture it remains difficult tofacilitate consistent knowledge capture as the earlier design phases, where more general,abstract knowledge is generated, are not adequately supported. The importance of supportingearlier phases is illustrated when we consider that at the end of the conceptual phaseapproximately 80% of the lifecycle costs are already committed. Thus, non-capture wouldnegate many of the cost benefits of re-use. Furthermore, documentation generated in currentpractice are generally based on a low level of abstraction e.g. geometry, tolerance, surfacefinish, manufacturing requirements. Such formal documentation leaves little or no scope forrepresenting knowledge related to the rationale, history, or product knowledge relating toconcept principles and dynamic process knowledge learnt through experience. Thiscontributes to the difficulty of managing the complexity of product knowledge in that a vastproportion of the quantity of generated knowledge related to other complexity factors are notcaptured explicitly and thus cannot be re-used. Hence, there is a limited range of availableknowledge related to relationships and their behaviours at a more abstract level of design.Consequently our understanding of how knowledge elements relating to function, behaviourand solution concepts, decision making, the design activity, actors and aspects and designalternatives 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 tothe earlier synthesis stages of design, and restricts 're-use' principally to support detaileddesign (standardised parts, manufacturing methods, etc.). In addition, it presents problemswhen attempting to partially re-use a design solution, or its associated knowledge. Thedesigner has no understanding of the 'evolution' of the designed artefact, no knowledge of thefunction, solution, and mechanism concepts realised by the artefacts components and/orpossible 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 theavailable 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 designedartefact are key elements to the 're-use' approach. Capturing such high level knowledge canfacilitate a 're-use' approach applicable far earlier in the design process.

4 Utilising knowledge in design re-use

Having established a case for the 're-use of design knowledge and identified the need tosupport and manage re-usable knowledge sources from the inception of a design activity wemust now consider its applicability to new situations.

Mostow, et al [11] debate whether re-using a previous design can be justified in terms of theadditional effort required to make it 'fit'. Unlike the direct re-use of code, adders, modulesand microprocessors in the field of software engineering, as engineering design deals 'withmore abstract concepts' [14]. However, Mostow, et al [11] further maintain that despite thedifficulties of partial re-use, human designers do 'modify the structure of a design to fit a newapplication' 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 tofit 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 thesuccess of a re-use approach there is a need to overcome such problems by supporting andmaintaining knowledge acquired through design experience (explicit and implicit) to supportits 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 fromexperience, an effective 're-use' approach must encompass elements of this 'learning' processto extend the approach's ability to utilise design knowledge and support re-use of partialsolutions [11]. Here, (as shown in Figure 5) we consider learning to be a process of acquiringnew knowledge, the modification of existing knowledge and the generation of newknowledge.

Duffy [15] states that 'learning helps to maintain experiential knowledge', which representsone of the most powerful resources a designer possesses. Such maintenance of experientialdesign knowledge, through abstraction from the specific to general, supports the dynamicnature of knowledge and prevents knowledge related to design experiences from becomingstatic and obsolete. Such activities as 'abstraction and generalisation' extend the utilisationcapabilities of knowledge in a 'design by re-use' process as they 'promote the flexibility ofexperiences by removing highly specific details and generating more generally applicableknowledge'. 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 knowledgefrom 'a design that is not 100% 'right' to a new situation'.

Figure 4 -The Learning Activities [15]

5 Where - the applicability of knowledge re-use

Having established 'design re-use' as an approach concerned with the provision of support forthe capture, management and subsequent utilisation of design knowledge, gained fromprevious experience, to further new design. Now we consider the applicability of such anapproach 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 solelyconcerned with aiding new design by re-using past design solutions. However, the conceptcan be further extended to include not only this phenomena of 'designing by re-use' but alsothat of 'designing for re-use', whereby the design process and potential solutions arespecifically managed and created to promote their future re-use. Indeed an industry basedbrainstorming program, [20] highlighted the need for capturing design information into thedesign re-use system whilst a design is being carried out. Addressing this 'design re-useprocess model' considers re-use as a total process which, with the support of well developedtools and methods, can encompass all phases of the design life cycle. Thus, a comprehensiveapproach to 'design re-use' should emphasise support, management and utilisation of designknowledge 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 issuesas: an avoidance of previous design faults and unnecessary re-invention; duplication of designsuccess; and the use of known and proven characteristics [9]. This may suggest that re-use isrelevant only to variant (repeat order) or adaptive (evolutionary) design as these issues arereadily 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 moreapparent than to that of original (innovative) design. However, as 'competitive advantage isnow obtained by innovation and creation of knowledge rather than access to financial ormaterial 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, whichlie 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 explicitknowledge, not previously available [21]. Thus, innovation in the design process can beconsidered as instances where 'new variables are introduced into the design process' and 'thestate space is expanded' [22]. Thus, the conflict between re-use and innovation arises from theperception of re-use as merely an approach to support and maintain already existingknowledge where innovation requires that new knowledge be created and/or added to thedesign process. For example, the perception of re-use as a facilitator of negative designfixation (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 permittingabstraction and generalisation of this knowledge to generate or modify knowledge. Thus, theprocesses is synonymous with knowledge maintenance can not only prevent its stagnation orobsolescence, increase it's applicability to new design, but also support the 'utilisation' of re-usable knowledge in original design environments. Further effective generalisation of designknowledge can increase applicability for design not only within a single domain but due to theremoval of 'case and domain specific' knowledge it can also be utilised to effectively supportthe re-use of knowledge across distinct domains.

6 Conclusion

In answer to the question: 'design knowledge re-use' -why what and where? We have shownthat there is significant value in capturing and re-using the knowledge and experience ofcurrent and past designs. In addition, we acknowledge that a greater understanding of the roleof knowledge in 're-use' is required. We establish within the spectrum of a comprehensive re-use model, that the knowledge generated throughout the evolution of a design requires aconsistent approach to its capture, modelling and structuring. However, it has also beenshown that for effective 'exploration' and 're-use', such knowledge must be maintained toprevent its stagnation and improve its applicability. Further, learning from design knowledgeby generalising, removing the specifics of a design case and/or aspects of the domain, isshown to generate a source of knowledge with greater applicability within and acrossdomains. In addition, this generalisation supports partial re-use of past cases (and theirassociated knowledge), and can facilitate positive 'design fixation'. Such 'formally' supporteddesign knowledge' extends the 're-use' approach to both earlier stages in the design processand 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 toSupport Re-use in Case-based Mechanical Design", Knowledge Based Systems, Vol.10,1998, p337-350.

[2] Khadilkar, D.V. and Stauffer, L.A., "An Experimental Evaluation of DesignInformation Reuse During Conceptual Design", Journal of Engineering Design, Vol.7,No.4, 1996, p. 331-339.

[3] Jones, M.E., "Reusing Integrated Circuit Designs", Computer Design, July, 1995

[4] Culley, S.J., "Design Re-use of Standard Parts", Keynote Paper, in Proceedings ofDesign Reuse - Engineering Design Conference, Brunei University, UK, 1998

ICED 01 -C586/048 233

[5] Finger, S., "Design Reuse and Design Research", Keynote Paper, in Proceedings ofDesign Reuse - Engineering Design Conference, Brunei University, London, 1998.

[6] Synopsys Inc., "Who can Afford a $193 Million Chip?", Synopsys Design Reuse CostModel" 1999.

[7] Duffy, A.H.B., and Ferns, A.F., "An Analysis of Design Reuse Benefits," inProceedings of the International Conference on Engineering Design, Munich, 1999.

[8] Altmeyer, J., and Schurmann, B., "On Design Formalisation and Retrieval of ReuseCandidates", Artificial Intelligence in Design, Kluwer Academic Publishers, 1996.

[9] Duffy, S.M., Duffy A.H.B., and MacCallum, K.J., "A Design Reuse Model", inProceedings of the International Conference On Engineering Design, Praha, 1995.

[10] Maher, M.L., Garza, A.G., "Case-Based Reasoning in Design", IEEE Expert,March/April, Vol.12, No.2, p34-41, 1997.

[11] Mostow, J., Barley, M., and Weinrich, T., "Automated Reuse of Design Plans", inArtificial Intelligence in Engineering Design, p. 2-15, 1993.

[12] Duffy, S.M., "The Design Coordination Framework and the Design Complexity Map",Integrated Production Systems Research Seminar, Fugsl0centret, Fugsl0, 3-5th April,1995.

[13] Brice, A., and Johns, B., "Improving Process Design by Improving the Design Process,A DRAMA white paper, QuantiSci, 1998.

[14] 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.

[15] Duffy, A.H.B., "The "What" and "How" of Learning in Design", IEEE Expert,May/June, p. 71-76, 1997.

[16] Deneux, D., and Wang, X.H., "A Knowledge Model for Functional Re-design",Engineering Applications of Artificial Intelligence, Vol. 13, p. 85-98, 2000.

[17] Altmeyer, J., and Noll B., "RODEO - Reuse of Design Objects", p. 1-2, 1998.

[18] Henninger, S., "Accelerating the Successful Reuse of Problem Solving KnowledgeThrough the Domain Lifecycle", in 4th International Conference on Software Reuse,IEEE, 1996:

[19] Fothergill, P., Lacunza, J.A., and Arana, I., "DEKLARE: A Methodological Approachto RE-DESIGN", Aberdeen University, Copreci S. Coop. Ltd: Dept of ComputingScience, Aberdeen University 1994.

[20] Shanin, T.M.M., Andrews, P.T.J., and Sivaloganathan S., "A Design Reuse System, inProceedings of Design Reuse - Engineering Design Conference, Brunei University, UK,1998

[21] Preiss, K., "Modelling of Knowledge Flows and their Impact" Journal of KnowledgeManagement, Vol.3, No.l, p. 36-46. 1999.

[22] Gero, J.S., and Maher M.L., "Theoretical Requirements for Creative Design byAnalogy", Colorado State University Fort Collins, 1990.

Joanne S Smith

CAD Centre, DMEM Department, University of Strathclyde, M209, James Weir Building, 75Montrose 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

DOCUMENTATION AND EVALUATION IN EARLY STAGES OF THEPRODUCT DEVELOPMENT PROCESS

L Schwankl

Keywords: Design information management, information representation, systematic productdevelopment.

1 Introduction

For developing innovative products for new markets in the context of high demandingtechnology development projects, often different creative methods are used by developmentteams. In this way, the teams are able to create a high number of concept ideas within a shortperiod of time. Due to the exchange of team members, often practiced in developmentprojects, it is very difficult to keep an overview of which ideas are already known and whichare perfectly new. In the context of different development projects [3,4] at the Institute ofProduct Development at the Technische Universitat Miinchen these problems were detectedand 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. Ina second step, the essential structure of this form has been modelled in a data base, whichpermits archiving concepts and a computer aided evaluation. The main problem is, if the ideasare not documented in a practical manner, that they are lost.

For supporting the information generating process, there are several methods and differenttools, to analyse product properties in the early stages of the development process. Relevantparameters, 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 MethodSelection System.

By the application of different analysis methods in the early stages [1] of the productdevelopment process, relevant information will be compiled, which is the crucial importancefor further development. Many of the concept ideas sketched in creative meetings are usuallyno longer comprehensible after a short period of time. Neither the relevant components wereindicated nor the function was described clearly. Often an exact description of the functiontakes place only in verbal form, as started in the later discussion. It is very difficult for mostof the team members to interpret sketches correctly a few days after, and it is virtuallyimpossible 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 questionsdiscussed. Nevertheless, these ideas could sometimes be valuable for following steps in theproject, other projects, or other project teams, who may be interested in them. This wasnoticed several times in the context of different development projects.

2 Documentation in early stages

In the early stages of product development processes, important decisions [2] are made and aquantity of information is collected, which is useful, and often urgently necessary for thewhole development process. For this reason different tools supporting the documentationduring the whole process have been developed at the Institute of Product Development. Tofind new solutions, we use several innovation stimulating methods [5], e.g. brainstorming, themethod 6-3-5, and parts of the TRIZ (Theory of Inventive Problem Solving) method. Also weuse catalogues with physical effects and different check lists. With such methods you canproduce a great number of new ideas with a high quality in a short time. In this chapter, theform 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), inwhich you can fill in either text or sketches; the most important of them will be describednext:

Sketching area:

Here, the concepts can be sketched in the usual way. Relevant components should be markedand 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 themduring the creation of the sketches. Using this forms, disadvantages were often realized, suchas 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 thisarea. In the later discussion, the critical questions can be clarified together or the necessaryanalyses 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 informationaccording to the ideas. Having common ground with the sketches, understanding of the ideashould be no problem.

We recognised that you can find out many interesting aspects belonging to the idea during thedescription (writing down) of its main functions.

Text field:

The text field, as known from manufacturing drawings, is used for organisational informationonly, e.g. name of project and name of creator, and includes the summarised results of theevaluation process.

You should enter the important things, you have found out during the discussion after thebrainstorming, on the form. So it is assured that you have documented all the informationwhich 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, theevaluation 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 transferredafterwards 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 arealso encouraged by the design of the form to use all the individual areas. Thus, on the onehand 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. Forexample, 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 logicalelements (for yes/no distinction). Within the sketching area, it is possible to merge scans orsketches 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 wereimplemented. Apart from a total summary, which contains all available data, still furtheroutput 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 theconcepts, should also be entered into the database for further handling. So you can fastlygenerate an extensive information storage, which is very helpful as well for single developersas for the whole company.

Figure 3: Database for concept ideas

3 Early analysis of product properties

The next step after generating ideas is to analyse and evaluate them in the early stages of theprocess. 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 earlystages.

In order to reduce the high risk, on the one hand it is necessary to collect as many informationas possible in the early stages of the product development process. On the other hand, youmust analyse the important product properties with suitable methods, that will need time andmoney. So you can get a complete understanding of the task and make the right decisions veryearly 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 probabilityof success relying on products which are developed for new markets and simultaneously baseon new technologies is only 5 %. So these products are a high risk for the company, becausethe effort for their development is normally 15 times higher than developing standardproducts (see figure 4). Using suitable tools and methods you can reduce this risk and increasethe 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 thedevelopment process, different methods and tools are used. For example testing componentsto 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 verifiedconcepts 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 needfor information), which have to be clarified before the evaluation process can start, arerepetitive standard questions (e.g. relating to assembly, fabrication).

A second criterion is whether the response should be qualitative or quantitative. Thesestandard 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 inearly stages of product development process. The user receives a short description andimportant hints using the methods, notes on training and application [2], and an estimation ofthe 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 anda 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 tomarket) are in the same area of the diagram. Then you can combine them to groups forcommon handling in the following steps of the process. In addition to that, the portfolio helpsyou to identify a proper ranking for analysing the ideas. At the beginning, you look intenselyto solutions, which fulfil all the requirements in the best way and which can be realised in ashort period of time.

Figure 5: different solutions with similar properties

4 Implementation and verification

The form for documenting concept ideas during creative sessions has already been used inseveral projects, such as the development of electromagnetic brake-systems, an testing engineand seat-systems for cars and buses. In this projects we could increase the quality of thesketches 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 tovarious criteria, which is very useful for further handling. The biggest advantage of this database is its simple structure, which allows user defined modifications if required in a shorttime. So you have a tool, you can adjust to your project and to the general conditions. Youcan 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 makesthe 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 formfor documentation and stored them in our data base. The implemented output formatssupported the further handling of the ideas, like the pre-evaluation process and the earlyanalysis of important product properties. With the help of the Method Selection System wehave chosen qualified methods in a short period of time. At the end, we had numeroussolutions for new, innovative and patentable brake systems.

5 Future work

In the next step, the application of electronic sketch boards will be examined. The teammembers will sketch their concept ideas directly on small sketch boards [figure 6], which areconnected to the computer. Thus, the data are available in the computer which avoidstransferring the sketches with a scanner or drafting them again with drafting software. Theusers can enter available information directly into specific arrays of the data base with akeyboard. In further case studies the acceptance of this procedure and the impact on quality ofthe 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 isgenerated during this discussion (often modifications are done or other versions of thisconcepts 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 developmentprocesses for example during video conferences. All members have access to the sketchedideas, they can have a look on them on their own display and modify them. So it is guaranteedthat all members have the same information at the same time.

6 Conclusion

The form and the data base have already been used successfully in several developmentprojects. Using the form with given areas, more information is demanded from the personwho is sketching the concept than by the use of simple sketching paper. A further advantage isthat 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 formulatingcritical questions, identifying relevant parameters and selecting an analysis procedure incommon, the methodical evaluation process becomes easier. Apart from archiving the ideas,there are also different visualization possibilities and a simple data exchange between varioussoftware programmes.

By consistent documentation with the tools presented here an extensive knowledge andinformation base can be established in a short period. Employees, in particular the newemployees, can get an overview of all projects done at the company and also use this database to suggest new creative concepts.

References:

[1] Bernard, R., "Early Evaluation of Product Properties within the Integrated ProductDevelopment". Shaker Verlag: Aachen 1999.

[2] Ehrlenspiel, K., "Integrierte Produktentwicklung". Miinchen, Wien: Carl Hanser Verlag1995.

[3] Gierhardt, H. et al., "24h-Entwicklung - Bin Grundlagenprojekt in derAntriebsentwicklung". Entwicklung im Karosseriebau.l 1./12. Mai Hamburg, vdiBericht 1543

[4] Schwankl, L.; Pache, M., "Collaboration between University and Industry inEngineering Design". Co-Designing 2000

[5] Malorny, Ch.; Schwarz, W.; Backerra, H., ..Die sieben Kreativitatswerkzeuge K7.Kreative Prozesse anstoSen. Innovationen fordern". Miinchen: Hanser Verlag 1997.

Ludwig SchwanklTechnische 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

MAPPING EXPERIENCE - LEARNING FROM EXPERIENCE OF PEERSTHROUGH SOCIO-TECHNICAL INTERACTIONS

T Liang, D G Bell, and L J Leifer

Keywords: knowledge and information management, design reuse, lessons learned systems

1 Introduction

In project-oriented product development communities, the ability for designers to learn fromthe experience of others across projects enables them to build upon and subsequently advancethe performance-baseline previously established by their peers [1]. This not only applies toexperience associated with particular products, but also with particular processes. In fact,learning from other's experience associated with processes has been identified as a criticalfactor for product development firms to maintain a competitive advantage [2]. To bettersupport 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 experienceacross project teams. While such systems have shown demonstrable success in contexts suchas field service [3], they have not shown comparable success in product development.Studies of such systems in product development indicate that purely technical approacheshave inherent limitations, and that social issues are an important contributor to effectivelearning [4, 5]. This study presents empirical findings on learning from the experiences ofpeers in product development, with particular focus on learning about product developmentprocesses through social interactions. This study identifies features of peer-to-peerinteractions that are significant for effective learning, and outlines implications for the designof related social-technical systems.

2 Research settings and methods

The setting of this study was the product development organization of a large multi-nationalfirm, which develops office machines and uses an enterprise-wide product developmentprocess. The organization has many product programs working in various phases of thefirm's product development process, and one of the prescribed elements of the formal processthat teams struggle with is program planning for technology readiness. At the beginning ofeach phase, each product program must have a detailed program plan that estimates the timeand resources necessary to complete the upcoming phase, and includes a detailed schedule fortasks and deliverables. At the end of each phase, the program's progress is judged against thedetails of their program plan. Teams struggle with making plans that are simultaneouslycompelling and achievable.

This study involved an intervention, where peers from three relatively similar productprograms interacted with the goal of helping one of the programs learn from the experienceof the other two with regard to program planning for technology readiness. The interventionlasted for three and a half hours, and involved a total of nine participants. Two of the threeparticipants from the peer programs were the technical leaders of their respective productprograms. 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 teamdecided 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, severalsignificant social features of interaction were observed, and a descriptive model of theinteractions was constructed. These observations, in turn, helped produce several keyrequirements for the design of future systems intended to support learning from theexperience of peers in product development. This study was guided by the following twoquestions:

1. What are the significant social features of interaction that facilitate learning from theexperience of peers in product development?

2. What are the sotio-technical design implications of such features for learning from theexperience of peers in product development?

2.1 Interaction analysis methodologyAn interaction analysis methodology was used to analyze the video and audio record of theinteractions that occurred among participants. This method was adapted from that outlined byJordan and Henderson [6], which includes group analysis of video records in conjunctionwith ethnographic fieldwork. This method relies on a combination of participant observation,in-situ interviewing, historical reconstruction, and analysis of artifacts, documents, andnetworks for providing the framing context. In this study, multiple cycles of interactionanalysis were performed. In each cycle the observations from the previous cycle was furthertested, evaluated, and refined. Specifically, the analysis cycle employed in this studyconsisted of the following four steps: 1) identifying conversational threads, 2) interpretinginteractions, 3) characterizing features of interactions, and 4) testing generality ofcharacterization. These four steps are outlined below.

Identifying conversational threads

A transcript of the event was first analyzed for conversational threads. The purpose was toobtain an overall understanding of the topics being discussed in the event, and to aid furtheranalysis by dividing the transcript into manageable segments. An expected side benefit wasthat the process of identifying threads would also help to identify the most significantsegments 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 theproduct programs, of the participants, and of the event itself. The threads were organized intotwo levels, with the first level being a broad topic and the second being the specific issueunder that topic.

Interpreting interactions

A large amount of analysis work in the early cycles was spent on semantically interpretingthe interactions. Interpreting and understanding these interactions were greatly aided by 1)the researchers' formal training in product development; 2) the deep understanding of thecontext that was acquired through ethnographic studies; and 3) the fact that the researchersparticipated 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 reliableset of features of interactions. The semantic interpretation in the previous step provided thein-depth understanding of the interaction that was necessary to perform this analysis. In thisstep, each exchange of interaction in the event was characterized in terms of interactionalmoves. These characterizations of interaction gradually evolved with each cycle of analysis.The characterization informed better semantic interpretation of the data, which in turn helpedto build better characterization of the features of interaction. In the end, a relatively stable setof 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 thatwere tested generally true in the event were added to a list of significant features. Forexample, it was observed that learning members verified lessons that they heard from onepeer with another peer. Once this feature was identified, the rest of the transcript wassearched to see if this occurred repeatedly throughout the event.

3 Observed features of interaction and a descriptive modelAs the event data is rich and is much more than we can show in this paper, we will describethree most significant features of interaction that were observed, and offer brief examples tosubstantiate these observations.

Context comparison is a key to making sense of the conversation

Context comparison activities such as comparing progress between the learning program andthe peer programs were observed throughout the event. Context comparison allows theexperienced peers to better understand the context of the learning team, and thus allow themto prioritize what experience to share and how to share it. More importantly, contextcomparison also enabled the learning members to judge the applicability of others'experience to their own program. Through the act of context comparison, the participantsconverged onto a set of terms and metrics, which are typically found in documents used formanaging the product development process. These terms and metrics became the commonreferences 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 adocument typically used by the management to benchmark program duration. In thisdocument, all product programs in the company are grouped into nine categories according toproduct newness and complexity. For each of the categories, a set of benchmark data isoffered so new programs can have a sense of the amount of time that it takes to develop aproduct 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 ofsimilar newness and complexity to the peer programs, such that their experiences weredirectly 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 bringslong and detailed reflections from the experienced peers. The detailed nature of thereflections allows the learning members to project the reflected experience onto their ownprogram and draw actionable implications for the near future. Furthermore, the details allowthe 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 todeal with shifting phase-gate review criteria, on which the program team was periodicallyassessed according to the firm's product development process. Because of a recent change onthe formal process, some of the deliverables from the next product development phase wereshifted upwards into the phase for which the learning program was planning. The programleader was frustrated about this change because the shift made all benchmark data in thenewness-complexity document invalid. Without the benchmark data on the amount of time ittook similar programs to complete the phase, the program leader was left with a much moredifficult job of planning for the next phase. After clearly stating the problem, the programleader voiced her frustration and asked, "So, tell me how those benchmarks change whenyou've now moved the phase-one exit line?" Her problem statement set off one of the mostdetailed reflections from the peers during the event. It was evident from the program leader'slater 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 observedfrom the event data. It was observed that learning members tended to verify the significanceof a lesson they heard from one peer with the second peer, as well as to verify the accuracy ofthe lesson by repeating them back to their peers.

Afforded by the interactive settings, the learning members not only formulated in their ownterms the experience as described by their peers, but also stated them in front of their peersand gave them a chance to correct or supplement if necessary. For example, after hearingfrom the first peer the fact that they underestimated the time to develop the full hardware forthe test system, the program leader turned to the second peer and asked, "Was that true withyour program too?" The program leader sensed that the lesson might have some significanceeven before she asked the question, and with confirmation from the second peer, she verifiedthe significance of the lesson. When verifying the accuracy of the lesson, learning membersrestated the lesson as well as its implications in their own terms, and restated them in theform of a summary or sometimes as a "think-out-loud" projection. For example, shortly afterthe second peer confirmed the significance of the lesson, the program leader said, "So, Iheard you say, don't underestimate what it takes to build full-system hardware..." Similar tothis, after hearing from the peers the importance of involving the program reviewers in theplanning process, the program leader stated, "So, we need to get our reviewers' buy-in at theplanning stage."

246 ICED01-C586/478

3.1 Experience Mapping - A descriptive model

The five significant interactional moves that emerged from the analysis were: contextcomparison, problem statement, localized reflection, meaning clarification, and implicationverification. To describe these interactional moves and the sequential relationship amongthem, a descriptive model was constructed. Given that this model came from data gatheredfrom one event, it is not meant to be a comprehensive model that would fit all interactivelearning situations, although it is believed that it is general enough so it is applicable to manysituations of learning from experience of peers in organizations. The purpose here is to helpto 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 theproduct development context.

This model lies at the heart of this mode of learning here being characterized as ExperienceMapping. Through activities in this model, experience from one context is mapped ontoanother. Here, mapping implies not only surveying the past experience, but also navigatingthrough 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 weremostly initiated by the learning members. Context comparison was initiated by both partiesand occurred in various points throughout the event. Localized reflection was mostly initiatedby the experienced peers, but was usually prompted by the program team's problemstatements.

The arrows in the diagram indicate the usual sequence of action, which is by no means theonly sequence possible. In fact, the interaction sequences were routinely broken by contextcomparison activities throughout the event. An interaction sequence usually starts withproblem statement where a learning member stated a need or a problem, or voiced his or herfrustration over a matter. That would usually set off a round of localized reflection from theexperienced peers, which is sometimes followed by questions from the learning membersasking for quick and straightforward clarifications. Finally, with the reflections from theirpeers, the learning members would reconfirm with the peers by summarizing those lessons intheir own terms. Then they would also express their project actions and obtain validation onthe 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 politicalcontext. Thus, the interaction between peers is inevitably influenced by the intricate social-political 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 areorganizationally consequential. While the experienced peers are teachers in this event, theycan also be peer reviewers who will assess the performance of the program at a future phase-gate review. In any case, they are peers of the reviewers and their opinions of the programcan be extremely influential to the reviewers. Although the program members felt the need totalk about the problems that they were facing in order to obtain concrete lessons from theirpeers, they had to be careful about what was disclosed because their words would partiallymake up the reputation of their program. This tension between disclosing enough informationto learning and portraying a competent image was apparent in multiple occasions in theevent.

For example, at one point during the event the learning program leader felt that she needed toexplain her technology before she could obtain valuable advice from her peers. She thenselected a few slides and presented an overview of the technology. One of the peers wasnervous about the fact that some of the technologies are so new that they might still beunproven, the peer voiced that concern and said, "so, I'd start asking, has anybody ever doneanything like this? Inside or outside the company?" The program leader started defendingher 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, attimes the experienced peers also had to do the same. For example, after some conversations itbecame clear to the learning program leader that the peer program was able to pass a phasereview without having fully completed their prescribed deliverables. Paraphrased here, theprogram leader essentially asked, "How did you get away with that? Is there a fudge factorwith the process?"

4 Socio-technical design implicationsThe interaction-based framework used in this study provided face-to-face interaction betweenlearning members and their peers. The interaction enabled negotiation of meaning betweenthe learning members and the experienced peers that is observed to be necessary for effectiveinter-team learning in product development contexts. Taking a socio-technical approach, webelieve that some of the interactions observed in this event can be supported by socio-technical systems. Here, we offer implications of the observations as design requirements.These socio-technical requirements become useful when trying to scale an interaction-basedsystem to a larger community. Although we also provide brief discussions of possiblesolutions with current technologies, we believe that a whole new level of social awareness isrequired to design tools to support inter-team knowledge sharing and learning in productdevelopment. 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 thepeers through their reflection. It was also observed that there is tension between disclosingone's problems and protecting one's reputation. In order for the learning members to talksomewhat freely about their problems and frustrations, and for the appropriate peers toprovide 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 limitedto the people in the room. Participants appeared moderate what they disclosed based on theirexisting relationships and knowledge of each other. Furthermore, the dynamics ofconversation interplayed with interaction in such a way that the topic of discussion wasinteractively negotiated between the participants.

With the distribution of product development communities around the world, the ability tointeract in the same physical space can be limited, and information technology such as on-line forums can support distributed interactions that transcend physical proximity.Implications for designing semi-private interactional spaces in such distributed contextsinclude providing technologies that not only support dynamic interaction (synchronous andasynchronous), but also enable participants to control who has access to their verbatimdisclosures 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 wasinduced by a demand from the learning members. Therefore, a system needs to providelearning members an avenue to express their immediate problems and needs, and allow theexperienced peers to understand the necessary background context to provide a usefulreflection of their relevant experience. The system can provide some basic contextualinformation about the learning member's background and a description of the productprogram in which the learning member is engaged. Furthermore, the system should provideenough information for the experienced peer to contact the learning member, perhaps evenanonymously 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'simportant that the structures support problem- or need-centered interactions, as well asmultiple interpretations and perspectives. This will help learning members and experiencedpeers from different functional backgrounds and organizational roles to see problems fromtheir own perspective. While structures for demand-driven and localized reflections can bemade explicit in the technologies, the structures can also be left to the domain of socialpractice. In this case, the technology should support flexible interactions where participantscan 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 thelearning team and their peers. As observed from the analysis, many of these objects wereprocess-oriented documents that were used in day-to-day operations. In this study, objects ofcomparison like the product complexity matrix were used strategically for comparingcontexts. These shared objects were used both to identify the most appropriate peers prior tothe interaction, and were used during the interaction to facilitation communication andaddress relevance through context comparison.

Information technology can support both uses of shared objects of comparison, howevertechnology should not prescribe the objects since they can change over time and are oftensocially constructed. The technology should support objects that are locally meaningful, andin the context of product development processes an implication is that they account forlocally meaningful characteristics of product complexity and processes. Technology shouldallow users to define locally meaningful metrics of comparison, and to assign values to thosemetrics for context comparison.

ICED 01 -C586/478 249

5 Discussion and conclusionRecent advent of computer and internet technologies brought forth many affordances thathave the promise of breaking the physical barriers of space and time. Undoubtedly, some ofthese technologies have already drastically changed the way we work and live. In the contextof learning from the experience of peers in product development communities, many toolswere designed to take advantage of these affordances. While most of these tools focused ondistribution of documents across space and time, they lack the support for negotiation ofmeaning through interaction that is necessary for effective learning of peer experience inproduct development contexts. With the deeper understanding of how negotiation of meaningtakes place through interaction, we can embark to design a new generation of socio-technicalsolutions that can support it. Furthermore, since learning is such a situated and socialphenomena, we strongly advocate that the implications from these new-found insights beaddressed during the design of the solution, not outside the design or after implementation.

AcknowledgementThe research was supported (in part) by the MIT Center for Innovation in ProductDevelopment 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 TheInternational Conference on Problems of Control and Modeling in Complex Systems(CPCMCS). 1999. Samara, Russia.

[2] Wheelwright, S.C. and K.B. Clark, Revolutionizing product development: quantumleaps in speed, efficiency, and quality. 1992, New York, Toronto: Free Press; MaxwellMacmillan Canada; Maxwell Macmillan International, xiv, 364.

[3] Bell, D.G., et al., Dynamic documents and situated processes: building on localknowledge in field service, in Information and Process Integration in Enterprises:Rethinking Documents, T. Wakayama, et al., Editors. 1997, Kluwer AcademicPublishers: Norwell, MA.

[4] Liang, T., Mapping Experience: Understanding Socio-Technical Inter-TeamKnowledge Sharing in Product Development Communities, in Department ofMechanical Engineering. 2000, Stanford University: Stanford, CA. p. 140.

[5] Liang, T., Bell, D.G., and Leifer, L.J. "Re-use or re-invent?: Understanding andSupporting Learning from Experience of Peers in a Product Development Community,"Forthcoming in Journal of Engineering Education, 2001.

[6] Jordan, B. and A. Henderson, Interaction Analysis: Foundations and Practice. 1994,Institute for Research in Learning: Menlo Park, CA. p. 71.

First author: Tao LiangXerox 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 DESIGNICED 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 industrialcompanies: they have to reduce cycle times, they should decrease costs, they should ensureand improve the quality of their products and they should offer new solutions - to name onlythe most frequently claimed demands for product development. But regarding the differentrequirements and the complex process of designing, the necessity to produce useable andnovel solutions seems to be the most comprehensive and challenging requirement in order toface world-wide competition. Thus, creativity and innovation seem to be the keycharacteristics of successful design practise. Although a lot of authors discuss severaldifferent origins of creativity such as divine gift, persistence, perceptual knowledge, and someother, in empirical investigations knowledge and experience prevail as the main ingredientsfor the development of new products and solutions [1].

Moreover the significance of information transfer of experience during the design processmust be addressed. With increasing complexity of technology individuals have to worktogether in order to raise individual solutions, which are part of a major common product, to ashared level. Furthermore, experience is an individual characteristic that can be exchangedthrough communication, however. Thus, the question arises how the transfer of experiencecan 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 ofcritical situations in an efficient way. This means that on the one hand experience isconsidered as an individual cognitive prerequisite in the individual designer and on the otherhand, experience is seen as an important part of the information transfer process, in thecontext of collaboration and communication.

2 Characteristics of experience

Experience is acquired mostly through extended deliberate practice, thus expertise is formedin a multitude of different situations and their constituents in the specific workingenvironment, in which more or less appropriate actions are taken [2]. But what are the specificcharacteristics of an experienced person?

2.1 Characteristics distinguishing experts and non-experts

The most empirical studies about expertise are investigations about the differences of expertand 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 differentcognitive models. Nevertheless it should be mentioned that expertise should be seen as acontinuum, with the outstanding expert on the one edge and the novice with rather modestexperience on the other. In addition expertise comprises different components such as generaland specific knowledge, methodological knowledge, skills and self-management strategies.According to the results of empirical studies differences between experts and non-experts canbe attached to three different levels [4]:

• General process: There are differences between experts and non-experts in regard to therapidity and accuracy of the general information process.

• Knowledge-organisation: There are differences in regard to the organisation ofknowledge. 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, thatis the organisation of knowledge.

• Cognitive-complexity: Experts build more complex representations of information, and itis supposed that experts do have a higher capacity of the working memory. The reasonmay 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 lessexperienced designers, it seems worthwhile to mention some important results in short.

Gilnther [5] aimed to compare the strategies of experienced designers without education indesign methodology (p-designers) and designers with education in design methodology (m-designers) in a laboratory experiment. He found that the p-designers needed 30% less time inthe average than the m-designers in completing a good or satisfactory solution. The reasonwas that experienced designers spent less time on conceptual design, elaborated fewervariants, did less documentation of the process and partly skipped phases of the designprocess. These results illustrate that the experienced designer seems to be a victim of the timeconstraints of the daily work. The one satisfactory solution produced in a short time is moreappealing 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-orientedprocess" and states that the time-oriented process provides solutions 'state-of-the-art', mostlyonly very few concepts, whereas the quality-oriented process produces innovative solutions.

Eckert, Stacey and Wiley [6] report about the burnout syndrome of experienced designers asan escalation of the effects of pressure on expert designers with the consequence of a decreaseof creativity. Whereas time-pressure is only one limiting factor equally true for experiencedand less experienced designers, Purcell and Gero [7] illustrate the aspect of mental fixationwhich is mainly a problem of experienced designers. This problem arises because designerswith 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 theelements from previous similar problem situations, which may not be relevant in the actualsituation and thus may lead to incorrect or at the best to conservative solutions. These resultshighlight the danger of experience. Experience is mainly used to design quick routinesolutions whereas the ability to produce innovative ideas decreases.

252 ICED01-C586/531

Reflecting these results encourages a differentiation of the requirements of design. Designersare confronted with ill-structured problems as well as with well-structured problems, so that itseems worthwhile to follow the differentiation of Hatano & Inagaki [8] between routine-expertise and adaptive expertise. Routine expertise is mainly developed in the field of work,which is characterised by constant and repeating requirements whereas adaptive expertisedevelops especially in the context of changing requirements and problems. In the process ofthe repeated performance parts of the involved knowledge may become unconscious and maymutate 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 transfertheir knowledge and their applied rules to other people [9]. So, if we focus on the transfer ofexperience we should concentrate on problems with less routine and more adaptive expertise.

3 Investigation

3.1 Research Methods

In a joint research project engineers and psychologists have investigated ten design processesin four companies by compiling detailed records of the design process as well as collectingdata on the individuals, the group and external conditions [10].

In a thorough analysis, the observed design process has being differentiated into routinesituations on the one hand and critical situations on the other in order to concentrate onsituations that have an important influence on the further direction of the design process andthe product. These 'critical' situations are then described by influencing factors and theirinterrelations [11]. Furthermore, the communication between members of the observed designteam 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 ofcollaboration 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 situationsand during the whole working time. Although in our investigations designers were workingindividually about 70% of the whole working time, communication between colleaguesoccurred in 90% of all critical situations. This result illustrates the importance of informationfor the exchange of decisive design information (cf. Figure 1).

In an additional study [12] interviews in 10 R&D departments of major German companiesthe importance of colleagues as the most frequently mentioned source of information transferin everyday design work were underlined: Verbal communication was described as the mostimportant 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 individualprerequisite during the handling of each critical situation. Experience was rated high, if theexperience of the designer with the specific problem area was longer than mostly five to sevenyears - in case that the observer couldn't decide about this fact the designer was asked abouthis experience in the particular field.

The data revealed that in 49% (n = 336) of all critical situations (n= 682) experience of thedesigner 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 self-assessment 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 transferredinto a successful result. Thus, the next step was to analyse how often high experience andinformation availability was combined with a successful result. The data illustrates thatwhenever an experienced designer was involved in the critical situation the transferredknowledge was mostly useful (cf. Figure 3): More than 80% (n= 219) of all critical situationswith 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 experienceddesigner was not able to turn the situation to a good account.

Nevertheless it is necessary to point out that experience was only one influencing factorcontributing to a network of interrelated factors from the field of the individual designer, thegroup, 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 dividedinto routine situations and so-called critical situations. Why? The analysis of design workreveals that not every moment is of the same importance for subsequent design activities andfor results obtained later. For example, at certain moments we may observe designers sittingat their CAD station adding holes and screws during the embodiment design phase of acomponent; 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 influencethe remaining design process in a positive or negative way. Derived from the steps of generalproblem solving, we can contrast different types of critical situations regarding their aim inthe 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 areimportant 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 combi-nation with skills in a specific work domain we would not expect that experience in the designcontext facilitates the management of critical social situations such as disturbances andconflicts. Thus, we analysed the impact of high experience in critical situations of the typegoal 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 tothe development of solutions. But experienced designers in our investigations had moreproblems transferring helpful information in situations of goal elaboration (cf. Figure 5). Thedata reveal that in 36% of all critical situations of the type goal elaboration the result of thesituation turned out as unsuccessful. In contrast, in more than 73% of solution search thesituations were crowned with success.

Searching for reasons we should ask what are the specific requirements of situations with goalelaboration in contrast to situations with solution search?

Table 1. Typical requirements in situations of goal elaboration in contrast to solution search.

Goal elaboration Solution searchTransfer of information is requested to fixed Amplifying and limiting the search area of

requirements ideas and solutionsPrecise knowledge about the factual Generation of ideas: intuitive, not necessarily

requirements systematic analysisRecognition of the context and relevance of There is no 'one and only' solution

the particular goal

As we point out in Table 1 the two types of situations are very different in regard to therequirements. In the context of goal elaboration the experienced designer is asked tocontribute precise information concerning existing requirements. However, the knowledge ofthe experienced designer is not necessarily concerned with the actual requirements; he oftentransfers 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 completenetwork 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 thegiven answer. If such information meets an inexperienced colleague the experienced designermay create severe problems in the future.

Whereas goal elaboration is very much restricted to the 'correct information', which is relatedto the prescribed requirements, the solution search is especially concerned with ideageneration and idea evaluation. In situations of solution search we observed many situationsof informal discussion, where the experienced designer was asked to generate an idea and todiscuss hindering or facilitating aspects of the developed solution. Thus, in this contextexperience is of high value because unclear ideas can be substantiated or brought into anotherview. The discussions move between limiting and amplifying the scope of the problem but theexperienced designer is not asked for the generation of the one right solution. In this contextexperience frequently initiates a thorough analysis and a deeper thinking, a process whichleads to successful solution search more often.

4 Conclusions

In the paper we pointed out that the transfer of experience does take place in the design officevery common and that the transfer of experience is of relatively great effectiveness in criticalsituations. 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 - inrelation to Hatano, G. & Inagaki [8] 'adaptive experience' - can be transmitted successfullyfor 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 informalinformation seeking is very recommendable in obtaining a good group climate and creativediscussions [12], it also enhances ad-hoc and non-reflected answers. Usually designers preferto search for information by asking their colleagues, because in doing so they receive a lot ofadditional information including a rough idea of the quality of their own idea, solution ordecision. According to the results of the study we would suggest to reinforce informal groupdiscussions in the context of solution search, but the process of information transfer duringsituations of goal elaboration should be supported by an information tool - not necessarilycomputer-based tools - which provide quick and current information about requirements.

References

[I] Cross, N. and Clayburn Cross, A., "Expert Designers", in E. Frankenberger, P. Badke-Schaub and H. Birkhofer (eds)., Designers. The Key to Successful Product Develop-ment, pp. 71-84, London, Springer, 1998.

[2] Hacker. W., "Expertenkonnen. Erkennen und vermitteln ". Gottingen, Hogrefe, 1992.

[3] Glaser, R., "On the nature of expertise", in F. Klix and H. Hagendorf (eds.), HumanMemory and Cognitive Capabilities. Amsterdam, Elsevier, 1986.

[4] Steinberg, R.J., "Expertise in complex problem solving: A comparison of alternativeconceptions", in P. Frensch and J. Funke (eds.), Complex problem solving: TheEuropean perspective. Hillsdale, LEA, pp.295-321, 1995.

[5] Gunther, J., "Individual influences on the design process - time-oriented vs. quality-oriented design", Proc. ICED '99. Munchen. Vol. 1, pp.201-204, 1999.

[6J Eckert, C., Stacey, M. and Wiley, J., "Expertise and designer burnout", Proc. ICED '99.Munchen. Vol. 1, pp. 195-200, 1999.

[7] Purcell, A.T. and Gero, J.S., "Design and other types of fixation", Design Studies, 17,1996,pp.363-383.

[8] Hatano, G. & Inagaki, K., "Two courses of expertise", in H. Stevenson, H. Azuma andK. Hakuta (eds.), Child development and education in Japan. San Francisco, Freeman,pp.262-272, 1986.

[9] Dreyfus, H.L. and Dreyfus, S.E., "Mind over Machine: The Power of Human Intuitionand Expertise in the Era of Computer", New York, Free Press, 1986.

[10] Wallmeier, S., Badke-Schaub, P. and Stempfle, J., "Empirical diagnoses and training indesign 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 CriticalSituations of Product Development". Proceedings of the 4th Design Thinking ResearchSymposium. 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.badke-schaub@ppp. uni-bamberg. de

© Petra Badke-Schaub 2001

258 ICED01-C586/531

Organization and Management ofDesign

Including sub-sections:

Project ManagementProduct Strategy and Management

Planning and Workflow ManagementConcurrent Engineering and Integrated Product Development

Distributed Design/Supply Chain IntegrationDesign Teams

Management of the Clarification PhasePerformance Evaluation

Risk and Uncertainty Management

This page intentionally left blank

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

PRODUCT DEVELOPMENT MODELS FOR SHORTER LEAD TIMES ANDMORE RATIONAL PROCESSES - ITS EFFECTS ON THE WORKSITUATION FOR PROJECT MANAGERS AND PROJECT GROUP

A Zika-Viktorsson and J Pilemalm

Keywords: Project management, project work, human resources.

1 Introduction

Time as a scarce resource

Time to market is since the past ten years a factor highly stressed in product developingcompanies. This factor is added to the requirements cost, performance and quality and hascaused rethinking and changes in companies and projects. The strive towards a faster productdevelopment can be considered a consequence of growing international competition, theaccelerating technical development, more products and shorter life cycles, and thediversification 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 broadconcept, encompassing a number of techniques as concurrent engineering, cross-functionalteams, and integrated rather than coordinated cooperation. One of these techniques isorganizing 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 beaccomplished. Project management literature describes projects as a rational method toorganise development work optimised to the objectives for time, function and costs. Projectsare seen as functional in order to handle undertakings of more unique nature withdevelopment as the central feature. In industrial product development the basic reason fororganizing work as projects is to implement a planning strategy.

One way of making the product development process more efficient in a company is toimplement structured models for standardising product development activities. In general, thereason for a company to implement such models is to obtain a more effective use of resourcesand time. Other reasons are to create consensus for the project process and the projectmanagement, 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 controlover projects from an internal as well as external point of view. A standard model for projectsmay 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 co-workers impact the ability to shorten lead times. Group effectiveness as performanceaddressed to the goals for the project is an essential factor. The project team must exertsufficient 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 bringadequate knowledge and skills. The members must be able to employ task performancestrategies that are appropriate to the work and coordinate their work at the same time asmotivation and commitment are created and maintained. Further, an effective team must havea potential to avoid inappropriate ideas and contributions as well as they must possesslearning and sharing skills. They need capabilities to avoid flawed implementation of plansand develop ways to proceed with the work [2]. Not only the capabilities of the available teamare crucial. Team effectiveness is interdependent with organisational context, boundariesbetween tasks and groups, and team development [3].

One disadvantage with working in time-focused projects can be a too heavy workload, whichcan give drawbacks on individuals as well as objectives for the project. Product developmentprojects high in complexity together with work in multi-functional teams and elevated timegoals can cause too much strain on the members in the projects. There is a risk that intensiveproject work brings a much too high work strain as a consequence of high demands oneffectiveness and efficiency together with parallel activities [4]. To tight time schedules giveless time for reflection and decision-making, which lower the quality of the product, and canbe 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 positiveand negative consequences for project managers and members in project teams highly focusedon the time objectives. The study looked at the work situation on the project level in twocompanies that implemented standard models for how to handle product development. Themodels were implemented as means to shorten the lead times for the projects.

2 Data and methodology

Data for the study was collected from 16 co-workers in product development projects (ofwhich 8 were project leaders), equally dispersed at two companies.

The two involved companies were Swedish manufacturing companies in the mechanicalindustry. The companies had implemented new models for the product development processwith the aim to run the projects faster and with better structure.

For both companies, the development of new products was important for the long-runsuccess. Further, the type of product development work in these companies wastechnologically sophisticated and the development undertakings included new products andvariants of existing products. The planned length of the various projects, the intervieweeswere working in, varied between two and seven years. The sizes of the core project teamsvaried between seven and 20 members.

262 ICED 01 -C5 86/461

The interviews involved questions addressing co-operation, co-ordination, workload, timepressure and decisions. The interviews were semi structured and with the length of one to oneand a half hour. The interviews were tape-recorded and analysed according to principles forgrounded theory [6].

The study had an explorative approach with qualitative methods. The qualitative approach isjustified by the complexity of the studied situation. To grasp both qualities in the models andexperiences of working with focus on shortening lead-times a qualitative approach wasneeded. An explorative approach was needed because of the lack of research concerning time-focused project work and psychosocial work-environment.

This paper shows results, which is a part of a more comprehensive study involving a broaderscope and a third company [7].

3 Findings

With an aim to make the product development projects faster the two companies hadintroduced 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 productdevelopment in general, as well as the separate projects. The new models were supposed to bea way to improve the quality in the work process by making the activities more concurrentand support the multi-functional co-operation, and at the same time make the projectsaccomplished on a short time.

The new models should support and prescribe the work by giving a holistic andcomprehensive view of the product development process. They should also introduce betterroutines and structures as well as elevate the time objectives. Former models imaged theproduct development process (and project process) as sequenced activities emphasizingconstruction, and functional goals. They mirrored work methods and strategies wherefunctional 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 goodsupport in the overall work with planning. The models and the routines had given the projectmanagers new tools for executing the projects. They were also functional as a commonplatform for all the projects within the companies. The models were considered ascontributions to better understanding of the product development process and the projectmanagement at all levels in the companies.

The models as a burden. Even if the new models were created with the aim to suit the specificbusiness in the particular company, shortcomings were reported. According to the interviewsthe models were fitting product development projects at a low level of complexity. Therebythe models couldn't be a functional support or guide for projects characterized by greatdynamics, parallel and concurrent activities, high complexity and high speed. The modelscouldn't support these kinds of projects well enough. The routines prescribed by the modelstended to become a burden for the project managers, making it difficult to accomplish theproject as effectively as they wished. According to the interviews the models were consideredas stiff and inflexible.

ICED 01 -C586/461 263

Needs for neglecting the model. Because of the elevated importance of time objectives it wassometimes a need to neglect the prescriptions connected with the model. In the interviews it isdescribed how the complex nature of the project together with the demands for speed madethe project manager searching for short cuts. Thereby there was a need to neglect some of theroutines. Because of the nature of the product development project, it wasn't possible to keepup 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 onworking with a sharp focus on time there were also some positive impact on individuals andteams. The work under high pressure was a challenge, which resulted in feelings of pridewhen the goals were reached. Another positive aspect was that a ground for high commitmentbetween team members was created.

More work with plans during accomplishing a project. Emphasis on reducing time gaveimplications for compressed time schedules for the operative work in the projects. However,the speed, dynamics and complexity put special demands on planning procedures andscheduling methods. The work with plans and with communicating them to team andstakeholders is always an important part of the work for a project manager. However, theelevated focus on time objectives resulted in more work with planning. The compressed timeschedule made the smallest deviation affect the plan. According to the interviewees this madeit 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 theperiods, during work hours, for thinking, reflecting and catching up fewer, or even non-existing for the project managers. Even though the daily work - off course - calls for a lot ofreflective 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 reflectabout the structure and the process from a distance, and thereby get possibilities to grasp thepicture of the whole situation. According to the interviews there was a need to reflect over theproject 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 intoaccount (in a satisfying extent) important aspects of a problem before a decision. The need forquick decisions created feelings as constantly coping with risks and, in turn demanded self-confidence and fearlessness together with carefulness and sound judgement. According to theinterviews the work with shortening lead times was sometimes synonymous with constantlyhandling hasty decisions and uncertainty.

Greater need for support. An assistant or a 'right-hand man' (or woman) can be of greatsupport for a project manager - especially in projects characterized by uncertainty and highspeed. 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 thatsupported the project manager in more strategic and sometimes controversial questions. In thehigh-speed project there was a constant need for quick and effective discussions about severalaspects of formal management as well as leadership. This partnership was facilitated by aconcordant view upon project management and compliance at the personal level.

Needs for empowerment in project teams. It is necessary for a project manager to delegatetasks 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 relateddetails. They had to trust the project members, their competence and ambitions. It was alsoconsidered important to encourage empowerment in the teams.

Needs for committed team placed together. A highly committed team was considered as theobvious ground for effective project work within narrow and rigid timeframes. According tosome interviewees organizing the project as a heavy weight team and not within a matrixstructure enhanced commitment. This made a good ground for commitment partly byavoiding conflicting supervision of more then one supervisor.

It was also of great importance to place of the team members together. This localization madeit possible to resolve problems in an effective manner where the team could use their capacityto continuously and thoroughly work out the problems coming up. The whole team couldwork integrated and discuss until all questions were went through. To place a team togethergives good opportunities for the members to thoroughly work with problems. Even if therewere limits they wasn't settled by a meeting agenda, formal communication channels ordistance.

Attention on signs for overwork. According to the interviews there was a need for the projectmanager in the high-speed project to be attentive to signs for team members not feeling wellunder the high pressure. Beside the demands for monitoring and controlling, to keep theproject 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 inthe interviews, projects with only male members tend to neglect these kinds of issues andfocus too much on practical and technical issues.

The risk for lowering the quality in technical solutions. According to the interviews there wasa worry among the product developers for a lowered product quality caused by the focus ontime objectives. In the interviews there was examples of dissatisfaction concernedjeopardizing the quality.

Another aspect on working with high time focus was the impact of the time pressure oncreativity and problem solving. According to the interviews there were situations when teammembers ran out of ideas because of the high pressure. But there were also examples onincreased creativity caused by the situation where the team, forced by the time pressure, hadto lift themselves up to higher levels to grasp the whole situation and then find out new waysto solve problems.

To work very intensive and focused had also created a lot of knowledge. The intensive worktogether in the team, with the common task, was a ground for high level of knowledge aboutevery aspect of the object for the project. This knowledge together with a rich flow of ideasand an open climate were considered as one of the basic factors for accomplishing a high-speed product development project.

Insufficient time for personal development and participating in company activities. In theinterviews 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 differentcompany events, which made the project rather isolated.

ICED 01 -C586/461 265

4 Discussion

The aim of the study was to investigate how standardised ways for managing projects togetherwith the claims for shorter time-to-market can affect the work situation on operative projectlevel.

The interviews give a broad picture of the experienced work situation in these projects withnew standards for routines and elevated time objectives. This picture includes both advantagesand 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 modelcreated to suite every project within a company can be difficult to apply. It can even beconsidered as an obstacle for effective accomplishment. Beside the direct implication of a stiffmodel 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 opposedto conform to an imposed standard. The standard way of managing a project has to bebalanced with possibilities for commitment, flexibility and control.

In what extent this is a general problem within companies, can be discussed. However, theuniqueness of a project form and standardization of the bureaucratic form can stand as eachother's empirical opposites as ways of organizing [1]. The project management literaturestates that projects should be handled on a situational basis. But also, the features of scientificmanagement can make a natural ground for primarily aim towards uniformity and standardswhen creating and implementing new work methods.

Second. Endeavours, at the project level, for speeding up the product development call forintensive teamwork. This kind of teamwork evolves naturally around the constantly arisingproblems. It involves effective communication; rich flow of ideas and possibilities to workthoroughly with arising issues. Provided by prerequisites for effective communication theintensive teamwork can give a genuine and comprehensive knowledge concerning the objectfor 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 highcommitment and pride. Factors as goals, empowerment, climate and human resources playsan important role in cross-functional work in product development. These factors are affectingeach other and set the stage for subsequent development [9].

Work group effectiveness can be defined in terms of both productivity and employeesatisfaction [10]. Another important factor is self-management, which is the group levelanalogy to autonomy at the individual job level. It is central to many definitions of effectivework groups [11] and part of most interventions. Related factors are participation and self-management that are presumed to enhance group effectiveness by increasing members' senseof responsibility and ownership of the work. Work group effectiveness also demands tasksignificance, 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 tostrain. Besides a more direct pressure from the explicit objectives, there is a pressure fromdecreased control and lack in overview if the project also is highly complex. The experienceof control is an important factor for reducing high negative stress levels [13]. Usually projectwork 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 andtime. But the tighter the scheduled time limits are, the shorter the time for reflecting andevaluating decisions and effects. There is less time for thinking and gaining control and thedifficulties 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. Atthe operative project level both team members and managers must be supported both sociallyand instrumentally. Besides the obvious advantages of instrumental support and relief, socialsupport has shown to be an important moderator on strain [13]. Among the need of otherimportant supporters the project manager can need a 'right-hand'. This partner can provideaid during the execution of the project, both in evaluations but also by generating ideasconcerning work methods. This partnership can reduce strain and improve the quality indecisions.

An increased risk for overstrain within a project can make obligations for the operativeproject manager to focus more on psychosocial issues such as workload. The pressure in ahigh-speed and complex project emanates directly from compressed time schedules, but alsoindirect by jeopardizing quality and hasty decisions. The primary part of leadership inoperative project management is goal-focused. Even if a project manager always, at somedegree, has to consider relational and psychosocial aspects, there can be more of a necessity tofocus on workload and well-being in high-speed projects.

The findings in the study indicate problems at the operative level connected with fasterprojects. Changes made to rationalise the product development and to shorten the project lifecycle put demands on the co-workers in the product development. Besides the advantagesconnected with economy and competitiveness there are also some risks with short lead-timesleading to time-pressure that is too heavy. Too high a speed in the processes are not only arisk for overstraining the personnel, it is also a risk for the creativity, the quality in thedecisions (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 satisfactionand thereby receiving a high personnel turnover.

The study gives implications for further investigations on how demands for shorter lead timeseffects humans, the outcome of the projects and the design of project standard models.Important question to be investigated concern the contradiction between the greaterimportance for controlling and planning in projects characterised by high-speed ancomplexity, and the deteriorated possibilities to actually do this in such projects. It would beappropriate to use a qualitative research approach to obtain detailed an in-depth understandingin these matters.

It is also of importance to investigate how single elements in a standard project model, as wellas more general functions for steering, management and execution, are related to each otherand to the work done by operative project manager and project team. Further, effects on theoutput of the project must be concerned. Not only outputs with obvious relation to the formalproject goal, but also in terms of development of teams and individuals, knowledge andcreativity. Off course, there is also a need for studies looking at workload (and moderatingfactors) generated within frames settled by objectives for time, resources and function.

ICED 01-C5 86/461 267

References

[I] Eskerod, P. and Ostergren, K., "Why Do Companies Standardize Project Work?",International Project Management Journal, 6, 2000, p34-39.

[2] Hackman, J.R., Groups that work (and those that don't), Jossey-Bass, San Fransisco,1990.

[3] Sundstrom, E., De Meuse, K. and Futrell, D., "Work Teams. Applications andEffectiveness", American Psychologist, 45, 2, 1990, p120-133.

[4] Hovmark, S. and Nordqvist, S., "Project organization: Change in the work atmospherefor engineers", International Journal of Industrial Ergonomics, 17, 1996, p389-398.

[5] 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.

[6] Glaser, E.G. and Strauss, A.L., The discovery of grounded theory: Strategies forqualitative research, deGruyter, New York, 1968.

[7] Zika-Viktorsson, A., Pilemalm, J. and Hjelm, J., New Way of Working in ProductDevelopment: Case Study in Three Manufacturing Companies (In Swedish), RoyalInstitute of Technology, Department of Machine Design, Stockholm, 2000.

[8] McDonough, E.F. and Barczak, G., "Speeding up new product development: Theeffects of leadership style and source of technology", Journal of Product InnovationManagement, 8, 1991, p203-211.

[9] McDonough, E.F., "Investigation of Factors Contributing to the Success of Cross-Functional Teams", Journal of Product Innovation Management, 17, 2000, p221-235.

[10] May, R.M. and Schworer, C.E., "Developing Effective Work Teams: Guidelines forFostering Work Team Efficacy", Organization Development Journal. 12, 3, 1994, p29-39.

[11] Pearce, J.A. and Ravlin, E.G., "The design and activation of self-regulating workgroups", Human Relations, 40, 1987, 751-782.

[12] Campion, M.A. and Higgs, A.C., "Relations between work group characteristics andeffectiveness: 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-ViktorssonIntegrated Product Development, Institution for Machine Design. Royal Institute ofTechnology, S-100 44 Stockholm, Sweden, Tel: + 46 8 790 63 03, Fax: +46 8 20 22 87, E-mail: annika@md.kth.se, www.md.kth.se

©IMechE2001

268 ICED 01-C5 86/461

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

A MULTI-PROJECT MANAGEMENT APPROACH FOR INCREASEDPLANNING PROCESS

F Marie and J-C Bocquet

Keywords: project management, multi-project, planning, decomposition, and assignment

1 Introduction

Scope of the research: After a short introduction about PMI® concepts for projectmanagement, we wil l focus on three major topics of the project planning process, which aredecomposition, assignment, and advancement state management. The scheme of the paper isin four steps: synthesis, problematic, proposals and impacts. The scope will widen in part 5with a research proposal about generalised multi-project management. The topics, which arein our research activities, but not developed in this paper, will be specified.

2 Formal project management by PMI®

The PMI Standards Committee has developed a document that describes the sum ofknowledge within project management: The Project Management Body of Knowledge(PMBOK©, [ 1 ]). It defines a project as a "temporary endeavour undertaken to create a uniqueproduct / service", and project management as "the application of knowledge, skills, tools andtechniques to project activities in order to meet stakeholder needs and expectation". ThePMBOK describes project management using three models:

• the project life-cycle: a project is subdivided into phases, organised by logical andchronological flow,

• the project processes: series of actions bringing about a result (they map knowledge intodeliverables). They are organised into process groups: initiating (recognising that a projector phase should begin and committing to do so), planning (devising and maintaining aworkable scheme), executing (co-ordinating resources to carry out the plan), controlling(ensuring that project objectives are met) and closing (formalising acceptance andbringing 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: projectintegration, 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 thetriangle scope / time / cost constraints. As specified in [2], planning and controlling processesare the major studied processes. We wil l focus on the planning process onto the next parts.

3 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 facilitatingprocesses. 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 consistentdocument. This process is facilitated by the Organisational Planning and the StaffAcquisition, which consist of identifying, documenting and assigning project roles,responsibilities and reporting relationships, and then getting the needed human resourcesassigned to and working on the project.

Synthesis: PMI describes a structured planning process, with identified steps. But manycompanies do not use such a structured process. For those companies, we propose somesimple methods to do the main actions of the planning process. For companies that use part orall of PMI's planning process, we propose some improvements or tools that are not specifiedin the PMBOK. So, there is a reason for everybody to use what follows, but let us see first theproblematic 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 besmall enough, so that it becomes possible to define and sequence the activities that willrealise it.

b- How to decompose low-level deliverables (or work packages, as called in the lowest levelof the WBS) into activities? Transcription of the WHAT into the HOW (how theobjectives and deliverables are achieved by carrying-out of activities).

270 ICED01-C586/563

c- How to decompose activities into smaller, more manageable activities? Decomposition ofthe HOW. The activity has to be small enough, so that there are resources, which wil l beable to carry it out.

d- How to assign people accountable for work packages, or bigger deliverables? Assignmentof a WHO to a WHAT. Finding the person or subcontractor with commitment, ownershipand responsibility for delivering the objective within time, scope and budget.

e- How to assign resources (people, machines, equipment) to carryout activities? Assignmentof some WHOs (who can be material stuff) to a HOW. Finding the persons, machines,equipment or combinations (like partners, subcontractors, internal services) with theskills, 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 worthyto 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 MUCHparameters (for time and cost).

Part 4.1 (Decomposition) brings l ight ing to problematic a-, b- and c-. Part 4.2 (Assignment)brings l ighting to d- and e-. Part 4.3 (Independent sub-projects planning) brings some lightingto problematic e-. Part 5 widens to generalised multi-project management. In summary:

Decomposition is a cognitive problem solving process, which depends on manyuncontrolled factors, as experience, available information, teamwork and teamperformance, team members' personalities and intelligence, and complexity managementski l ls .

Assignment is a multi-criteria choice process, which depends on human factors, ashistorical experience and relationships between people, powers and politics, complexity ofmultiple criteria, information about skills and interests, personal and even private data.

Independent planning is a risk management process, which depends on personality ofpeople, experience and historical information about similar situations / teams, andreporting accuracy needed by management.

4 Proposals and impacts

Figure 2 defines our research topic: from a situation analysis, each project manager at eachlevel of the project, is able to generate the process that will satisfy the stakeholders, and theorganisation that w i l l carryout the process.

We identify three kinds of risks:

Functional risk: linked with the project objectives. The more ambitious, complex andresource-limited it is, the higher is this risk. Unrealistic expectations represent 9% offailure in IT projects.

Uncertainty and waiting risk: as we do not s t i l l have any idea of the solution, there is arisk that this solution does not exist, or that we will find it too late. It is the balancebetween 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: l inked with the solution decided to realise the need. The more the solution istested, validated by experience and robust, the smaller the organic risk is. Maybe we couldask 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 (wait ing risk).

Figure 2: basic scheme for project manager's actions and decisions

4.1 Decomposition

Decomposition is a cognit ive process. A non-human tool is not able to decompose workpackage or act ivi ty . Decomposition builds the project process (figure 2).

Proposal 1: As the three problematic talk about different natures of inputs and outputs, thereare three different methods for decomposition. Research outputs: standard procedure for eachdecomposition process: the DDD (Decomposition of project Deliverables into smallerDeliverable*) method, the DDA (Decomposition of project Deliverable into Activities)method and the DAA (Decomposition of Activity into smaller Activities) method. Link withPMBOK: DDD is in Scope Definition, DDA and DAA arc in Activity Defini t ion. The threemethods and their differences and similarities wi l l be developed in oral presentation.

Proposal 2: Historical information and standard documents and templates are needed to helpthis human cognitive process. Best arc computer-based templates and historic. Researchoutputs: 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 threedecomposition 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 managerof a smaller project. A recommendation is to decompose one level at the time. Each sub-element (deliverable or ac t iv i ty) is assigned, and the person responsible for the sub-elementwi l l execute the same decomposition process, with one of the same three decompositionfunctions. Research outputs: a WBS that is bui l t progressively, and not in a one shot process.Act iv i ty lists are progressively bui l t , 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 w i l l increaserel iabi l i ty of decomposition results. The decomposition w i l l be complete, the alternatives wi l l

272 ICED01-C586/563

have been specified, sorted and maybe eliminated (or may s t i l l serve as "B plans"). The sub-elements wi l l be coherent and consistent, and the interface problem will have been studied (itis a very tough problem to manage interface between deliverables, or between teams). Theorganic risk and waiting risk (see beginning of part 4.) will be reduced. As we know that theamount at stake growths through the phases, the organic risk reduction is a major gain in theplanning 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 father-element, some brothers, and some sons. This reduced vision allows a more accuratemanagement, because of the reduction of complexity of environment. Each manager can forexample make a stakeholder analysis (as father manager becomes the customer, and as son-managers 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 orsomething. Assignment builds the project organisation (figure 2).

Proposal 1: There are only two kinds of assignment: people responsible (accountable) for adeliverable (output of the Initiation process, seeing deliverable as project), and resources(people, machines, equipment) carrying out an activity (output of the Resource planningprocess). 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 toimplement such a database in companies when it evaluates what can do the person, and notthe level of competence she has in different skills. It reduces many problems of rewards,database maintenance and evaluation system. Research output: a data structure forcompetence database. It includes level 1 to 4 evaluation of skill and levels 1 to 4 evaluation ofinterest about working in this ski l l (developed in oral presentation).

Proposal 4: the project manager may be guided with a standard assignment procedure, just asfor 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 ski l ls : For a deliverable, manager looks for an accountable,responsible person, so a person having management sk i l l s (level 4, proposal 3), andhaving 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 skil ls(level 4) to be able to carryout the activity (actions or tasks).

2. Select and sort the corresponding persons, with knowledge about their sk i l l levels andinterests, [f there is no result, manager knows the person wil l 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 answerabout 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 keepshuman. The step 7 can not be computerised. Research output: a multi-criteria selection andsorting 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 theorganic risk. A process supported by a standard method and a computer-based tool that isl inked with a competence database reduces this risk of error. As the choice of the members ofthe team may dramatically influence the project results, this is a major gain in the planningprocess.

Impact 2: as the process is standard and the search is automatic, the time wil l 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 andshared, especially if the decomposition has well managed the interface problem.

Impact 5: It is possible to include training plan in the assignment process: people notcompetent (level 1 or 2 for skill level) but very interested (level 4 for skill interest) can beused after a training period.

Impact 6: the process can be used for e-assignment, in the case of distributed, or networked orextended 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 mayalready be under development (with actual costs), while another one is just planned (withbudgeted costs), another one is just estimated (with estimated costs) or even not (with noidea). Their advancement state can be independently managed.

Independent sub-projects advancement state management is part a cognitive process, part afeeling process and part a reporting process. Advancement state management givesstakeholders satisfaction (figure 2).

Proposal 1: the management of sub-projects of a project, the management of projects of aprogramme [3] or portfolio, the management of sub-phases of a phase, and the managementof sub-deliverables of a deliverable are similar. Research output: everybody in a project isproject manager of something (of the entire project, of a part of the project, of a phase of theproject, 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) shouldhave 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) shoulduse the same decomposition and assignment processes.

Proposal 4: as every project actor is a project manager, he (she) manages its advancementstate as an independent parameter. It means that he (she) has an objective, a deliverable, abudget, a deadline, a team, and that the advancement state (estimated, planned, underdevelopment, 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 toundertake. The consequence wil l be more efficient relationships, because of knowledge aboutthe terms, the language, and the basic and common principles or tools. It wil l be easier tounderstand each other and to work together effectively.

Impact 3: the waiting risk is increased by the choice work / plan / wait for parallel sub-elements. Indeed, we may wait too much, and be late, or overrun costs by crashing (addingmore resources to respect deadlines). In the other side, we may decide too quickly, and bewrong, 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 advancementstate management may procure some benefits in terms of time, cost (especially cost ofquality) and number of overall changes [6]. As we know that the quality cost may represent12 to 20% of the total project cost, and that rework and errors due to bad requirements arestrong 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 animportant place for trust between actors, or between actor and contractors [7].

5 Generalised multi-project management

The project managers, or sub-project managers, decompose their stuff into smaller and moremanageable 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 stillbe at a low decomposition level. We may have unbalanced WBS, or plans with some emptyparts [8]. At the same time, we may have some sub-projects planned, other ones underdevelopment, and other ones validated. The planning is managed with only three functions.

6 Applications & perspectives

A perspective is the development by student projects of a shareware of some functionali tylisted above (the proposals' research output deliverables), like decomposition processassistant, assignment process assistant, historical information storage & search, graphicalinnovations 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 completesoftware, or of a module for existing software.

7 Key conclusions

We have introduced some improvements in project planning. They are based on PMI'sstandards, but many companies, which do not use such standards and so structured processes,may stil l use our proposals without the PMI's basis. They are independent (even some arelinked) 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 oractivities),

• assign accountable person to these smaller parts (if it is deliverable), or carrying-outresources (if it is an activity),

• manage and report the advancement state of the part he (she) is responsible of, and the riskthat is linked with this state.

References

[ 1 ] PMI Standards Comittee— "A Project Management Body Of Knowledge (PMBOK)" -2000 ed., fSBN: 1-880410-23-0, Project Management Institute (2000).

[2] Kloppenborg T. & Opfer W. — "40 years of PM research: trends, interpretations andpredictions". Proceedings of PMI Research Conference 2000: PM Research at the turnof the mi l l enn ium, 41-60, Paris, France, June 2000.

[3] Eidsmoe— "The strategic program management office". Project Management Network,Vol. 14, number 12, 39-45, December 2000.

[4] Crawford L.— "Profiling the competent project manager". Proceedings of PMfResearch Conference 2000: PM Research at the turn of the millennium. 3-16, Paris,France, June 2000.

[5] Burnette D. — "The new face of the project team member". Project ManagementNetwork. Vol. 14, number 11, 61-63, November 2000.

[6] Chapman— "Project risk management: the required transformations to become projectuncertainty management". Proceedings of PMI Research Conference 2000: PMResearch at the turn of the millennium. 241-246, Paris, France, June 2000

[7] Hartman F. — "The role of TRUST in project management". Proceedings of PMIResearch Conference 2000: PM Research at the turn of the millennium. 23-28. Paris,France, June 2000.

[8] Abramovici — "Long duration projects: the fixed rolling schedule". ProjectManagement Network, Vol. 14, number 12, 47-48, December 2000.

Franck Marie

Ecole Centrale Paris, Laboraloire Productique - Logistique, Grande Voie des Vignes, 92295Chatenay-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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

APPLYING CONCEPTUAL DESIGN METHODS TO ENGINEERINGMANAGEMENT

P Hughes, C Burvill, and R Hughes

Keywords: mechanical product design, business process re-engineering, competitiveness,design for manufacture.

1 Background

A review of the available literature discussing the management of product based innovation ledto the identification of the following major objectives, meet market demands; compatibility ofproposals 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 thespecial needs associated with the management of innovation [3,7,13],

The use of systematic design methods that provide a formal structure for the definition ofproblems and evaluation of design concepts [6,10,11] was considered a suitable basis for thedevelopment of management tools by a small Melbourne based engineering firm that specialisesin mechanical product design (Integra Systems Pty Ltd). Design methods were successfullyused to assist the firm in corporate decision making and the logical storage and analysis ofinformation. Further, the tools created within the firm allowed the inclusion of new informationover 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 themanagement techniques described will be applicable to other firms developing innovativeproducts and services.

2 Introduction

A case study is presented that demonstrates the benefits available from the use of conceptualdesign methods in strategic decision making, in particular, those associated with evaluation ofcorporate 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 designmethods for product and process development within the firm facilitated their use in thedecision making process.

This approach has assisted the following decision making processes: select the industry sectoror sectors best suited to the firm's overall capabilities (table 1); identify opportunities foractivities within the chosen industry sector (table 2); and, derive and continuously refine itscompany strategies to best exploit the opportunities within the chosen sector (table 4). Thecase 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 thepreferred approach within the industry sector, or through the choice of sector.

3 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 tointroduce innovation to a manufacturing sector, the uncertainties associated with comparingavailable markets and the attributes of the organisation can be alleviated with an evaluationmatrix [11].

Table 1 shows the evaluation matrix used to select the most appropriate industry sector for thefirm under review - substituting industry sectors for design concepts, and necessary corporateattributes for design criteria. The overall expertise of the firm dictated that selection would fallwithin the manufacturing sector. The selection criteria chosen is broadly applicable althoughthe concept ratings are specific to the firm under review.

As there is typically no median or datum for comparison when attempting to enter an industryas 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 opportunityand '5' indicates high certainty or good opportunity.

Within the case study, table 1 demonstrated that the firm's mechanical design expertise is highin 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 1also showed that punching and forming from sheet metal coil provided developmentopportunities.

4 The design of a business strategy

Morphology is a common tool for the development of alternative design variants [2,10], wherea morphological chart will typically consist of rows divided according to the concepts(functions and sub-functions) of a design proposal, with columns identifying alternativesolutions for each concept (variable). This approach has been applied to the identification ofalternative approaches to business operation (table 2), where rows are divided according tobusiness functions and columns identify attributes associated with the business functions. Forthe firm under review, this allowed a range of business operation variants to be defined withreference to the necessary concepts required for the business variant to be considered forimplementation. The creation of the concepts and solution variables in figure 2 is an ongoingprocess that effects the attractiveness of alternative business variants. The creation of thebusiness operation morphological chart in table 2 involved an extensive review of the chosenindustry sector.

Potential Failure Modes and Effects Analysis (FMEA) assists the engineering designer inexploring, to the extent possible, potential failure modes and allowing their associatedcauses/mechanisms to be addressed and evaluated [13]. This design tool has been applied tothe assessment of business operation proposals (table 4) to assess issues associated withpossible failure of a proposal, and facilitate quantification of the risks associated with the modeof 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 areoffered that may be able to correct the cause of the limitation. As for the business operationmorphology approach, the use of FMEA to review corporate decision making accommodatesongoing changes to the business organisation and to the available market.

5 Application to an engineering firm - a case study

The firm under review used the tools described in section 4 to continually adjust its overallbusiness strategy. The firm has attempted the following operational strategies and has beenable to identify the strengths and weaknesses of each strategy: a combination of consultancyservices and a range of relatively low cost, medium volume products; downgrade consultancyservices and introduce a distribution service of internationally sourced high technologycomponents; design and manufacture low to medium volume machines as products for salethat incorporate the sourced high technology components (providing a means by whichtechnologies could be introduced to the chosen market); and, withdraw machines as saleableitems and use them within a customised production cell where the technology advantage can beexploited when competing for manufacturing services (allows testing and refinement of thetechnologies in-house). These operational strategies evolved within the firm and as newproposals were defined, they were introduced to the review process and analysed against theexisting strategies. The firm does not align itself to any one strategy to the exclusion of theothers but applies the most appropriate strategy to each situation.

Table 3 highlights the attributes associated with the product based approach (variant) tobusiness operation identified by the firm from the overall chart (table 2). Opportunities that areoutside the scope of the firm are quickly identified using this approach. Uncertain or criticalvariables are highlighted to assist the decision making process as these are associated withissues most relevant to the business strategy FMEA (table 4). Issues associated with theexisting and proposed correctional measures were quantified using risk numbers.

Benefits resulting from the introduction of the FMEA approach include: rapid identification oflikely critical failure modes and the prediction of associated consequences; quantifying of theimpact of the identified modes of failure relative to other modes of failure and to the associatedmode following correctional action; and, provide a measure with which to assess proposals foroperational changes within the firm.

6 Conclusions

Formal design methods have been successfully applied to the management processes of a smallfirm whose principal focus is product and process innovation for the manufacturing sector.Opportunities associated with this approach include: define the strengths and weaknesses of anorganisation; formal selection of industry sectors that reflect internal organisational strengths;assess whether a proposed approach to business operation can be accommodated by theavailable 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. Applyingformal design methods to management processes provided a framework for managing the firmin a creative manner, encouraging human decision making attributes such as intuition andexperience. 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 ofattributes from the alternative approaches to business operation led to the design andmanufacture of a sheet metal punching manufacturing cell (figure 1), combining coil basedsheet metal expertise, advanced metal punching systems developments, and a well understoodand documented overview of the sheetmetal punching industry sector.

Using this approach, the company has been able to double its product based turnover each yearover the last four years whilst rationalising resource levels through automation and reducingmanufacturing costs.

References

fl] Boag, D.A. and Rinholm, B.L., "New Product Management Practices of Small HighTechnology Firms", Journal of Product Innovation Management. V6, pp. 109-122, 1989

[2] Blake, R. R. and Mouton, J. S., The Versatile Manager. Scientific Methods, Texas, 1986

[3] Collins, J.C. and Porras, J.I., "Built to last, successful habits of visionary companies".3rd Edition, Random House, London, 2000

[4] Cooper, R.G. and Kleinschmidt, E.J., "Benchmarking the Firm's Critical Success Factorsin New Product Development", Journal of Product Innovation Management. V12, pp.374-391, 1995

[5] Dieter, G.E, Engineering Design. 3rd edition, McGraw-Hill, Singapore, 2000

[6] French, M.J., Conceptual Design for Engineers. Springer-Verlag, New York, 1985

[7] Hershock, R.J., Cowman, C.D. and Peters, D., "From experience: action teams thatwork", Journal of Product Innovation and Management. Vol. 11, pp. 95-104, 1995

[8] Lewis, W.P. and Wu, H., "Factors affecting the successful development of newproducts", Engineering Design Conference. London, 1998

[9] Muncaster, J.W., "Picking new product opportunities", Research Management. Vol. 24,pp. 26-29, July, 1981

[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 andinnovation tti '99. Melbourne, Sep. 1999

[13] Samuel, A.E. and Weir, J.G., Introduction to engineering design. Butterworth-Heinemann, Oxford, 1999

[14] Scherer, A. and McDonald, D.W., "A Model for the Development of Small High-Technology Businesses Based on Case Studies from an Incubator", Journal of ProductInnovation Management. V 5, pp. 282-295, 1998

Corresponding author

Dr Colin R. BurvillLecturer, Department of mechanical and Manufacturing Engineering, The University ofMelbourne, 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

IndustrySector

Table 1. Industry sector selection (evaluation matrix) [8]

MANUFACTURING ENGINEERING

Sheetmetal Working Toolmaking General Engineering StructuralEng.Punch Profile Form Mill Turn EDM CNC Profile

IndustryExperienceEducationalBackgroundColleagues in

industryComputer

ToolsPlant &

EquipmentUnexploited

MarketLow Tech.

SectorHigh Labour

ContentBreadth of

opportunitiesNo technologyadvancements

Totals

5

4

4

2

1

3

2

3

3

5

32

5

4

4

A

0

5

4

2

5

5

:;3:8;

3

1

4

4

0

2

2

1

1

5

23

1

1

1

1

0

5

4

2

5

5

25

4

3

4

4

1

1

2

5

1

3

28

4

3

1

2

0

5

5

2

5

5

32

4

2

4

5

5

4

5

5

4

5

43

5

2

2

0

0

1

4

4

1

5

24

3

4

4

2

0

1

1

2

3

2

21

5

2

2

0

0

1

4

4

1

5

24

3

4

4

2

0

2

1

2

3

2

22

4

1

5

5

0

4

4

1

1

4

29

2

1

2

0

0

2

2

1

1

4

15

2

4

2

0

4

1

4

4

4

4

29

4

2

5

5

5

3

2

4

4

4

38

3

2

3

1

0

1

3

2

1

4

20

3

2

3

1

0

1

3

2

1

4

20

3

1

1

4

0

1

3

2

3

2

20

3

1

1

4

0

3

3

2

4

2

23

2

3

1

0

4

1

3

4

1

4

23

4

2

3

3

5

1

4

4

3

3

32

2

2

2

0

2

1

3

4

3

3

22

2

2

2

0

4

1

3

5

3

3

25

4

2

1

3

5

1

4

3

3

3

29 2523253J

Table 2. Business operation morphological chart [7]

Concepts

1

2

3

4

5

6

7

8

9

Industry SectorOpportunities

Company Focus

ProductionFunctions

Products andServices

BusinessDevelopment

Funding

Avenue forMarket

Penetration

Barriers /Constraints

Personnel andResources

Evaluative Meas-ures / ProcessRefinement

a

Identify unexploitedmarkets

Locally producedinnovative products

Materials Handling

I x)w cost - Mediumvolume products

Self funding throughproduct sales

Market directly

h

Low technologycompared to related

sectors

Import replacement

Decoiling andStraightening

High cost - Lowvolume products

Self funding throughconsulting services

Market throughdistributors

Meet industry sector Market need foror market demands product / service

Low technology withhigh lahor

Profitability

High technology withlow labor

Market acceptance

f

High Process LaborContent

Value-adding imports

Material Feeding

A combination of 4aand4b

Collaborations withother high technology

organizations

Product andtechnology licensing

Levels of in-houseexperience

Multi-skilled team

d

No recent majoradvancements in

technology

Synthesis oftechnologies

Plate Punching

High TechnologyProducts

Collaborations withR&D institutions

An upgrade pathapproach to product

introduction

Available budget andcash flow

Use personnel fromother companies and

researchorganizations

_ . ! In-house efficiency -Serviceability | _

Cost vs. return

!Low synthesis of 1

technologies ,

|Offer High i

technology Design .and analysis services [

to industry 'I

Plate Forming ,

Value added imported!product '

Joint ventures with (

other companies !

Create products from !synthesis of in-house '

technology •

Delays in market ,acceptance |

Industry based 1research ,

|

Selling horizon (I>ong!vs. short selling cycle)'

Solution Variables

Choice ofundeveloped

production techniques

Stacking andCollating

Low volumemachines

External fundinginvestors and

financial institutions

Manufacturability

Use of contractors

Reputation forproduct and service

quality

Downsizing ofManufacturing Sector

Set-up andChangeover Systems

Technology cells andworkcenters

Technology grantsand Government

assistance

Available companyresources

Access to requiredtools

Repeat orders /ongoing business

Evidence ofcompanies wanting to

specialize

Manufacturing cells

Virtual 3D Design

Available technology

Colleagues andassociated companies

with shared values

Customer referrals

Industry trendstowards outsourcing

Computer BasedFailure Analysis

Clients downsizing in-house production

facilities

Customer willing tofollow upgrade path

Market subject touncertainty

Predictive machinefunction simulations

Customers' perceivedvalue of product /

service

Delay in bringingproduct to market

Industry sectorinability to embrace

change

Offline CNCprogramming

Time for market toaccept product

282 ICED01-C586/594

Table 3. Business concepts and solution variables - strategy overlay for "product based" approach. Criticalopportunities: low technology market (Ib) with high process labour content (Ic), no recent major advancementsin technology (Id) and low synthesis of technology (le). Critical barriers: meeting industry sector or marketdemands (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).

123456789

a b c d e f g h i

•1

j k

Figure 1. Sheet metal punching system - applying the accumulated knowledge of the firm under review withinits 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 significanceof 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 AnalysisExistingSituation

Suggested correctionalmeasures

ImprovedSituation

LimitationLimited market need forproductProduct innovation radicaland advanced

Product range not broadenough to satisfy market

High technology productsexpensive in low technologymarket

Product delivery delays

High cost of product R&D

Product incompatible withexisting plant

Consequence

Slow market penetration

Limited market acceptanceof productInability to introduceproducts withoutcomprehensive range

Unable to sell product withadequate profitability

Reduced customersatisfaction

Delays bringing product tomarket

Limited market acceptanceof product

CauseDownsizing of manuf-acturing industry sectorConservative market buyingpatternsRange too complex or largeto manage with existingcorporate structure

Manufacturing costs toohigh

Development times exceedmarket expectations

Insufficient funds andresources

Incompatibility withexisting infrastructure

O

7

8

8

8

9

9

8

S

7

7

7

9

6

8

9

D

9

9

9

7

8

9

9

RN

441

504

504

504

432

648

648

Prototyping and conductsmall scale market research3D virtual prototyping andcomputer based sellingLiaise with other companieswith complimentaryproducts

Modify products to reducelabor or material expense

Communicate realistic timeframe for product deliveryat the outsetCollaboration with researchinstitutions to broadenavailable resourcesCreate in-house solutions tocompete with users ofexisting plant

O

3

2

3

5

2

5

5

S

3

2

3

6

2

6

7

D

3

4

6

8

2

7

7

RN

27

16

54

240

8

210

245

O = Occurrence

Probability of occurrence

Very lowMedium lowMediumMedium highHigh

12-34-67-89-10

S = Significance

Effect on Business Development

Barely noticableNot detrimental to businessReasonably seriousDetrimental effect on business developmentHigh negative effects on business development

I2-34-67-S

9-10

0 = DetectionLikelyhood of detection before business is

adversely effectedHighMedium highMediumMedium lowLow

12-56-8

910

Risk Number

HighMediumLow risk

1000

1251

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

FINDING AND IMPLEMENTING BEST PRACTICES FOR DESIGNRESEARCH ACTIVITIES

M Gardoni and C Frank

Keywords: best practice, Knowledge Management, lessons learned systems, informationanalysis, classification and retrieval, design reuse

1 Introduction

The fast changing competitive environment in which most companies operate are forcingthem to change their strategies in order to remain competitive. It is within the design activitiesthat 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 andtechnologies in order to prepare industrial design units to realise innovations in designmethods and technologies. Some main design research activities are : strategic and technologysurveillance, to analyse industrial design requirements, to put into context new designconcepts, and to transfer new knowledge and technical solutions into industrial design units.

Design research activities nowadays are confronted with a rapidly technology and industrialrequirement change and therefore might need a support that helps to ensure the performanceand capacity for research activities. Indeed, researchers have to spend time to organise andoptimise their research processes in order to generate good results with the availableresources. 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 thesepractices 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 researchactivities by finding and implementing Best Practices. We will describe where and how itcould be possible to introduce Best Practices and illustrate our method. Furthermore we willdiscuss the probably existing relationship between Best Practices and knowledge managementsystems. We will illustrate that our method could lead to the introduction of a Best PracticesDatabase which could be related with knowledge management activities. Finally, cultural,organisational and technical problems and constraints which are related with the introductionof Best Practices will be discussed.

2 Definition of Best Practices

Among various available definitions of Best Practices, we retain two of them [3]:

• According to Carla O'Dell and C. Jackson Grayson JR. "Those practices that haveproduced outstanding results in another situation and that could be adapted four oursituation."

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 mayhave applicability to other organisations." Moreover, they distinguish different levels ofBest 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 canhardly be the best for all criteria: quality, cost, delay, etc.. Moreover a practice can fulfil theneeds within a context but not within another one. We prefer then to deal with "OperationalAdvices". However, we will retain the term "Best Practices" because it is widely used. Toharness Best Practices, we try to characterise their context and criteria in order to take intoaccount most of their influential parameters [4]. To this aim, a special interest is given to usethe Pattern approach. The purpose of this approach is to constitute a "Know-how base to solvea problem frequently occurring in a particular field" [5], Moreover, enterprise modellingmethods such as CIMOSA [6], with the concept of modelling views and the generationprinciple, describe the behaviour and the functionality of a system from various modellingviewpoints [7]. These modelling views can be represented by a meta-model. The objective ofthis meta-model is to be at the same time generic, exhaustive and representative in a certaincontext. All these views can be related to the description of a design "context". Within thisframework, various views of the characteristic elements of this context can be extracted fromthe meta-models. Moreover, we intend to use a skills model [8] to be able to compare theskills required to use the Best Practice and the skills owned by the users. The difficulty is toestimate the distance between these two instances of the skills model.

Figure 1. An example of skills model

3 Best Practices Management

Identifying and classifying fields for Best Practices applications for research activities isdifficult. Voss et al. [9] argued through their research for the Made in Britain and Made inEurope studies, that companies which have achieved world class status have adopted BestPractices and achieved high performance in operational areas. Therefore, there is an argumentto suggest that, by implementing Best Practices at the operational level, operationalperformance can be improved, and consequently the performance of the overall organizationcan be improved. Nevertheless, there seems tendency to use this expression for staticprocesses rather than for dynamic ones which both could be placed in the operational level ofan 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 beoptimised by a mechanism of comparison. So best solutions for common processes andproblems can be generated.

Design research activities are more or less structured in research processes and oriented byindustrial requirements. Several activities in these research processes could be structured andoptimised by Best Practices in order to make design research activities more efficient. Wepropose a formalisation of a method based on knowledge capitalisation cycle [10] to findimprovements.

3.1 The knowledge capitalisation cycle

The knowledge capitalisation cycle is characterised by four main steps in order to support thedevelopment and reuse of knowledge: locate, memorize, re-use and up-date. These steps canbe 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 knowledgecapitalization cycle describes the activities how to capture and distribute knowledge. Weconsider Best Practices as being knowledge elements. This means, every Best Practice can beconsidered as a knowledge unit or as a defined set of knowledge units what could justify ourapproach 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 abetter support for repeated tasks and implement Best Practices. Indeed, there is a need todefine the relationship between Best Practices and performance in order to understand whichpractices should be implemented to improve particular aspects of performance. Performanceindicators can and should be used as criteria in order to choose Best Practices and supportprocesses.

Our proposition (see also figure 3) begins with the identification and formulation of the needand the objective to improve the operational performance of a process or parts of a process. Aspecification 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 performancewhich reflects the area to be improved, and helps monitor change and to identify a new Best

287ICED01-C586/488

Practice. This phase and the identification of measurers might be difficult because of the lackmotivations of the involved person. A common definition, with the help of meetings andinterviews, might be helpful in order to identify the measurers. Before one can transfer BestPractices, it is necessary to define and find them: a phase of searching and evaluating ofpossible solutions. This research can be made inside and outside an organization. Approachesfor identifying Best Practices could be: benchmarking teams, best practices teams, knowledgenetworks, and internal audits [3]. The framework of defined measures of performancespecifies then a potential list of Best Practices influencing each measure. This list of BestPractices needs then to be evaluated and prioritised in terms of the strongest positiverelationship 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 andadaptation: Transferring means to choose the Best Practices from the list of Best Practiceswhich might be the best solution to improve the process. If necessary, this Best Practice has tobe adapted to the new process and its environment. These phases of transferring andadaptation are related to the steps "memorize" and "re-use" of the knowledge capitalizationcycle.

The transfer and especially the adaptation of new Best Practices are probably the mostdifficult activities hi order to improve the operational performance. A new practice has to beadapted and accepted by an already existing system, environment, and by people. This systemor environment is characterized by its organisation form and habits, by its using technologiesand by the people managing this organisation, technology and process. Not only the BestPractice needs to be adapted to the new environment but also the system and the people needto be adapted to the new Best Practice. Therefore this adaptation process needs thecompetence of the people involved in this process. Methods for identifying the necessarycompetence [8] have to be applied before and during the adaptation process in order to ensurethe necessary competence and resources which help and to transfer and adapt the new BestPractice. The skills model (figure 1) could assist to identify the existing and necessarycompetence in order to overcome people's problems related to the change of their module ofthinking and working. With the help of learning and assisting processes required skills to usethe Best Practice should be transformed into owned skills. In order to avoid problems withtransfer and acceptance caused by people, the future users of the new Best Practice should beinvolved 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. Whileusing the Best Practice it is necessary to measure and evaluate the improvements with thedefined criteria and measures described in the phase where the Best Practice was identified. Ifthe expected results are not yet achieved, a re-adaptation of the Best Practice might benecessary.

After evaluation of the results and after the complete adaptation of the Best Practice and thesystem or environment where the Best Practice is implemented, the Best Practice could beadded to a "Best Practice Database" in order to make it accessible for other users and for otherproblems 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 ourapproach which is related with the knowledge management cycle.

4 Best Practices and knowledge management activities

The formulation and storage of Best Practices allows other actors to have access to differentBest 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 storageof the Best Practice might be useless if actors do not know the environment and especially thecontext in which the Best Practice is used. Therefore we propose to formulate and store BestPractices always with their context in which they are used. This helps other actors to identifythe useful Best Practices for their problem by comparing the context of the Best Practice withthe context and environment of their problem.

Knowledge Management activities and methods could help, with appropriate technologies, togive 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 orderto harness non-formal information and to capitalise relevant information exchanges.Moreover, with other methods and technologies like forums, email, intranet, documentmanagement, 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 forthe identification and reuse of Best Practices.

Knowledge management methods and technologies could allow to show and to formulate theconnection between different use cases of the same Best Practice. One Best Practice might beused for different environments and for different problems and it might be interesting to trackand to show the history of development of a Best Practice.

The result of the interaction between knowledge management activities and Best Practisestransfer and adaptation could be a map which shows the different Best Practices in theirdifferent 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 severalrepetitive processes or sub-processes. These processes could be supported be implementingBest Practices: Best Practices could help to improve knowledge management activities. Thereexists differences between knowledge management systems and the method of implementingand transferring Best Practices: A knowledge management system tends to be more complexsince it manages evolving knowledge whereas Best Practices only focus on static knowledge.A knowledge management system tries to support dynamic and static processes whereas BestPractices support morels static processes.

5 Best practices supporting design research activities

Best Practices could help to organise, to improve, and manage design research activitiesImplementing Best Practices could probably optimise processes and sub-processes used fordaily research activities. An example could be the constitution of a research report with BestPractices including propositions like how to structure, format, distribute, etc. a report.Moreover, we think that TRIZ methodology [14] could be useful to standardize designresearch activities. TRIZ methodology could be described through four main steps:

1. Once you have detected a real existing research problem you try to reformulate thisproblem 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 yourabstract problem.

4. You try to transform your abstract problem and the abstract solutions in your real problemwith a real solution.

This methodology shows, by formulating a method how to solve specific problems, that it ispossible to introduce Best Practices for research activities and to help to find an efficient wayof problem solving. Considering the TRIZ methodology a Best Practice a knowledgemanagement method and technology might help to show, how, why and for which problemsTRIZ 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 relevantcontext, which can help to optimise the use of the TRIZ methodology for different but similarresearch cases.

Another example of a method which could be defined as a Best Practice for design researchactivities is the functional analyse method. Once industrial requirements for design researchactivities are defined, it is very often difficult to identify the way of solving the problems andhow new concepts and technologies could look like. We propose the functional analyse as aBest Practice in order to find efficiently new solutions, concepts and technologies for givendesign research problems. The functional analyse could be described through the followingmain steps: specification of the industrial needs and requirements; description of the contextof the following research program (answering the three questions: for who, on what it haseffects, what are the objectives); definition of the risks of the research program; description ofthe 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 integratedin the system or solution in order to connect the different objects and to respond to therequirements; characterisation and description of the different functions.

A further example for a Best Practice could be the MICA approach. Design research activitiesare often project-oriented activities defined through the specific project oriented industrialrequirements. The MICA approach could be used by design researchers in order to support thedefinition and development of new design technologies and concepts in a project-orientedresearch environment.

However, it is essential to keep in mind that Best Practices are based on static and standardrules whereas researchers need a flexible environment. Not every research activity can beoptimised by introducing a Best Practice. People and culture are the key to transfer and createknowledge about Best Practices. A company needs a pro-sharing culture in order to be able tomotivate the exchange of Best Practices. Elements of a pro-sharing culture are: Personalrelationships, common areas of interest and expertise, continuous exchange and creation ofnew knowledge, learning through teaching and sharing, etc.

Organisational and technical support should join the cultural support in order to guarantee anoptimal exchange of information. An organisational support could be a monthly meeting of aBest Practices discussion group, a monthly update of company members about new BestPractices, etc. Technical support includes intranet technologies, technologies supporting theexchange of information, etc.

6 Conclusion

We consider the identification and transfer of Best Practices to be one of the possible tangiblemanifestations of knowledge management - the process of identifying, capturing, andleveraging knowledge to help organisations to improve their daily work processes and tocompete with other organisations. Surrounding the process of identification and transfer, andhelping 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 orderthat the transfer process has a chance to work. Nevertheless, every organisation has to find itsown enablers.

After the identification of a Best Practice could follow the transfer and adaptation of this BestPractice in order to solve the problem related to a process. Moreover, the identification of aBest Practice could lead to process reengineering activities, involving people's competenceand organisation form and habits, with the objective to achieve a better performance for thisprocess. 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 BestPractices and has interfaces with knowledge management methods. However, this approachneeds 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 andbenchmarking in manufacturing planning and control system", in OE/IFIP/IEEEInternational 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 managementpractices on performance and competitive advantage, Decision Sciences, Vol. 26 No. 5,pp. 659-84, September/October 1995

[3] O'Dell, C., Grayson, C.J., If Only We Knew What We Know, New York: The Free Press.238, 1998

[4] Gardoni, M., Spadoni, M., Vernadat, F., "Information and Knowledge Support inConcurrent Engineering Environments", 3rd International Conference on EngineeringDesign and Automation, EDA'99, Vancouver, B.C., Canada, August 1-4, 1999

[5] Gzara, L., Rieu, D., Tollenaere, M., "Product Information Systems Engineering: anapproach by reuse of patterns", Proceedings of The Product Data Technologyconference PDT Europe 2K., Noordwijk, The Netherlands, May 2-5, 2000

[6] Vemadat, F.B., Enterprise Modeling and Integration: Principles and Applications,Chapman & Hall, London, 1996

[7] Gardoni, M., Blanco, E., "Information and Knowledge Support in ConcurrentEngineering Environments", 7th ISPE International Conference on ConcurrentEngineering, CE'2000, Lyon, France, July 17-20, 2000

[8] Harzallah, M., "Modelisation des aspects organisationnels et des competences pour lareorganisation d'entreprises industrielles », PhD thesis, University of Metz, France,2000

[9] Voss, C., Blackmon, K., Hanson, P. and Oak, B., "The competitiveness of Europeanmanufacturing - a four-country study", Business Strategy Review, Vol. 6 No. 1, pp. 1-25, Spring, 1995

[10] Barthes, J.P., Grundstein, M., "Discussion Summary", 3rd International Symposium onthe Management of Information and Corporate Knowledge (ISMICK'95), InstitutInternational 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 JapaneseCompanies 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 4697 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

LATE POINT DIFFERENTIATION ANALYSIS FOR CONFIGURABLEPRODUCTS

T A Lehtonen, A O Riitahuhta, and J M Malvisalo

Keywords: Configuration modelling, product architecture, planning and workflowmethodology, design-for-X.

1 Introduction

Late Point Differentiation is an important topic in variant production. This meansstandardisation early in the manufacturing process and differentiation at the end of theprocess. It is a cost-effective way of work and it is regarded as universally good principle indesigning configurable products.

However, reducing the cost of variety is not the only objective driving to use of late pointdifferentiation. 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 productarchitecture to the delivery time. Usually the purpose is to minimise the delivery time, bymaking changes to product architecture. The analysis points out modules, which are criticalfor the delivery time. This analysis provides information for contemplation, whether productdesign 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 arepresented in sequences of sales process and production/assembly process. Critical time line ofthe delivery is then drawn across the matrix. The relations on the left side of the line indicateacceptable design solution/production sequence, but the relations on the right side are likely tocause problems like re-work in assembly line.

2 Late Point Differentiation in time critical deliveries

Late point differentiation is often regarded as a tool for manufacturing engineering. Howeverthe manufacturing and assembly sequence is only secondary mean to achieve late pointdifferentiation. Product architecture affect as a dispositional mechanism, which allows latepoint differentiation or ultimately makes is impossible. Applying late point differentiationrequires:

• Product architecture is modular and modular decomposition corresponds to the neededvariation. [1]

• Production sequence is made according to add-on -principle. This means that base unitscommon to all variants could be assembled first and variable parts could be added in laterphase of the production. [2]

ICED01-C586/139 293

In this paper we focus on time critical deliveries. In these deliveries there are two morerequirements:

• Production sequences should be optimised for sales-process.

• In order to be able to optimise the product sequence also the product architecture shouldbe refined (and adapted to requirements of sales sequence).

The late point differentiation analysis is a tool for this. The relations between productarchitecture and sales-delivery decisions are examined and the result is compared againstproduction sequence.

The main idea is shown in figure 1. The relations onwards (descending from top to down) arenot a problem, because needed sales decisions are already made when productionspecification should be frozen. The relations backward (ascending from down to top) areproblems, 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 haverelations to modules, which are needed early in the manufacturing process. On the right, thereare no such feedback relations and manufacturing can be started simultaneously with salesprocess. The patterns beside each of the figures show the relational attachment of sales andmanufacturing process in function of time.

294 ICED01-C586/139

3 Starting point of the analysis

The analysis requires a list of modules that are used in a configurable product family. Thenmodules should be arranged in sequence of production or assembly. The sequence could bealso 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 isoften a difficult task. According our experience, the sales process is seldom defined veryaccurately. The actual sequence of decisions in sales process is not readily obtainable, while itis critical for the analysis. Therefore, every effort should be given in order to get thisinformation.

There should be only one relation between a sales decision and a corresponding module, if theproduct is engineered according to strict functional module structure. However, this is hardlyever 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 technicalsolutions often rule out the functional module structure.

4 Progress of the analysis

The analysis tool is based on asymmetric matrix. The modules of the product are beingexpressed in rows. The rows are arranged so that they are approximately similar to theproduction sequence. The first modules are needed in first production sequences. They arerepresented 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 thatthe first decisions made in sales process are in the first columns and the last decisions are inthe 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. Thestrength of the relation is also examined. If a sales decision has an very strong influence on toa module, the value of the relation is set to 9. The value is 3, if the relation is moderate. Ifthere is only minor interaction or correspondence between a sales decision and a moduleselection, the value is represented with 1. This 9-3-1 division stresses the strong bonding andit 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 thematrix. Simple diagonal could be used, if delivery and sales-processes would be both linearand synchronous. In that case all relations at the lower left corner of the matrix are forward-type and will not cause problems. The relations above the diagonal are backward-type andthey indicate problems in sales-delivery process.

However delivery and sales-processes are seldom, if never, linear and synchronous. Insteadthere are decisions and tasks that are being made and done simultaneously. The progress iseverything but linear. Therefore, instead of simple diagonal a better estimation is needed. Inour case, we used workflow diagram as starting point. Suitable workflow diagram is a simpleGantt 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. Thebars show the duration's of individual tasks. Ideally, there would be a one-to-one relationbetween the tasks and the modules. This means that one task includes manufacturing andassembling one module. In reality this is usually not the case, but tasks are manufacturingstages that are related to many modules. The chart may be converted to show modules bymarking the modules to the task where a module is first needed in manufacturing process (orwhere it's lead time is encountered).

The timeline, which would guarantee progress without iteration, is estimated according to thisdiagram. The example of a result can be seen in figure 4. The fraction line across the matrixshows a similar shape than the workflow diagram. In this case there was one task, which tookvery much time and is related to many modules. This causes the bulge to the right in thefraction line.

In the figure 4 the fraction line shows, which relations between sales decisions and modulesare suitable for current sales and manufacturing process. The relations left of line would causeno problem, but relations right from the line would cause iterations in the manufacturingprocess. 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 analysisbecause it would be critical to know if a module is specified, selected or even needed at thestart of the task.

Figure 4. Example of Late Point Differentiation matrix.

5 Results of the test case

A test case with the proposed tool was conducted in a company delivering heavy mobilemachinery. The objective of the company is to deliver configured products instead of earlierproject 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, onlystreamlining assembly was examined and lead times were not considered. The product was arevised version of an old product in the test case.

As this was a case of revised product, many known problems were already corrected. Theresult of the analysis showed that product was quite satisfactorily adapted to currentproduction/sales processes. However, many problems were pointed out. It is noteworthy thatalmost all causes to them were new features in the product. It seems that the aspect ofvariation 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 gradualproduct improvements. The need for this kind of analysis at product development stage wasacknowledged in the company.

The result was verified also by making survey amongst the product experts. The answers hadgood relevance to results of the analysis. One general notation was that all expertsunderestimated problems that were in their own responsibility area.

6 Conclusions

The paper presents a method where late-point-differentiation is analysed using DesignStructure Matrix (DSM) type approach [4]. This method does add time element to the relationmatrix in the form of critical time line. This is required when analysing Late PointDifferentiation and it is a novel approach. Proposed method will also enlarge the focus of latepoint differentiation thinking. Not only the assembly order is regarded, but also lead timescould be taken into account.

Late point differentiation analysis is a usable tool for industry with firm methodicalbackground. It provides effective ways for guiding the design and discovering problems inadvance. It requires thorough co-operation between sales, design and production people andso encourage applying integrated product development [5].

ACKNOWLEDGEMENTS

The authors would like to thank the personnel in the case company for their efforts. We alsoacknowledge National Technology Development Centre of Finland (TEKES) and the casecompany for funding the research presented here.

References

[1] Erixon, G., "Modular Function Deployment - A method for Product modularization",Dissertation, Royal Institute of Technology, Stockholm, 1998

[2] Ishii, K, Eubanks, C.F. "Design for Product Variety. Key to Product Line Structuring",ASMEDesign Technical Conference Vol.2 pp.499-506, Boston 1995

[3] Clausing, D., Pugh, S. "Enhanced Quality Function Deployment", Design andProductivity International Conf., Honolulu, Hawaii, 1991

[4] McCord, K.R., Eppinger, S.D. "Managing the Integration Problem in ConcurrentEngineering", Working Paper no.3594, M.I.T. Sloan School of Management,Cambridge, MA, 1993

[5] Andreasen, M.M., Hein, L. "Integrated Product Development", Institute of ProductDevelopment, Copenhagen 2000

Time Lehtonen, Asko RiitahuhtaTampere University of Technology, Machine Design, Box 589, 33101 Tampere, FinlandTel: +358 3 365 2627, Fax: +358 3 365 2307, E-mail tle@me.tut.fi. aor(ajme.tut.fi

Jani MalvisaloFastems Oy, Tuotekatu 4, 33840 Tampere, Finland, E-mail Jani.Malvisalo(5),fastems.com

©IMechE2001

298 1CED01-C586/139

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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 theireconomic activities. Multitude of services have been and are being created and operated invery diverse environments. Those services are designed somehow. Be it by highlysystematic approaches, by pure trial-and-error, or by some combination of these designstrategies.

Nevertheless, those involved with the creation or operation of services and interested inachieving competitiveness and efficiency may be frustrated with the meagreness of referenceson services design. Despite the interest raised by the matter in the academy, books dealingwith the fundamentals of the subject are few, as may be verified by searching booksellersthrough the world-wide-web. Two books where the authors apply engineering designmethods to the design of services stand alone [1,2]. What is found, on the whole, is theoccasional chapter in books on service management and operations [e.g. 3, 4] presentinggeneric ideas about service design. On the other hand, there is a great deal of information andactivity 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 callfor 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, wrotethat in industrialised countries services can be industrialised in three ways: via hard, soft andhybrid technologies and gave a list of examples that would delight any engineer.

Hewlett Packard, recognised for its excellence in engineering development, presents in a pagerelated to products & services in its site at the world-wide-web the following topic of itsstrategic priorities [6], with my highlights:

"Create e-services ecosystems that place HP at the center - With its multi-prongedstrategy focused both on present needs and on creating a roadmap for the future, HP'sprinting e-services strategy will drive the development of inventive Internet printingappliances, services and infrastructures that will make printing and imaging asintegral to the Internet experience as is e-mail today."

Aiming at the creation of ecosystems the company indicates that those appliances, servicesand infrastructures have to be integrated and interdependent. The development of integratedproducts 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 asolution for satisfying customer needs through a combination of objects, procedures andpeople. It is proposed that design of services ought to be approached as design of systemswhere those elements comprising the design solution will come into the system as a result ofhow design specifications are satisfied rather than induced at the onset of the process. Theproblem 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. Theseare organised as design specifications, DS, which is a kind of genetic code of the engenderedsolution. A complete DS also describe conditions and requirements to be complied by thesolution along its stages of development, use and disposal [7].

The most adequate result of this engendering process will be the solution that best satisfies theDS. However, a fascinating characteristic of the process is the possibility of generatingseveral alternative solutions for the same design specifications. Mainly because: i)specifications are not satisfied in exactly the same manner; ii) there are many attributes thatare specified in ranges of tolerance; iii) information to elaborate the specifications isimprecise and incomplete. All these allow enough degrees of freedom for the solutions to bevaried and yet adhere to the design specifications.

A solution may take two fundamental forms. It can be a physical structure, an object such asa cloth pressing iron. It can be a procedure such as a computer programme or a packagedelivery scheme. Rather than being a natural result of the design process the form of thesolution may be induced at the process onset. At this point, asking for the design of a clothpressing iron will induce rather different results than asking for a mean to keep the clothwithout wrinkles.

Broader specifications are formulated if hidden assumptions are surfaced and altered when theset of needs is considered. That will facilitate the widening of the field of solutions. StuartPugh, always pugnacious about the paramount importance of design specifications as the solereference for the design activity, proposed the static-dynamic product status as a frameworkof thought [8, Ch. 19] for broadening up the design specifications when formulated. Broaderspecifications open up opportunities for innovative solutions that break away from staticconcepts commonplace. The static-dynamic product status is a necessary consideration inservice design.

Differentiation between service and product is one of the issues related to service design andmanagement. Package delivery would be immediately recognised as a service and a laptopcomputer as a product.

A major difference between a product and a service, as both are largely perceived, is howpeople are made part of the design solution. For products, the buyer is solely responsible forits use and operation, like with the laptop computer. The manufacturing company transfersthat responsibility to him. Services are processes in which some or all actions required to runthem may be done by the service company personnel. The buyer may be passive as when heorders 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 processmuch. Such categorisation is illusive, constrains the conceptual phase of the process andincreases 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 userwhose interest is to do her banking transactions?

In fact, the ATM is part of a solution system comprising objects, procedures such as softwareor rules of operations, and people that work together to execute bank transactions satisfyingthe customer and the service company.

What about package delivering? What the customer cares is to have her package safelydelivered on time to the right hands at a reasonable cost. What would be the solution tosatisfy her needs? Surely it depends on the package itself and how fast and how far thecustomer wishes it delivered. One person of the package delivery company may easily takean envelope with documents sent to another office a couple of kilometres away on the sameroad. He may go through very simple procedures for collecting and delivering, may travel onfoot, and require no particular object to perform his actions. On the other hand, to take livefish from fish farms to sophisticated restaurants that serve fresh food could require specialprocedures, specific objects, and involve several service people.

When a designer is briefed to provide a solution for the restaurants needs she will be facedwith devising objects and procedures to do the job. If these are not fully automatic, thedesigner will have to employ people to run them. What and how many objects, proceduresand people are going to be involved will depend on the conditions constraining the solutionand on the adopted design strategy. Instead of being concerned with categorising the solutionas a service or as a product, designers ought to be looking for the best solution for theproblem posed, obtaining different ones by varying the combination of objects, proceduresand people into the solution system.

How the elements of the solution system are combined is a design decision based on thebusiness strategies of the service company. The solution system provided by a hammermanufacturer might be restricted to the object hammer. The people to operate it and theoperating procedures will be decisions transferred to the customer. A taxi company, in itsservice, could provide the object car, the personnel to operate it, and leave in the hands of thecustomer the procedures for going from the origin to the destination. In the service in asurgery ward at a hospital, the objects, the operating personnel, and the procedures are verymuch 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 ofproducts as shown in the two books referred at the Introduction. Hollins&Hollins [1] pavedthe way and brought along some of Stuart Pugh's teachings on total design [9] with whomBill Hollins had an academic association. Ramaswamy [2] came a few years later under theinfluence of Clausing's total quality development methodology [10]. These books teach howto structure the service design process and to apply valuable supporting methods andtechniques to service development.

ICED01-C586/480 301

Nevertheless, why is it that the word service is not even mentioned in the whole call forpapers of an important design conference such as ICED? The hypothesis is that this is due tothe presence of people as an integral element of the service process

Traditionally, service development and operation rely on human abilities, of both theservicing personnel and the customer, to cope with unpredicted situations and to negotiateways to have the service process completed. Humans have the marvellous faculty ofadjusting to non-conformities or to unforeseen situations in processes.

When discussing how services are approached Levitt [5, Ch. 3] wrote that for historicalreasons "service took the form of one person's labour for the benefit of another....performingone-on-one highly personalised service....just right to the exact specifications of each familiarcustomer 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 createundesirable situations. Customers are insatiable. When faced with a serving person thatapparently has some power to decide and act upon service processes, a customer mayrelentlessly pursue the opportunity to have things done his way. In some cases the servicecompany yields to the customers' unexpected demands. A couple of hours at a check-incounter in the airport will reveal several of these. However, fulfilling those demands is notalways reasonable, feasible, or desirable to the company. Denying their satisfaction maycreate insurmountable conflict at the interface between the serving people and the customer tothe point of disrupting forever any business with that customer.

Person-to-person relationship induced service development and operation to be largely doneas an ongoing trial-and-error process of adjustment, thus creating the impression that it is notfeasible 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 clearexample. Efficient services may be systematically designed and variation in behaviour andmistakes that people are bound to make may be prevented by adequate training, fail-safeprocedures, and redundancy of people like a pilot and a co-pilot.

The notion that services are basically exchanges between a serving person and the customershies engineers away from service design since they usually feel ill equipped to deal withhuman-to-human interactions. On the other hand, non-engineers involved with design ofservices are also prevented from taking advantage of the immense technological advancesavailable today due to a lack of technology awareness and the perception that only humanscan provide what the customer wants. The latter is true for a number of circumstances wherehuman warmth and emotional presence are important. However, in many cases the servingperson is only there because long ago the provision for the customer needs was set that wayand the reasons for that were never challenged. The banking transaction system supported byATMs is a case-in-point of successful challenge and change of the traditional clerk-at-the-counter service. Now we may take months without need for seeing or talking to any person inthe banking organisation.

Concern with human factors in design has increased dramatically in the second half of lastcentury. Largely with greater focus on the customer and lesser on the serving people. Therise 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, whatis understood by design with people in mind, broadly speaking, is the avoidance ofcircumstances that are uncomfortable, ambiguous, risky, or demand unduly physical or mentaleffort. On the whole, people are being cared for but they are still passive pieces in the solutionsystem. What is lacking is how, by design, to take advantage to greater extent of humanfaculties. Designers ought to make an effort to integrate people to the solution system withfreedom to apply their intellectual and emotional abilities to run the service processsuccessfully.

The intent of this paper was to speculate on the design of services in an attempt to clarify whymethods for systematic service design are so rare. I believe that the main reason is theinability 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 tosatisfy customer and company needs through systems that integrates objects, procedures, andpeople 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 ofengineering and human sciences. A service design team should comprise, or at least involve,engineers, marketers, psychologists, sociologists, anthropologists, and professionals that workas 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 havegood conditions to create innovative and efficient services that benefit from technologicaladvances 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 hiddenassumptions that may preclude the generation of innovative solution concepts. Thechallenge is simply done by asking why or why not are those requirements or constraintsthere.

2. Look for the solution in terms of an integrated system of objects, procedures and thinkingpeople. Not as product or service.

3. Establish required and desired relationships and interactions between objects, proceduresand people in order to integrate the system.

4. Consider the service system as a process in which its parts have to work in coordination inorder to satisfy the customer and the company.

As for the methods for service design, those that are used in engineering design and aretechnology independent [8] are just as adequate for structuring and taking the design processto the stage where concepts have to be made real, a transition often called embodiment byengineers. From this point on, specific technical knowledge is required and the methods usedin 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 copingwith and using effectively the human behaviour. Such problem remains hidden andunresolved 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 bymultidisciplinary teamwork. However, it is not compulsory to have serving people inservices. They should be there as the best alternative to provide customer and companysatisfaction.

Technology must be applied to provide solutions that prevent people from working in tediousand intellectually undemanding processes. Creative application of technology will generatesolutions 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 engineeringdesign coupled with the vast knowledge on human behaviour are powerful tools for thecreation of innovative alternatives in services.

References

[1] Hollins, Gillian and Bill Hollins. Total Design: managing the design process in theservice sector. Pitman Publishing, 1991.

[2] Ramaswamy, Rohit. Design and Management of Service Processes: keeping customersfor life. Addison-Wesley, 1996

[3] Lovelock Christopher H. and Lauren Wright. Principles of Services Marketing andManagement. 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 AndradeDepartamento de Engenharia Industrial, Universidade Federal do Rio de Janeiro, caixa postal68507, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

FUNCTIONAL PRODUCTS CREATE NEW DEMANDS ON PRODUCTDEVELOPMENT ORGANIZATIONS

O Brannstrom, B-O Elstrom, and G Thompson

Keywords: Functional Products, Integrated Product Development, Service Design, ServiceManagement, Competitiveness, Whole Life Cost

1 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 orcontrol systems, increasing the complexity of product development work. The productsthemselves also require significant services to support them, many critical for their use andhence their value. Accordingly, Normann & Ramirez [1] argue that it is no longer possible todraw a distinct border between products and services, as all products include services vital fortheir value. Today, in professional Business-to-Business relations, we believe that thecustomer 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 offerthe market a unique product through product differentiation. According to Nordstrom &Ridderstrale [2], product differentiation will no longer be about the hardware, but ratherthrough 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 scopeof product development work into a "total offer". Although the authors all have theirprofessional backgrounds within the engineering field, we belief that this is a subject thatrequires 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 onproduct development organisations. Also, we will propose a structured product (total offer)lifecycle model that integrates all value adding activities within a company. Especially, weaim to determine what demands this new scenario puts on the engineering design activitieswithin a company.

ICED01-C586/606 305

2 Background

In respect to previous research, the development of a total offer overlaps a number ofresearch areas, including integrated product development (IPD) of goods, servicemanagement and development and industrial organisation. In the following sections a briefoutline 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 howto best develop physical products. Results from e.g. the WDK School can be found from theearly eighties, and early work done by Hubka [3] is still used as reference for researchersconcerned with structured product development models and processes. Other well knownexample 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 beingboth mature and vital. Still, research in the area have been focusing on physical products, andin line with our objectives we will try to use knowledge from the area as a step stone to adevelopment model in a wider sense. One might argue that the integration in IPD aims tocover 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, howeverthey do not include services a mainstream item. Although taking into account other aspectsapart from engineering, we still find it aimed at marketing, developing and producing aphysical product. The generic development process presented by Ulrich & Eppinger [7]includes different types of activities, mainly marketing, design, and manufacturing, but alsoother activities, such as finance, legal and service. But once again, we find that thedevelopment process deals with physical products. There is no process for developing orverifying services. What we like to bring forward with these references is not that they areinsufficient to our purpose, but rather that they provide an important framework in the workof developing total offers. Important reasons to adopt a well-defined process in productdevelopment are: quality assurance, co-ordination, planning, management and improvement[7]. For a company trying to integrate its value adding activities, these are vital reasons tochoose 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 stillclaim that it is no longer holistic enough to cover the needs of every modern company. Tounderstand this we have to understand that the area of IPD has its roots in the paradigm ofscientific management, starting with Adam Smith and his pin-fabric that he made famous inlate eighteen century England. According to Gronroos [8] most of today's managementprinciples are based on a scientific management perspective, a perspective that focuseseconomy of scale and mass production [9], Generating customer value within the massproduction and mass consumption economy was, and still is, done through selling thecustomer single products or services. But the means for competition have changed, and themarkets are undergoing major structural changes [10]. Gronroos [11] points out maturingmarkets, an increasing global competition and customers demanding individual offers andtreatment 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 thissituation, competition through single products becomes hard, if possible at all, andcompetitive 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 bothtangible and intangible assets, such as knowledge, financial offer, service deals, etc. [1]. Butas focus is shifted from transactions and products, new demands on how solutions tocustomer problems are to be developed emerge. Grb'nroos [11] argues that a total serviceoffer 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 humanresource 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 theoutcome to total customer-perceived quality in enduring customer relationsships.

4. From production of the technical quality of products (goods or services) as the keyprocess in the organization to developing and managing total utility as the key process.

In a company applying a service management perspective, a traditional product developmentapproach within a specific product development department is not enough as the developmentof services integrates activities from a number of departments in the company to develop allparts in the service system [12]. According to Edvardsson [10] there are three maincomponents that build up the service offer: The service concept, the service system and theservice process.

The service system defined by Figure 1 represents the resources required for the service andis important in this context as it implicates vital differences in designing services compared tophysical goods. The service system can be divided into two parts, the interactive part (frontoffice) and the support part (back office). It is the interactive part that is visible to thecustomer.

Figure 1. The Service System (Edvardsson [10])

We will not describe the different parts of the service system in detail, but we would like toemphasise some important points. In the service system the customer has a role as a co-producer and user, while the customer traditionally in the case with physical goods normallyhave the user role only. When designing a service system we have to keep in mind thatalthough 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 iswhat Chekland [13] refers to as a "soft system", meaning that it will not have the repeatableand logically predictable behaviour of a technical system. Accordingly, all models of a softsystem, e.g. the service system, will not be representations of it, but merely intellectualdevices being used to explore them [14]. According to Norling [15], the most significantdifference between a manufacturing and a service company is in fact that the service consistsof sets of activities that may not be standardised and quality controlled in the same way aswith physical products. Also, the interfunctional dependency between e.g. marketing, finance,production and administration are higher in services as they all contribute simultaneously inthe service interaction with the customer [16].

3 Industry survey

An interview study was carried out within Swedish industry to explore industrial perceptionsof, and beliefs about, 'total offer' products. As our aim was explorative, a survey approachwas selected [17], and interviews were carried out in a semi-structured form with a total ofthirteen executives at eight different companies. The interviewees were selected due to theirholistic view of the company and typically the persons interviewed where Chief ExecutiveOfficer (CEO), marketing directors or, in the larger companies, persons responsible forcompany strategy or future product concept development. Unfortunately, all companiesdemanded to be anonymous in all external publications as a condition for their participationdue to the sensitive information they shared with us on a strategic level.

The companies selected represent different types of companies, ranging from large hardwaremanufacturers to consultant companies. All of the companies have mainly a business-to-business focus although some of their products end up at consumers. Even if all of thecompanies in the study were Swedish, they all act on an international market, some in Europeand some worldwide.

To verify the results of the interviews all interviews where recorded and the participantsreceived a written copy. In some cases the interview results was discussed with theinterviewees, 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 materialwithout prejudiced to find categories to structure the material.

4 Results

In this section we give a brief presentation of the results from the survey. Two aspects will beaddressed, each company's view on how to generate customer value in the future and howthat view will affect their development operations.

Instead of selling only isolated products or services, the companies want to sell integratedsolutions or concepts with responsibility for performance and reliability. This means takingover non-core business from the customer to reach economy of scale and co-ordination spin-offs. Some of the companies emphasised that they wanted to take the knowledge heavyposition in the value chain, thus integrating several sub-contractors into a joint offer. Figure 2below 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 wasstrongly emphasised, and to be integrated in his work processes to understand the truecustomer needs. Three of the companies expressed that they had to be able to understand thecustomer situation in order to improve not only their own processes, but also the customerprocesses. A number of companies brought forward a change in customer and sub-contractorrelations. They claim to move away from the traditional buy-sell transactional relationshipexcept for low price large volume goods. Instead they are moving into a more integratedrelationship 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 whowould get paid, as the integration was so close.

All the hardware vendors in this study expressed that they had quite mature hardwareprocesses and only one of them expressed the need for enhancing them further. With that weare not saying that those process are completed or beyond further development work, but it isan indication of where these companies will have to put in their effort in the future. Morethan anything else it is pointed on the need for service processes. Especially one of thecompanies (Company 1) is concerned about the performance measurement of services andproposes a hardware-like approach for dealing with services. Also, they claim that only wellestablished work processes could result in services being uniform and scalable. Generally, animportant part of future development work will be to develop work processes and proceduresfor service production. Three of the companies express worries about how to manage theintegrated development work of total solutions, especially the integration of hardware withservices.

5 Analysis and discussion

The results from the interview study support our initial assumptions, i.e. the companies in thestudy want to sell the customers complete solutions with an increased responsibility forfunction, performance, reliability, etc. But the companies also emphasised a new relation tothe customer. A relation where the traditional buy sell relationship was abandoned forcollaboration and the achievement of common goals. Generating customer value in the futureis to provide the customer with complete solutions to maximise his profit through co-operation. 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, eachcontributing in a combined effort to provide the customer with the desired function. It isimportant to note that although the processes are pictured as separate, there is obviously aneed for a high degree of interaction between the processes. This is especially true in theconcept phase where there is a high degree of creativity. The processes steps should not beseen as a strict sequence, rather they tend to overlap each other in practice. It is alsoimportant to realise the difference in life-cycle length between the different productcomponents. While the lifecycle for a jet engine hardware, from initial idea to last enginescrapped, is in the order of 30 to 50 years, the embedded software control system might havea life span of ten years and the service might be replaced every year.

The concept of functional products that include hardware, software and services hassignificant implications for engineering designers who have been concerned principally withhardware. It has long been recognised that, under many circumstances, maintenance andfailure costs can be as significant as the initial product cost. However, it continues to be adifficult argument to persuade clients to pay high initial costs in the expectation of futuresavings when selling just hardware. In the case of functional provision, such arguments areredundant. There is no requirement to convince anyone of the need to invest now for futuresavings when the functional provider decides the optimum balance between initial cost,maintenance and failure costs. The designer then discovers previously unrealised freedomsand has many opportunities for creative thought. A decision may be made to increase initialcost and to spread the cost throughout the expected life of the equipment. Or, initially lowcost 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 ofperiodic 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 inrecent decades.

The difference in nature between the service system and the technical system implieschallenges for the development organisation. Being able to handle traditional engineeringactivities will no longer suffice. In some cases the single employee is to the customersynonymous with the organisation, and it will be his/hers motivation, training and access toresources that will decide the functional products availability. What we must do is to designattractive jobs and a stimulating environment that promotes employees with the rightmotivation, experience, motivation and enjoyment [10]. It requires integration of all activitiesin a company, and departments usually without a product development focus, e.g. humanresources and after market, will find them selfs being part of a functional productdevelopment 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 allthese part time developers will certainly require a well-structured development effort. As aservice system due to its 'soft' nature is formed and affected by its cultural context, thebehaviour of the system will not be obviously transferable between different customers,branches or countries.

6 Implications

Industries competing in today's changing market will have to carefully consider how toapproach the problem of functional product development. Especially, the after-marketactivities 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 theresearch society. Future research must fill out the gap between the long research traditionswithin service management and integrated product development, the former traditionally abusiness school subject and the latter traditionally an engineering school subject

7 Conclusions

The literature survey indicates that there are changes in the marketplace that makes it hard toachieve product differentiation, i.e. a competitive market situation, through hardwareproducts only. Instead, competing effectively in the market place will require a broaderperspective on value creation. Companies have to combine all their value adding activitiesinto complete offers, or functional products. The function provider takes an extendedresponsibility for the product through its lifecycle.

Our survey in industry supports these findings and expresses a need for integrating thedevelopment of hardware, software and services into complete offers. Although makingvaluable contributions, we belief that the literature on IPD and design science does not coverthese needs. Therefore this paper has propose a model that combines the lifecycle processesof 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 functionalproduct components differ greatly.

ICED01-C586/606 311

References

[I] Normann, R. and Ramirez, R., "Designing Interactive Strategy. From Value Chain toValue Constellation". Wiley, U.K., 1994.

[2] Nordstrom, K. A. and Ridderstrale, J., "Funky Business - talent makes capital dance".BookHouse Publishing, Stockholm, Sweden, 1999.

[3] Hubka, V., "Principles of Engineering Design". Butterworth Scientific, London, U.K.,1982.

[4] Pahl, G. and Beitz, W., "Engineering Design: a systematic approach". Springer,London, U.K. 1988

[5] Pugh, S., "Total Design - Integrated Methods for Successful Product Engineering",Addison-Wesley Publishing Company, Wokingham, UK, 1990.

[6] Andreasen M. M. and Hein, L., "Integrated Product Development". IPS (Publications)LtdVSpringer-Verlag, 1987.

[7] Ulrich, K. T., Eppinger, S. D., "Product Design and Development". McGraw-Hill,1987.

[8] Gronroos. C., "From Scientific Management to Service Management. A ManagementPerspective for the Age of Service Competition", International Journal of ServiceIndustry Management. Vol. 5, No. 1, 1994, pp.5-20.

[9] Piore, M. J. and Sabel, C. F., "The Second Industrial Divide". Basic Books, U.S.A.,1984.

[10] Edvardsson, B., Gustavsson, A., Johnson, M. D. and Sanden, B., "New ServiceDevelopment and Innovation in the New Economy". Studentliteratur, Lund, Sweden,2000.

[II] Gronroos, C., "Relationship Marketing: Challenges for the organisation", Journal ofBusiness 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 ofQualitative Research. Sage Publications Inc., U.S.A., 2000.

[15] Norling, P., "Tjanstekonstruktion" (Service Design). PhD dissertation, StockholmUniversity, 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 BrannstromLulea 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

HOW MISSIONS DETERMINE THE CHARACTERISTICS OF PRODUCTDEVELOPMENT METHODOLOGIES

B Bender, B Bender, and L T M Blessing

Keywords: prescriptive models of the design process, process modeling, systematic productdevelopment, change processes, mission in product development

1 Introduction

The aim of this paper is to examine the suitability of design methodology to meet today'schallenges of product development by looking at the mission behind the evolution of thesemethodologies. 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 andstructuring process. "Mission" will be understood as the idea of a desired, ideal state and theboundary 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 toget from "As-Is" to "To-Be". This means that to be able to judge the appropriateness of a de-sign methodology for solving particular problems, it is necessary to know the mission under-lying this methodology. Furthermore, a reorientation of design methodology to meet today'schallenges requires rethinking of the mission of product development rather than trying toadapt existing strategies to today's specific boundary conditions.

This paper is of the 'speculation' category, evolving an idea, not reporting scientific results. Ittherefore focuses on the introduction of a new approach without strong empirical evidenceand shall be seen as a contribution to a hopefully extensive discussion.

2 Challenges of Product Development and the History of DesignMethodology

As early as 1972, Beitz listed the following challenges in product development to point outthe need for a design methodology ([1], S. 6):

• increased complexity of products to meet increasing requirements regarding technical per-formance 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 prod-uct;

• 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 integra-tion of the customer's viewpoint, some of the issues have become even more challenging andnone of these has yet been solved satisfactory. Reality in engineering design departments haschanged, but this had had little impact on the formulation of design methodologies.

The following paragraphs apply to a variety of common design methodologies, but refermainly to the design methodology according to Pahl and Beitz [2], which is very similar tothe German guideline VDI 2221 [3].

The haydays of German design methodology can be set around the 1970s. The early ap-proaches mainly aimed at supporting design teaching [4], Designing was regarded as a proc-ess of problem solving during which complex and contradictory requirements had to be met.Psychological findings on problem solving were combined with strategies from systems engi-neering. These were adapted to the (former) conditions of product development and resultedin a guideline consisting of working steps to be carried out sequentially to obtain certainspecified results.

Design methodology today has not changed much since the 1970s. Numerous research pro-jects (some of them can be found for example in [5]) showed that, in general, guideline VDI2221 is useful for individual design processes, provided it is applied flexibly. Still, in industrydesign methodology is not widely considered to be helpful in meeting the requirements ofproduct development and often regarded as too time-consuming.

What are the reasons for this obvious lack of practicability of design methodology, eventhough it is proven to enhance designers' capabilities to find appropriate solutions to designproblems?

3 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". Problemsolving involves finding a way to get to the "To-Be" state [6]. Design methodologists appliedthe concept of problem solving to both the design problem and the design process. The psy-chological concept of "problem solving" has been transferred directly into a practical guide-line for solving design problems. In doing so, the fact that the assessment of the "As-Is" stateas well as the estimation of the "To-Be " state are highly subjective, has been neglected. Fac-tors 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 develop-ment methodologies. Problem solutions can be of a completely different nature depending onthe discrepancy between the ideal state and the anticipated problems or solutions. For exam-ple in the 1980s the very same market situation lead to two opposite concepts for industrialwork 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 theproblems to be solved, has to be clarified. A mission for today's product developmentprocesses has to be formulated. These missions must then be compared to find elements ofdesign 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 enablepotential users to judge the suitability of the mission, and thereby the particular methodol-ogy, 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 theprocess through standardisation and optimisation, analogous to the strategies in manufactur-ing. With this aim in mind the overall task of product development was divided in partialtasks 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 workforcerather then its support. The integration of the results of partial tasks took place higher up thehierarchy, requiring equally specialised knowledge in these positions. Planning and controlwas based on the elaboration of rather detailed results at long term and also took place inhigher levels of hierarchy. Due to the kind of problems to be solved as well as the corporatestructures in the 1970s, product development could mainly take place within one single unitof organisation or domain. The number of disciplines and groups involved was low comparedto today. The integration of product development activities in the company's organisationstructure and workflow usually resulted in clear areas of (managerial) authorities for every-body involved in the product development process.

The strategies of design methodology match the boundary conditions from the 1970s namedabove. To be able to estimate the use of these strategies to meet today's challenges the formerboundary 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 multidisciplinaryproblem solutions and the parallelisation of product development processes today's aims andstrategies are integration, cooperation and coordination of various disciplines and institutionsin product development projects. The importance of information exchange as well as effectiveand efficient communication and cooperation processes within and between (units of) organi-sations increases strongly. Today, self-organisation, self-management, short feed back circlesand flexible target planning replace detailed top-down planning of working steps and the re-sulting long iteration loops.

ICED01-C586/489 315

What conclusions have so far been drawn from these changes to find approaches to optimiseproduct development processes? Current efforts can be distinguished in two main lines: tech-nology oriented or human oriented strategies.

Technology oriented optimisation of product development

The availability of information and the consistent and general management of data are consid-ered to be the main problems to be solved throughout the product development process, whichleads to the development of specialized hard- and software to support designers in fulfillingtheir tasks. The aim is to store and process the designers' expert knowledge in informationsystems 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 de-velopment, which leads to new concepts for management processes that are based on motiva-tion, goal analysis and review. Therefore not only domain-specific competencies but, me-thodical as well as social competencies of designers play an increasingly important role. Theacquisition of these competencies takes place in an organisational and personal learning proc-ess which has to be integrated into corporate structures.

Table 1. Technology and human oriented strategies for the optimisation of product development processes

goals

managementmodel andprinciples

organisationstructure and

workflow

managerialauthority

feedback,iteration loops

informationflow

technology oriented

• subdivision of the overall processin partial processes

• automation of as many partial pro-cesses as possible

• high availability of informationthrough universal data concepts(process chain)

• management process partiallyautomated by supporting software

• workflow determined by software

• determination according to sup-porting 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 col-

lecting relevant information

human oriented

• optimisation of cooperation andcoordination performance

• motivation and integration of thecollaborators

• high availability of informationthrough organisational integration(shallow organisation)

• target planning• delegation of management func-

tions to lower levels of hierarchy• self management in teams• determination by all collaborators

via targets• cross functional• integrated approach• overlapping authorities in matrix

structures

• short loops because of regular in-formation exchange in teams

• related to the individual• individual is responsible for pro-

viding and requesting information

In table 1, characteristics of technology oriented and human oriented strategies to optimiseproduct 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 abovebut does of course not totally neglect elements of the opposite strategy. In reality elements ofboth strategies often occur as a mix, but mostly with an emphasize on one of the approachesmentioned above.

3.2 Missions related to these Strategies

The comparison of the technology oriented and human oriented strategy shows that these arebased on fundamentally different missions about aims and problems in product developmentprocesses.

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 ishindered by problems resulting from the transfer from knowledge of designers to com-puter data and the performance of current hard- and software.

• Available information will be searched and retrieved by designers and interpreted cor-rectly according to the actual problem to be solved. Therefore large amounts of data haveto 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. Thereforeappropriate strategies have to be found to identify and clarify the aims of product develop-ment from the viewpoints of the collaborators. Simultaneously the integration of individ-ual and organisational goals has to be aimed for.

• Information does not make sense by itself but becomes useful within a particular situationor context of cooperation and communication. Therefore in product development (coop-eration) situations have to be created that enhance the effective and efficient exchange ofinformation of the collaborators. Information technology is needed to support - as op-posed to replace - human design activity.

When examining current approaches for optimising product development it becomes clearthat these are based, to varying degrees, depending on the particular approach, on one of themissions (or parts of these) described above. The missions behind the approaches are rarelymade explicit: looking at their specific characteristics facilitates only an implicit conclusionon the underlying mission. Knowing this, it is easy to explain why there is no such thing asthe "right" design methodology. Different strategies can be valid in different coordinate sys-tems, 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 thisallows a focused discussion on missions in product development, without getting lost in ar-gumentations 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 isthe design methodology according to Pahl and Beitz [2]. This methodology was chosen be-cause numerous research projects over the last decade in Germany dealt with its suitability toenhance effective and efficient product development processes. In addition, the authors of thispaper have experience with the application of this design methodology in teaching and prac-tice.

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 ofproducts to be developed, and the globalisation of markets, lead to problems that cannotbe solved by single designers or within single domains. Therefore engineering designmanagement must match these conditions and is of increasing importance.

• The quality of cooperation processes depends not only on social skills of the individualbut also on other boundary conditions.The individual designer cannot be the only party to be held responsible for successful co-operation. For example corporate culture, organisation structures, workflow, the leader-ship attitude, or the kind of task to be fulfilled equally influence the quality of cooperationprocesses.

• Managing effective and efficient cooperation processes can be learnt and must be learnt.Cooperation and communication can be enhanced by specific boundary conditions andsupported by specific methods. Therefore an appropriate training and the reflection of co-operation situations within the design process improve cooperation performance. Finally,the success of this process of 'life-long-learning' very much depends on the formulationof an explicit mission.

The proposed strategy aims at the optimisation of product development through implementinga corporate culture of individual and organisational learning and the optimisation of coopera-tion and communication processes. A detailed description of the strategy, called Goal Ori-ented Cooperation Management in Product Development, can be found in [10]. Basic ele-ments of this strategy are (see figure 2):

• A model of analysis providing parameters that determine cooperation processes. These ap-ply to entire product development projects as well as to single team meetings. The pa-rameters 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 managementfunctions into the product development process. The model consists of elements of designmethodology according to VDI 2221 (workflow and design methods), elements of ProjectManagement (management and phase concept), and the management attitude as well ascooperation methods, e.g. the concept of semi-autonomous teams well known from manu-facturing.

318 ICED 01 -C586/489

• A strategy for the implementation of Goal Oriented Cooperation Management in ProductDevelopment in practice. The implementation strategy consists of a combination of ele-ments from organisational development and experiential learning (the latter according toKolb [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 cooperationprocesses based on the above described model.

Figure 2. Characteristics of Goal Oriented Cooperation Management in Product Development

4 Conclusion

This paper highlighted the importance of the underlying mission for understanding character-istics of strategies for the optimisation of product development processes in general and de-sign methodologies in particular. Based on theoretical findings on factors influencing the ideaof a current state and the desired state, we showed that completely different ways of dealingwith the very same problems can be found. To clarify this, two different views about the cur-rent problems in product development were presented: the technology oriented and the humanoriented approach. It is obvious that the fundamental differences between the underlying mis-sions prevent the development of a universal design methodology.

Still, there is a need for new strategies in product development since the boundary conditionsand thus the missions fundamentally changed since the 1970s. So far, attempts to adapt theVDI 2221 design methodology only went as far as changing isolated details (for example itsflexible application in iteration loops as opposed to sequential workflow, or computer supportfor particular design tasks). As long as there is no common understanding about missions inproduct development, a discussion about a universal design methodology is not fruitful. Wehave tried to start this discussion by introducing our human oriented mission and the coreelements of an approach to a new - in the sense of adapted to today's challenges - designmethodology that were derived from this mission.

ICED01-C586/489 319

References

[I] Beitz, W., Systemtechnik in der Konstruktion, in: Rau, J. (Ed.), Vortrage undDiskussionen in der Sitzung der Arbeitsgruppe Forschung und Technik der Arbeitsge-meinschaft fur Rationalisierung des Landes NRW am 8. Marz 1972. Verkehrs- undWirtschaftsverlag, Dortmund 1972, p. 6-21

[2] Pahl, G., Beitz, W., Engineering Design: A Systematic Approach. Springer, London1996

[3] VDI 2221: Verein Deutscher Ingenieure (Ed.), Methodik zum Entwickeln technischerSysteme und Produkte, in: VDI-Richtlinien. VDI-Verlag, Dusseldorf 1993

[4] Miiller, J., Arbeitsmethoden der Technikwissenschaften: Systematik. Heuristik. Kre-ativitat. Springer, Berlin 1990

[5] Ehrlenspiel, K., Practicians - How they are Designing? ...And Why?, in: Lindemann,U., Birkhofer, H., Meerkamm, H., Vajna, S. (Ed.), Communication and Cooperation ofPractice and Science. Proceedings of the 12th International Conference on EngineeringDesign. Schriftenreihe WDK 26, Technische Universitat Munchen 1999, p. 721-726

[6] Hacker, W., Allgemeine Arbeitspsychologie: psychische Regulation von Arbetts-tatigkeitea Huber, Bern 1998

[7] Daenzer, W., Huber, F., Systems Engineering. Industrielle Organisation, Zurich 1984

[8] Spur, G., Automatisierung und Wandel der Betrieblichen Arbeitswelt, in: Akademie derWissenschaften zu Berlin (Ed), Forschungsbericht Bd. 6. de Gruyter, Berlin 1993

[9] Brodner, P., Pekuhl, U., Ruckkehr der Arbeit in die Fabrik. Wertbewerbsfahigkeit durchmenschenzentrierte Erneuerung kundenorientierter Produktion. Insitut fur Arbeit undTechnik - Wissenschaftszentrum Nordrhein Westfahlen 1991

[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 Per-fomance, in: Lindemann, U., Birkhofer, H., Meerkamm, H., Vajna, S. (Ed.), Communi-cation and Cooperation of Practice and Science. Proceedings of the 12th InternationalConference on Engineering Design. Schriftenreihe WDK 26, Technische UniversitatMunchen 1999, p. 177-183

[12] Kolb, D. A., Experiential Learning - Experience as the Source of Learning andDevelopment. Prentice Hall, New Jersey 1984

Dr.-Ing. Beate BenderBombardier Transportation, Advance Engineering, Kablower Weg 89, D-12526 Berlin, Ger-many, Tel.: ++4930 6793-2554, Fax: ++4930 6793-2237,E-Mail: bbender@transport.bombardier.com

Dipl.-Ing. Bernd Bender, Prof. Dr. Ir. Lucienne BlessingTechnical University of Berlin, Dept. of Mechanical Engineering and Transport Systems, En-gineering Design and Methodology, Sekr. H 10, Strasse des 17. Juni 135, D—10623 Berlin,Germany, Tel: ++4930 314-24309, Fax: ++4930 314-26481E-mail: bernd.bender@ktem.tu-berlin.de

©IMechE2001

320 ICED01-C586/489

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

VISUALIZATION TECHNIQUES TO ASSIST DESIGN PROCESSPLANNING

P J Clarkson, A F Melo, and C M Eckert

Keywords: planning and workflow methodology, risk analysis and management

1 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 marketsuccess (or failure) of a new product [1], Indeed, for every new product there will be a bestpossible design process that achieves an 'ideal' balance between the technical requirements ofthe product and the commercial aspirations of the company. A successful planner needs to beaware of constraints imposed on the planning process not only by resources but also by theprocess itself. However, in design the process is difficult to define before its has began. Inaddition, requirements change as design processes and the planned activities are notguarantied to be successful. Hence, any support for planning must cope with this dynamicnature of design. The aim of this research is to improve the effectiveness of design processplanning by defining novel ways to generate and visualise alternative plans.

2 Approach

The requirement for improved visualisation of alternative plans emerged from earlier work onthe capture and analysis of task-based design processes [2]. In particular, there was a need toinvestigate a wider range of alternative plans and provide some indication of their relativemerits. A review of existing planning models was undertaken with reference to a number ofspecific case studies. Their relative strengths and weaknesses were assessed and requirementsderived for a new approach that would improve visualisation of the underlying processcharacteristics. A number of alternative models were investigated and adapted to meet theserequirements. The preferred approach was then evaluated with further case studies taken froma wide range of design processes.

3 Design process planning

As in chess, in design planning good moves can lead to early victory, resulting in a costeffective design and a good product. So what defines good design process planning? In orderto answer this question it is necessary to know something of the number and characteristics ofall possible design routes. Then, when presented with a choice of tasks, the most appropriatetask may be chosen in the light of its associated downstream process. Process planning istherefore 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 designroute. The following sections discuss a number of process representations and risk assessmenttechniques 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 beeninvestigated (Figure 1). Gantt and PERT charts are traditionally used to aid visualisation ofcomplex 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 effectivemeans of process planning. However, whilst the first and last tasks are clear, the ordering ofthe 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 revealserial, parallel and interdependent task clusters, where the latter may then be grouped to formlarger coordinated activities. Although the DSM reveals task interdependence, it says littleabout 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 partof the process of task evaluation and selection. A task sequence diagram (Figure 3), whichmakes all routes and decision points explicit, is useful in this respect. This is an expansion ofthe PERT diagram that allows multiple instances of each task, therefore enabling taskssequences 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 thedesign state network (Figure 4), where design states, defining particular states of completionof 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 someredundancy by using the parameter states as nodes linked by the tasks. As a result it is alwayssimpler in form. It relies on the assumption that a given design state can be reached by anumber of different routes and can be derived directly from the task sequence diagram. This isconsistent with observations of a number of design processes made by the authors [2], thoughits 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 taskdependencies, 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, butmisleading in its suggestion of a potential process. Conversely, the task sequence diagramshows all possible routes, but appears too complex. Finally, the design state network alsoidentifies all possible routes, but with much reduced complexity when compared to the tasksequence diagram. Therefore, it is proposed that the design state network, with itscombination of simplicity and completeness, is used as a basis for visualising possible designprocess routes and identifying the lowest risk routes.

The following section discusses possible methods of constructing design state networks andthe provision of addition information to assist design process planning. A particular focus hereis 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 designstates and their associated linking tasks, which can provide adequate separation of the networknodes. The design state network may be drawn manually (Figure 5). Here the separation ofstates is easily achievable, but the unique identification of tasks is difficult to achieve and amore 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 thedesign state network. It allocates specific line gradients to individual tasks, attempting tomaximise the separation of states. It achieves this by allocating gradients with the greatestpossible angular separation to tasks emanating from states that exhibit the greatest processdivergence (Figure 6). For example, the three tasks emanating from state 27 in Figure 4 arerepresented by lines of high angular separation in Figure 6. Those states with the largestnumber 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 identifiedtasks. In addition, prismatic structures emerge in the network that identify groups of tasks (forexample, 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 oftasks by the gradient of the network links. A further benefit is the identification of serial andparallel task groups. A number of other representations have been explored [6], but noneprovide quite the clarity of the tangent diagram. This is further illustrated by Figure 7, a plotfor a 27-task model of mechanical design. The extended mechanical design process ischaracterised by an initial serial sequence (a) followed by a short parallel sequence (b). This isthen followed by two large task clusters (c and e), separated by a bottleneck (d), andconcluded by a final short parallel sequence (f). These characteristics have major implicationsfor the success of the process. In particular, it is important to understand the nature of thebottleneck and whether it represents a particular risk to the project. The task clusters alsohighlight potential for extensive parallel working and the need for resources to be availableconcurrently.

Figure 7. A tangent network for a 27-task model of mechanical component design

4 Risk management and design process planning

Despite the benefits of the tangent diagram in characterising a design process, there is as yetthere 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 assesspossible design process problems has been adopted. It uses a likelihood / impact graph (Figure8) to represent possible technical and non-technical risks, where each risk is assessedqualitatively for its likelihood of occurrence and impact on the design process [7]. Riskmanagement 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 toproduct launch. The usefulness of such a method is then critically dependent upon thecompleteness of the assessment and availability of heuristic knowledge of the product anddesign process. The principle of the likelihood / impact analysis can be applied to theassessment of alternative design routes. If the likelihood and impact of task failure can beestimated for each task on each proposed route, then the route with the lowest predicted costmay be identified. Alternatively the impact may refer to a number of other interdependentmeasures, 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 sumthe 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 sof route ; and c(r(s>) is the impact or cost of the task failure. It is important to note that thisimpact 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 bederived 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 tocomplete the design. Again there a number of possibilities for representing risk. Figure 9shows the probable cost overrun for all the routes shown in Figure 6. Note that the riskreduces 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 individualroutes. An alternative representation may be derived from the tangent diagram where the linethickness now represents a measure of risk (Figure 10). Preferred routes may be shown bythicker lines. Whilst it is now more difficult to ascertain a direct measure of risk, it is mucheasier 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 casesit has been possible to clearly identify tasks which must be performed sequentially or inparallel and task clusters which may be grouped to form larger coordinated activities. Inaddition, potential bottlenecks in the design process and processes which incur the lowest riskof overrun can be identified.

ICED 01 -C5 86/065 327

5 Conclusion

Effective process planning is dependent upon identifying the key attributes that characterise aparticular process. These include natural process constraints, such as bottlenecks, andnetworks of alternate process routes. It has been demonstrated that it is possible to improve oncurrent planning tools to assist with this characterisation. In particular, simple graphicalrepresentations 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 mostpotential as a visualisation tool. Further work in under way to develop software which willallow the interactive development of process plans, supported by the use of design statediagrams incorporating process risk analysis.

References

[1] Mass, N J and Berkson, B (1995). "Going slow to go fast." The McKinsev Quarterly. 4:pp 19-29.

[2] Clarkson, P J and Hamilton, J R (2000), "'Signposting', a parameter-driven task-basedmodel of the design process." Research in Engineering Design. 12(1): ppl8-38.

[3] Krueckeberg, D A and Silvers, A L (1974), "Program Scheduling," in Urban PlanningAnalysis: Methods and Models. John Wiley, pp231-255.

[4] Steward, D V (1981), "The Design Structure System: A method for managing the designof complex systems," IEEE Transactions on Engineering Management. 28(3): pp71-74.

[5] Eppinger, S D , Whitney, D E, Smith, R P and Gebala, D A (1994), "A Model-BasedMethod for Organizing Tasks in Product Development," Research in EngineeringDesign, 6: ppl-13.

[6] Clarkson, P J, Melo, A F and Eckert, C M (2000), "Visualization of routes in designprocess planning," in International Conference on Information Visualisation (IV2000),London, UK, 19-21 July, pp 155-164.

[7] Coppendale, J (1995), "Manage risk in product and process development and avoidunpleasant surprises," Engineering Management Journal. February 1995, pp35-38.

[8] Clarkson, P J, Melo, A F and Connor, A M (2000), "Signposting for design processimprovement, a dynamic approach to design process planning," in Artificial Intelligencein Design. Worcester, USA, 26-29 June, pp333-354.

Dr P John ClarksonEngineering Design CentreUniversity of CambridgeTrumpington StreetCambridge CB2 1PZUnited KingdomPhone: +44 (0)1223 332 742Fax: +44(0)1223332662E-mail: pjclO@eng.cam.ac.uk

© Cambridge Engineering Design Centre 2001

328 ICED01-C586/065

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

A PRODUCT AND PROCESS MODEL SUPPORTING MAIN AND SUB-SUPPLIER COLLABORATION

B Fagerstrom and H Johannesson

Keywords: Product modelling, collaborative design tools, SMEs, industrial case study.

1 Introduction

Many main suppliers are streamlining their operations, moving towards more externalcontracting of their sub-systems. The co-operative aspects of product development are therebyincreasing, and therefore the need to manage different types of relationships, and to exchangeinformation and knowledge. The main supplier is reliant upon the sub-supplier's knowledgewithin certain areas. Thus, it is obvious that the customer-supplier interface now plays a keyrole, and the product and process model is an important part of the design and development ofnew products.

The point in time for involving sub-suppliers and the ability to quickly put together a teamwith distributed actors is an important factor for success. Sub-suppliers become moreimportant as they develop and produce an increasing amount of the components needed forthe final product. As a result, the main supplier's ability to use sub-supplier's knowledge is astrategic factor for the future. The collaboration between main and sub-suppliers is dependenton the ability to manage the information exchange between interfaces for upstream anddownstream tasks, different sub-systems and different organisational functions [1].

Organising and running a development project is a dynamic and complex process, partly dueto the fact that knowledge is added as the project progresses. As a result, earlier decisions canbe considered unreasonable at a later stage. It is therefore important, that the processcontinuously supports the exchange of design information and knowledge. When preliminaryupstream information is utilised too early by the downstream activity, future changes have tobe incorporated in time-consuming subsequent iterations. Overlapping tasks could be bettermanaged through a proper understanding of the properties of the exchanged information. Sub-supplier's ability to work with preliminary specifications, to manage overlapping anddependent 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 therequirement specification and the product structure, including descriptions for what is to beachieved [3]. When doing this, consideration of downstream processes is very important: sub-supplier knowledge must be taken into consideration in a more bottom-up manner in order toavoid sub-optimal requirement specifications and product structures. Functionaldecomposition of the product is an important step when selecting the product structure and forreducing the complexity. The decomposition makes it possible for sub-suppliers to designsub-systems in parallel, even though the interaction between sub-systems must be taken intoconsideration [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], wherethe formal procedure for information and knowledge exchange is often pending.

2 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 andtaking advantage of opportunities. Knowledge is often described as a result of data andinformation. Information is about placing data in a meaningful context, and a commonlanguage for communication is crucial for efficient information exchange. A lot ofinformation about the physical product model is often available, but aspects like decision-making, packaging, suppliers, transports, etc are often pending.

As the products become more complex, the amount of information to be stored anddistributed increases. The need for efficient computer-based tools increases as well.Therefore, digital product models must support the product development process. The modelscontain product related information needed by different actors and tools in the process. Theproduct information framework in the present study is an object oriented product model basedon the so-called function-means tree [3,5], which has been implemented using the commercialsoftware Metis Software. One of the aims of the study is to extend the model to incorporatesub-supplier process information. It is argued that the extended model is a powerful aid forsupporting main and sub-supplier collaboration.

Many delays in product development projects are related to inadequate specifications. Thiscauses even more difficult problems when sub-suppliers are involved. In order to improvehandling 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, allowconsideration of alternative new concepts and technology and consider different stakeholders'views. By incorporating the product specification into the product and process model as anintegrated part, these issues become easier to manage.

There are some shortcomings in information models as well. A lot of the designer's time isspent 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 islacking 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 tacitand explicit knowledge not available in the computer-based models.

3 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 theother. The life phases and aspects are not fixed, and should be determined according to thespecific situation, depending on industry-, organisation- and product type, etc. The mainobjective with the model is to put the needed product-related information into a productmodel 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, constrainingfactors and design solutions, fulfilling the wanted behaviour while meeting the constraints. Itsbasic structure, shown in figure 1, is an object-oriented, hierarchical representation ofdifferent design solutions (assemblies, sub-assemblies, parts and features) and their governingcriteria (functional requirements and constraints). The solutions and their criteria constitute acomplex 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 asfunction performance attributes, constraining limit values or design parameter characteristicscan be linked to the objects. It is also possible to link describing documents and other modelsto the different objects. A DP represents the design solution, a FR is a solution driver and a Cis a solution restraint. The six different relations used are defined and shown in figure 1. Thedesign 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 Olssontable, with so called "context interaction maps," is used. It is also used as a supportingchecklist (fig. 1). Each object triplet (FR-DP-C) in a completed F-M tree has its own Olssontable linked to it, and each relevant table cell contains complementary information, such ascompany preferences, company standards, process descriptions, operations lists, lessonslearned documents and so on. Furthermore, sub-supplier information is in this paper linkedvia 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 upstreamand downstream information exchange, which is sufficient for the purposes of this paper. Thisis shown in figure 2. The DSM is used as an interaction map to describe relevant sub-supplierinvolvement and processes. Design tasks to be performed are identically labelled in both rowsand columns in the matrix. Each marked cell (+) shows a task dependency. Rows indicateinformation providers, while columns indicate information dependants. There are three typesof task dependencies (fig. 2). Independent tasks can be performed in parallel, dependent tasksmust 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 theadvantage 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 quantifythe dependency of information to each task (fig. 2). Furthermore, different actors, such assuppliers 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 thathave to be performed during an entire, new product development project. To deal with thisproblem; the proposed model could be a powerful aid, where the early product model (F-Mtree) 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 theconstraints on the highest hierarchical product level (fig. 1). These formulations are mostlikely derived from a type of project assignment. Relevant information describing theseoverall criteria is linked to the requirement and constraint objects, either as attributes, inattribute lists or as referenced documents and models in other software systems. Then, theoverall design solution (DP) is selected. The DP, which fulfils the FR and meets the Cs, ismodelled as a DP-object. It is connected to the FR and the Cs respectively, and, finally, isdescribed by its attributes and references. The DSM modelling process is dependent on thispreliminary concept and the description of the main functions. The early phases for modellingthe primary tasks in the DSM, should therefore be modelled simultaneously with descriptionof properties, preliminary concept, main functions, requirement specification, etc. Thisprocedure is somewhat iterative and the DSM supports the process.

Next, sub-requirements for the chosen DP are identified and modelled at the next lowerhierarchical 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 andlinked to relevant information sources in the same manner as the first level objects. All thesub-tasks to be developed are modelled in a master DSM (fig. 2), provided by the mainsupplier. Available process information from sub-suppliers is linked to the model objects asinteraction maps via relevant Olsson table cells. It is also recommended that sub-supplierscarry out their own DSM, with, for example, information about design tasks, prototypes,testing, verification, tooling, processes planning and production ramp up. The main supplier'smaster DSM covers information for the complete system, such as, different suppliersinvolved, testing, verification, validation, 0-serie and final assembly. The level of dependencybetween different tasks is also to be stated (fig. 2).

332 ICED 01 -C586/076

4 Product and process analysis

All aspects mentioned above, involving different objects and activities with relations to eachother are very difficult to manage efficiently. The F-M DSM product information model is auseful tool in this instance. The F-M tree and the DSM show the functional couplings andtask-dependencies. This makes it possible to show when, and which, suppliers are involvedduring different stages of the main suppliers' product development process. It also relates sub-suppliers 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 tofulfil one of two or more functional requirements on a design solution on the previous higherstructure. Graphic functional coupling degree analysis [12], based on the information capturedin the F-M tree, can then be used. This technique is based on a graphic interpretation of theaxiomatic design equation [10] for a group of parallel DPs and their governing FRs on anarbitrary level in the F-M structure model. The axiomatic design matrix elements thencorrespond to the z76-relations in the structure model (fig. 1).

It is suggested that functional couplings are defined as interactions between incompatibleparallel design solutions or between design solutions causing negative constitutive influences[11]. Incompatibility can be of many different types. The main areas of interest in mechanicaldesign are geometry, time, system physics, driving effort and material. Constitutive influencecan 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 requirementsthey may also be incompatible in order to meet design constraints. Incompatibility caused byconstraints can be classified according to the same classification scheme as functionalincompatibility. Design solutions incompatible due to geometrical constraints can be coupledin a way similar to incompatible solutions caused by functional requirements. Thesegeometrical 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 havean influence on the input to a parallel sub-system. The DSM will support the process todetermine in which order the sub-systems may be designed to avoid needless redesign, or atleast control the necessary iterative loops that is provided to meet the requirements and todesign a first-class product. As the project progresses, additional knowledge is obtained, andthe 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-suppliersand the main supplier. When a certain sub-supplier have essential information, that could belinked via the Olsson table back to the product model (fig. 1). The DSM will also show whichsuppliers 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, itcould 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 adecoupling 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 todivide the loop into sub-loops. There the iteration drivers are essential for selecting sub-loops.

5 Case study

This paper is based both on theory and on empirical findings from a case study. The casecould be defined as a strategic partnership between the customer and the main supplierAutoliv (first tier), for the development of a new complex product (inflatable curtain: a sideimpact airbag) within the automotive industry. The company Autoliv is a worldwide leader inautomotive 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 areillustrated. In this case, the customer starts the design process with a description of theproperties of the product (item 1). The main supplier (Ml=Autoliv) prepares the designspecification 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 interactionmaps for the F-M tree. The top-level triplet (FR-DP-C) for the product/sub-system is definedby 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 asitem 4 in figure 3. The Olsson table covers life-cycle phases and different aspects. The aspectscould be divided in suitable sub-headings for the purposes of the project.

The solution 'inflatable curtain' (DPI) requires three sub-functions at the next hierarchicallevel below (item 5: FR21-FR23). The top level of the Olsson table is decomposed into sub-tables simultaneously with the selection of sub-functions and solutions (item 6). Thedecomposition of the Olsson table is dependent on the selected solutions. As such, it cannotbe 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, anipmb-relation (is_partly_met_by) as item 9.

The different sub-systems to be designed and their information needs are illustrated in theDSM (item 10). This case illustrates task dependencies, where iteration is provided for thetasks in row 7-11. It is not efficient to have all four sub-suppliers working in parallel, so itwas decided to use the opening mechanism (Supplier 1: SI) and the cells (Supplier 2: S2) asiteration drivers, row 7 and 8 (item 11). After this initial iteration, information could be linkedback to the product model, via the Olsson table. The master DSM (item 12) is used for co-ordination of suppliers and the verification and validation of the entire system. Each suppliercould also define each sub-system's in a sub-DSM (item 13). There, the information from thedesign 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 figure3 (DP23, DP3i and DP32). That will be further discussed in other ongoing work.

6 Discussions and conclusions

In a distributed product development environment, it is essential to determine in which orderthe sub-systems have to be designed and which actors are dependent on each other, duringdifferent stages of the project. A generic F-M DSM product information model has shownpromising results. The model describes both the task and object dependencies. It is alsohelpful for purposes of analysis. Defining the product structure in the F-M tree is important inorder to structure the design tasks and locate them in the DSM-matrix. The DSM addressesboth task and supplier dependency, using the important design parameters in the productmodel for the decomposition of iterations into suitable blocks. Furthermore, the DSMillustrates the feedback loop of information from sub-systems/suppliers back to the mainsupplier's product model, via the Olsson table.

The enhanced F-M tree puts the product related information in a product context. Theobtained structural product knowledge is essential for selecting the sub-system interfaces. Theproduct model supports the information needed for each sub-system (supplier). The masterDSM puts the information into a process context. The model contains the proceduralknowledge, which is a good starting point when setting up new projects. It is also helpful forunderstanding supplier involvement, both from the main and sub-supplier's perspective. It issuggested that the master DSM be performed at a general manageable level, with the detailedsupplier information being described in the sub-DSM for each supplier. Therefore, it is arguedthat the model is not only a model for structuring large amount of information, but also partlya knowledge model for both structural (product) and procedural (process) knowledge in theproject.

As the main supplier often is dependent on knowledge from suppliers, it is recommended thatthe F-M DSM product information model be created with personnel from both the main andthe sub-suppliers. In addition, at least one person from each supplier should be responsible. Itis essential that this is a physical meeting, for two reasons. First, this type of modellingconsists 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 specificationsand the product structure, as long as the design process is defined and supported by theinformation 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 withusing the model, as the model could be computer-based, which is partly done in this project.

7 Acknowledgement

The authors would like to thank Johan Stenquist at Autoliv Sverige AB, for valuable inputand technical knowledge. Funding was provided by the Swedish Foundation for StrategicResearch (ENDREA program). This support is gratefully acknowledged.

References

[I] Fagerstrom, B. and Jackson, M., "Efficient collaboration between main and sub-suppliers", Proceedings of the 4th conference SMESME'2001, Aalborg, 2001

[2] Krishnan V., Eppinger S.D. and Whitney D.E., "A Model-Based Framework to OverlapProduct Development Activities", Journal of Management Science, 4, 1997, p437-451

[3] Schachinger, P. and Johannesson, H., "Computer Modelling of Design Specifications",Journal of Engineering Design, 4, 2000, p317-329

[4] Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D.A., "A model-based Methodfor Organizing tasks in Product Development", Research in eng. Design, 6, 1994, pi-13

[5] Andersson, F., Nilsson, P. and Johannesson, H. "Computer based requirement andconcept modelling- Information gathering and classification", Proceedings ofDETC'2000ASME, Baltimore, 2000

[6] Akesson, A. and Bjarnemo, R., "Dynamic product design specification", Proceedings ofICED'99, Munich, 1999, pp.389-392

[7] Blessing, L. and Wallace, K., "Supporting the knowledge life cycle", Proceedings of theKIC3 workshop, Tokyo, 1998

[8] Steward D.V., "The Design Structure System: A Method for Managing the design ofComplex Systems", IEEE Transactions on Engineering Management, 3, 1981, p71-74

[9] Olsson, F., "Principkonstruktion", Lund University, Sweden (in Swedish), 1978

[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 inAxiomatic Machine Design", Proceedings of DETC'1996 ASME, Irvine, 1996

[12] Johannesson, H.L., "Computer Aided analysis of Functional Couplings in StructuralAxiomatic Design", Advances in Design Aut, Book NQ.H00998, ASME, Vol. 1, 1995

[13] Soderberg, R. and Johannesson, H.L., "Spatial Incompatibility - Part Interaction andTolerance Allocation in Configuration design", Proc. DETC'1998 ASME, Atlanta, 1998

Fagerstrom, BjornIVF Industrial Research and Development,Argongatan 30, SE-431 53 MoTndal, Sweden, andDepartment of Machine and Vehicle Design,Chalmers University of Technology, Goteborg, Sweden.Phone: +46 031 706 61 57, Fax: +46 031 27 61 30E-mail: bjom.fagerstrom@ivf.se

©IMechE2001

336 ICED 01 -C586/076

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

IDENTIFYING AND ANALYSING CHANGES IN A DYNAMICCOMPANY

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 product-family 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 fewchanges 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 powerproducing applications [1]. The study was delimited to the annual production of an enginefactory. Change orders, arguments, and explanatory information were collected at differentpoints of the delivery process. A team of specialists with extensive experience in the fieldanalysed the data in the performance of their daily tasks. The objective was to identify thesources of change to better control their impact on the delivery process. The focus was onchanges induced by the company's own processes. The findings will be used in internalprocess 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-controlledlogistics. In view of material management and inventory control every change causes apotential disturbance. Second, every change order initiates a chain of transactions, both in thedesign 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 helpin managing product data, version history, and engineering change orders, it is obvious thatwe 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 meansthat new markets are opening and new customer needs are being charted. Companies have tomaintain a large product variety and be responsive to evolving customer needs at the sametime. 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 therequirements of a changing environment. All changes, especially in the market, affect thebusiness 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 ofrequirement lists, ideas, and domain structures. It then assumes a more concrete nature in theform of technical specifications, configurations, engineering drawings, and bills of material.These are depictions of the product at different stages and they comprise a continuousinformation flow, which is united with a material flow to make a physical product in amanufacturing process. Product-related documentation accompanies the product in thisevolution. All features and properties, intended or unintended, are involved in the process.

In a delivery process the change is intentional alteration of requirements, design, specificationor contractual terms. The causes behind the change vary. Some typical causes are:

• Feedback from different life phases of the product, striving for better manufacturingcapability, 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 duringthe delivery process. Time-based competition emphasises a change-intensive approach, i.e.product improvements must be promptly implemented.

3 Sources of change

If we want to emphasise the environment's dynamic nature in generating changes over timewe call it a source of change (henceforth referred to as SOC). There is a complicatedinteraction between the environment, business and company processes, which canindependently or collectively behave as a SOC. Depending on the viewpoint we can speakabout external sources and internal sources (see Fig. 1).

External SOCs usually fall outside the company's sphere of influence, such as societyrevising a law or normative rules. However, many changes are not mandatory. Changesinduced by market trends are fully within the power of the company because it defines inwhat market it wants to be and with what product portfolio. Based on its own arguments thecompany makes decisions on product mix and the introduction of new technologies. Thesedecisions 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 onlylimited controlling possibilities, such as specific customer requests and cases in which acomponent supplier fails to meet its commitments, compelling the company to seekalternatives.

Documentation in itself also possesses features of a SOC; e.g. misspelling or a typographicalerror in one document may cause a chain of others to be revised. This may sound like redtape, but we must keep in mind that very often the implementation is triggered by a givendocument. Documentation also plays an important role in quality systems and may havesignificant 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 correctiveactions. For this we have introduced a new term: germ, which is something that isunintentionally designed into the object and remains undetected until the object meets aparticular 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 withrespect 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 non-fulfilment of a specified requirement. This covers the departure or absence of one or morequality characteristics. 'Potential' means that the nonconformity is possible only when thenecessary conditions exist. This infers that, at its point of origin, the germ is not anonconformity and perhaps may never be, unless the conditions in object's later life phasesturn unfavourable.

Second, we use dispositional approach, as presented in [3]: "By disposition we understandthat 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 wemay make a decision which carries a germ, affecting the progress of activities later in theprocess, 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 majorsources 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 customerneeds to factory tests. Between the performance of these activities, information is stored,transformed and distributed through contact surfaces, which serve as potential points fororigination. A process can be seen as an information cycle, in which the output of eachactivity adds to the volume of object information, accumulating every time the main processis performed (see Fig. 2). In this system a germ may originate and progress as part of theoperand to the next round.

Designer

Designing is a human activity, and the way the designer performs his work reflects all aspectsof life. Despite systematic design practices there is always room for biased thinking,misunderstanding, missing motivation or even casual obstinacy. When solving complexdesign problems under time pressure, the designer is inclined to accept the first workingsolution without striving to find one that is more optimal. Even if the work is reviewed andchecked, 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-enthusiasmare often prone to haste. They may find drawings with a perfect solution to a technicalproblem, but cannot understand the original premise for that particular solution, which makesits 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 receivedand must be given preferential treatment. Unforeseen requirements may lead to radicalchanges in sales configuration and to project-related designing.

Product information

Maintaining a dynamic product-family means managing a large variety at a high rate ofchange [6]. The variety is based on different configurations, which are realised by means ofstandard modules. Continuous product improvement results in an extensive revision program,which comprises a myriad of drawings and bills of material. Rushed sales orders causesudden overloads in the design office.

Project-specific applications are realised by joining adaptive modules or non-modules withstandard modules. A strong connection between their interfaces may result in some degree ofincompatibility 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 workindependently or together with others, making their identification difficult. Certainmechanisms can apply to only one product variant, covering its all life phases while otherswork across the whole product-family. These features describe the germ's nature as a changecarrier: originating during the delivery process, it is a considerable internal SOC in a fast-moving environment, where the conditions are changing frequently.

The behavioural mechanisms are presented in the following list. The numbers refer to thelegend listed in Fig. 2.

1. Retracing. The germ originates somewhere in the process. It is perceived in a later lifephase. In searching for its origin it is retraced from one life phase to another. Much timeand 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 germappears in a similar form in life phase N+k.

3. Hereditary. A particular solution made in the product development is introduced incommercial applications; e.g. mapping of functions into physical modules. This maycause 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 forcorrective actions later. Meanwhile the new design is reused somewhere else, includingthe original germs. This occurs especially when details of existing drawings are copied tonew drawings.

6. Contagious. A germ that is perceived in and corrected for a particular product variantcreates 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, foreach origin there is more than one mechanism. Second, for retracing germ there are fourorigins 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. Jobrotation in the workshop is recommended to extend designers' knowledge on efficientlogistics and manufacturing technologies.

2. Process. It is important to find a balance between hard and soft control [6], to developdesign rules, and to encourage people to engage in systematic feedback andcommunication.

342 ICED01-C586/087

3. Order information. Although flexibility is important, standard configurations shouldprimarily be offered. This is also the aim of sales configuration development. On the otherhand, we recommend the structured sales process [7], which ensures that all customerneeds 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, andlogistical interchangeability of components widens their applicability. Weak connectionsbetween 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 thechanges into two main categories according to their implementation process: 1) those wherethe company has discretionary power and 2) mandatory changes.

Processing the changes of category 1 typically consists of two phases. First, we have to judgethe necessity of the change, i.e. consider whether to do it or not. At this phase we compare thecost-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 theimpact on the logistical chain, particularly on the availability of the revised material forordered products. At the same time we have to decide what to do with the material of olderversions, 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 orregulations coming outside the company. Some of these mandatory changes have a transitionperiod, which makes them essentially easier to implement. Non-conformities must becorrected promptly. The same applies to construction changes, which may, if leftunimplemented, cause a risk of failure. The object of change may range from particularproduct variants up to the entire product-family. Customer requests are negotiable and thechanges apply usually only to particular product entities.

An experienced designer can contribute to logistical interchangeability when makingdecisions on the types of materials and component specifications. At the same time he canestimate whether to make or buy and finally, how his decisions affect the inventory. Thesequestions 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 deliveryprocess of a manufacturing company. Changes come from both outside and inside thecompany. The external sources of change can be managed proactively. Most changes,however, originate in the internal processes. We introduced a new term - a germ - whichmeans a hidden flaw in the object. It originates in the process and carries a flow of changesthrough seven different mechanisms. Process development is suggested to focus to the originsof germs for their better control. The logistical arguments are important in implementing thechanges.

Finally, we point out that change per se is not negative - on the contrary, it indicates thedynamic nature of our world and allows for industrial companies to prove their commitmentto a continuous product improvement, both in terms of quality and of environmental-friendliness.

References

[1] Wartsila Corporation: "Power Divisions". Available at <http://www.wartsila.com>.

[2] Kotler, Philip: "Marketing Management. Analysis, Planning, Implementation, AndControl." Seventh Edition. Prentice-Hall International Editions. Eaglewood Cliffs, NewJersey. 1991. ISBN 0-13-563479-2.

[3] Olesen, J.: "Concurrent Development In Manufacturing - Based On DispositionalMechanisms". Ph.D. Thesis from the Integrated Production Systems. Institute forEngineering Design, Technical University of Denmark, 1992. Publication IK.92.116-A.ISBN:87-89867-12-2.

[4] ISO 8402:1994 (E/F/R): "Quality Management and Quality Assurance - Vocabulary".2nd Edition.

[5] Hubka, V. - Eder, W.E.: "Design Science. Introduction to the Needs, Scope, AndOrganization of Engineering Design Knowledge". Springer-Verlag. Berlin- Heidelberg-New York. 1996. ISBN 3-540-19997-7.

[6] Sanderson, Susan W. - Uzumeri, M.: "The Innovation Imperative. Strategies for Man-aging Product Models and Families". Irwin Professional Publishing. Chicago. 1997.

[7] Suistoranta, S.: "Structured Sales Process for Configuration". Proceedings of the 5th

WDK Workshop on Product Structuring. February 7-8, 2000. Tampere University ofTechnology, Finland. (In print).

Seppo SuistorantaWartsila Finland Oy Turku FactoryStalarminkatu 45, FIN-20810 TurkuTel. +358(0)107093097Fax +358(0)107093169E-Mail: seppo.suistoranta@wartsila.com

©IMechE2001

344 ICED01-C586/087

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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

1 Introduction

The timely introduction of new products to market is a critical factor in determining theircommercial 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 theidentification of possible alternative plans, their comparison, and the selection of the mostappropriate. The model, which provides planning guidance for designers, is to be incorporatedinto a tool that aids decision making in scheduling, thus enabling design processimprovement.

Difficulties arise in the introduction of new products because of the complexity of the designprocess. Unlike other processes, in the design process the state of the product after each stagecan not be predicted. This frequently leads to iteration. Many design tasks are undertaken toprovide information about the fulfilment of requirements and their outcome has a directimpact on the subsequent direction of the design process. Very often, these outcomes force re-design and re-testing. Development plans (sequences of tasks) are thus bound to change, andschedules (resource allocation timetables) are affected in the process. Scheduling is alsoaffected 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 taskprecedence. This is equivalent to assuming that activities have predictable outcomes and canimply that there is no iteration. This simplifies the model, but at the same time requires thedescription of the process components in terms of their relation to the process as a whole. Forexample, in a PERT diagram, a task is described in terms of the tasks it depends upon and thetasks that depend upon it. This means that changes in the model or unexpected situationsrequire revision of the task descriptions, and therefore render the original model unreliable.

Exploring and evaluating possible design processes leads to some problems. The necessarydefinition of starting points, components of the design process, goals and measures forevaluation is not trivial [1]. The model proposed in this paper separates the description of thecomponents of the process from the process itself. The components are then actions thatproduce changes in the state of the design process. Their potential outcomes depend on thestate of the design when the action is performed and, in this way, the states put the actions intocontext. The current state can be determined at any point in the process, potential future statescan be identified, and plans are made by choosing sequences of tasks according to thecomparative benefit they offer.

ICED01-C586/073 345

2 Using the state of the design for process planning

Design can be seen as a series of tasks that are scheduled following precedence relationsbetween 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 isrefined by performing certain actions [3]. This process continues until the design object isconsidered sufficiently refined. Merging both ideas, a state (described as the refinement of thedesign object) is repeatedly modified by performing actions (design tasks), until a desired finalstate 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 usefulrepresentation for highlighting ways to produce complex changes within a system [4]. (In thisarticle, in the context of state transitions, the term action is used instead of task, following theusual practice in the literature on the topic.)

Our approach to design process planning derived from earlier work on Signposting, a processcapture and planning technique which has been successfully applied to a number of designproblems [5]. However, the use of Signposting has been limited to identifying only the nextstep at any stage of the process. Following a review of the Signposting technique and furtherobservation of industrial design practice, a revised state-action model has been developedwhich allows the identification and evaluation of alternative design routes.

This new model is being incorporated in a software tool including uncertainty modelling andscheduling techniques. It supports the construction of a more flexible plan, using a state-actionmodel, which is described by means of an example in the next section.

3 A state-action model of design

The details of the state-action model are now described with reference to the design of aventing valve. A group of designers at the Technische Universitat Miinchen successfullyredesigned the valve, and its associated assembly line, in order to resolve a number ofoperational problems. The model presented here was built using the experience they gained inthe process.

3.1 State description

To represent the state of the design, the design object is divided into parameters that can beseparately evaluated. These parameters may be components, dimensions, materials,performance parameters, or any other characteristic of the product that is addressed by thedesign process. The choice of parameters and their levels of detail is critical for the success ofthe model. It must be simple enough to be easily understood and used by the designers, whilestill being sufficiently rich to be able to express the situation of the design process in a usefulway for the tool. In the case of the valve, the design was divided by components on the onehand, and by stages of development on the other. This resulted in 27 parameters, shown inFigure 1.

The state of the design is represented as the refinement of the parameters that describe theproduct, or more accurately, the confidence that the designer has on the suitability of each ofthe 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 designerscan readily estimate how far are they from reaching it, and the result of that estimation is whatwe call confidence. In the example, the designers do not really know whether the VALVECONCEPTS 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 threeimportant properties:

• It can be derived at any point during the design process. It is clear that designers can takethe list of parameters and assign sensible confidence values to each one, and that it willshow a profile of the completeness of the process. For example, they can readily indicate ifthey 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 thedesigner has a high confidence in all the prototypes (VALVE PROTOTYPE, GRIPPERPROTOTYPE, ASSEMBLY LINE PROTOTYPE, and SO on).

• Tasks can be described as changes in confidences of parameters. Each task produces achange in one or more of the design parameters; otherwise, it would not be relevant to theprocess.

The cases previously studied have proved the use of confidence to describe states and tasks tobe 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 theirinput 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, anddescribing them as exhaustive pairs of possible inputs and resulting outputs would beunnecessarily demanding. Therefore, an option is to generalise the input-output pairs by usingrules 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 ofconfidence will remain unchanged if the task is performed; but if they do have them, at leastone of the confidences will improve and a new state will be reached. The basic description ofthe tasks is thus made by indicating the minimum confidences needed in the parametersrequired to execute the tasks, and the potential increases of confidence. For example, the taskdetail design of gripper (illustrated in figure 2) requires a medium confidence in the GRIPPERDESIGN and high confidences in the GRIPPER REQUIREMENTS, VALVE DESIGN, VALVEREQUIREMENTS, and WORKSHOP REQUIREMENTS. If the detail design is successful, theconfidence 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. Forexample, if some technical problems were encountered when doing the detail design ofgripper 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 onlywhat 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 stateof the design at any point, and the tasks that can advance the design are selected. The taskrepresentation identifies then the state that can potentially result from performing the task. Inthis 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 byfinding the tasks that can be performed given the current state, the states that can berespectively obtained, the tasks that could be used from these new states, and so on. Fordesign planning, it is possible to estimate in this way the possible sequences of tasks andstates that would lead to the conclusion of the design.

For example, suppose that in the current state of the design, the designer has mediumconfidence 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, taskdetail design valve can be done in the current state, and has the potential to produce therequired refinement. Both tasks can thus be done in a sequence, provided that the detail designof 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 tasksgive 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 thecombinatorial complexity of such a set of sequences, it is better to take advantage of the factthat most states can be reached through several different task sequences. The search space canthus 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 tasksemerging from different states can converge to the same state. (A good way of showing a statenet 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 usefulcomparison of the task sequences. The risk associated with executing each task needs to beconsidered at every stage of the process. In particular, the impact of the alternative outcomesof each task, and the different effects they can have, must be evaluated with respect to theirposition in the task sequence.

3.4 Choosing the next action

Effective design process planning involves identification of appropriate actions to take giventhe requirements of the design. Actions are preferred when they are more likely to result inlower commercial risk and maximum long-term profit, and ultimately in a more successfulproduct. Time management is critical in design since commercial risk is directly affected bythe time taken to design the product [7]. Hence, by choosing the best plan to minimise theexpected duration and costs, commercial risk can be reduced.

Alternative plans can be compared by treating the state-action model of the design process asa Markov decision chain when choosing which task is best to perform next. Markov chainshave 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 failto capture some important aspects relating to the complexity of the design process, such as thedesigner'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 statetransitions, which can be used to compare the different possible task sequences. This net hasthe same nodes as the optimist task sequence, but these nodes are also joined by linksrepresenting 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 areunidirectional, as in the optimistic case, and may represent increases or decreases in theparameter confidences.

This enhanced state-action model is an example of a Markov decision model. At each statethere is a choice of actions (the tasks that fit the state), and these actions can have differentoutcomes. Actions have also a cost that accumulates as the process develops, until a finalstable 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 duringplanning, 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 agiven state to a final state. This evaluation considers the possible actions that can be done atevery state, their costs and possible outcomes (including decreases in confidence). The bestpolicy, which describes the best possible actions for every state, is found in parallel with thisevaluation.

The algorithms used to evaluate the Markov decision net are standard and can be found intextbooks on the topic. The problem is that even though the number of iterations needed tosolve a typical model of the design process is low (two or three using a policy iterationalgorithm), the evaluation in each step has combinatorial complexity, and becomescomputationally infeasible with large problems. This can be overcome by pre-processing thenet to simplify it. This is done by detecting the pairs of tasks whose ordering affects the totalrework, and using the Markov net to decide on the ordering of these pairs only, while ignoringthe 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 itscomputation with the iterative algorithms becomes possible.

At the end of the analysis, the dynamic plan that is obtained takes the form of a policy, inwhich the best actions are identified for each design state. The optimistic task sequences thatfollow the policy stay as conventional plans, indicating likely routes that can be taken tocomplete the design process. For dynamic process planning, though, the policy may be used asguide to what to do given the current situation. It is supported by an indication of theadditional 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 byproducing an optimistic task sequence net that shows only those tasks that belong to the bestpolicy. A preferred approach is to extract precedence rules from the model. They can be usedin 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, butbreaking them has a known cost or risk. Conflicts between precedence rules and schedulingconstraints can be solved by comparing the risks and taking the lowest risk route. This has theadvantage of including a measure of the expected process risk, which in turn can be used toplan for contingency.

In contrast with precedence dependencies, the precedence rules obtained with the model arenot obvious from the task descriptions or the process rationale. Precedence dependencies canbe easily identified by designers, as they derive the rationale of the process and even of thetask description. For instance, in the valve case it is clear that generate gripper conceptscannot be done before tasks generate valve concepts and define gripper requirements havebeen successfully completed. On the other hand, precedence rules like "detail design valveshould precede analyse assembly line" though justifiable and reasonable, are not obvious (seeTable 1 for more precedence rules). Breaking this rule would include the relatively expensiveanalysis of the assembly line in the rework loop of the valve design, causing 36 additionalhours of estimated rework. This is an increase of 5% of the total cost of the process. It istherefore in the interest of the project to avoid breaking this and other precedence rules. Theyshould be considered and traded-off with other conditions such as resource cost andavailability during scheduling.

350 ICED 01 – C586/073

Precedence rule

Detail design valve before Analyse assembly line

, Generate assemblyAnalyse valve before

concepts

Analyse assembly line before Analyse valve

Analyse assembly line before Pre-evaluate gripper

Generate assemblyDetail design valve before

concepts

Detail design assembly before Pre-evaluate gripper

Estimatedcost of

breaking rule

47.8 h

39.9 h

36.4 h

25.3 h

23.3 h

13.7 h

Percentage oftotal time

7.1 %

5.9 %

5.4 %

3.7 %

3.4 %

2.0 %

Table 1. Example precedence rules from the valve design model

4 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 underthis representation. On the other hand, regarding the planning strategies given by the tool witha populated model.

Models of different levels of complexity have been created, ranging between simple cases ofbicycle configuration and the mechanical design of a single component, to the conceptual anddetail design of a valve (as used in this paper). Currently, a model of the design process for anautomotive powertrain is being constructed with the assistance of Lotus Cars. In all of thesecases, the division of the product into parameters proved to be the most critical part of themodel elicitation. The idea of defining the parameter refinement needed to perform a task, andits potential outcomes, seems to be quite natural for the designers involved in building thesemodels.

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 onit. In the valve case exposed, following some of the rules can produce improvements in theorder of 5-10% of the total time of the project, which make the analysis worthwhile.

5 Conclusion

A design process model that considers the state of the design, using the designer's perceptionof the refinement of the design, has been described. The structure of the model is simple, butallows sophisticated analysis of the process structure, to provide useful insight and guidancefor dynamic planning. A measure of the progress of the design process may be obtained, andadvice, 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 thatmodels 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 andrefinement of the design process representation.

Acknowledgements

The authors would like to acknowledge the help of the design group of the TechnischeUniversitat Munchen, and in particular of Ludwig Schwankl, in providing information aboutthe valve design and participating in building its model.

References

[1] Westerberg, A W, Subrahmanian, E, Reich, Y, Konda, S et al. (1997), "Designing theprocess design process," Computers & Chemical Engineering. 21:pp S1-S9.

[2] Steward, D V (1981), "The design structure matrix: A method for managing the designof complex systems," IEEE Transactions on Engineering Management, EM-28(3):pp71-74.

[3] Ullman, D G, Dietterich, T G and Stauffer, L A (1988), "A model of the mechanicaldesign process based on empirical data," AI EDAM. 2(1): pp33-52.

[4] Fikes R E and Nilsson, N J (1971), "STRIPS: A new approach to the application oftheorem proving to theorem solving," Artificial Intelligence. 2:ppl89-208.

[5] 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.

[6] Clarkson, P J, Melo, A F and Eckert, C M (2001), "Visualisation techniques to assistdesign process planning, " Proceedings of ICED 2001.

[7] DTI (1994), "Successful Product development." Department of Trade and Industry,HMSO.

[8] Eppinger, S E, Whitney, D E, Smith, R and Gebala, D (1994), "A Model-based Methodfor Organising Tasks in Product Development," Research in Engineering Design. 6(1):ppl-13.

[9] Carrascosa, M, Eppinger, S E and Whitney, D E (1998), "Using the Design StructureMatrix to Estimate Product Development Time," in Proceedings of the ASME DesignEngineering Technical Conferences. Atlanta, GA, 13-16 September

Andres F MeloEngineering Design CentreUniversity of CambridgeTrumpington StreetCambridge CB2 1PZUnited KingdomPhone: +44 (0) 1223 332 376Fax: +44 (0) 1223 332 662E-mail: afm27@eng.cam.ac.uk

© Cambridge Engineering Design Centre 2001

352 ICED 01 – C586/073

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

INTEGRATED NEW PRODUCT DEVELOPMENT - A CASE-BASEDAPPROACH

R Valkenburg and J Buijs

Keywords: Design reams, systematic product development, concurrent engineering, empiricalstudy, design education.

1 Introduction

Nowadays we should know how to develop good products; enough theories and methods havebeen developed to support new product development. Many product development modelshave been introduced over the years [1, 2, 3, 4, 5]. The developers of such models werepeople with a lot of practical and/or industrial experience. Although they have not made theirexperience 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 dailypractice is much more complex and as a result few practitioners recognise their activities inthese theories and models. Most 'model builders' of the NPD-process had an engineeringbackground, and as engineers they were used to building and using abstract models to producereal artefacts. They were also used to working in highly compartmentalised companies.Companies with an R&D department for the development of new technology, a designdepartment to translate this technology into a new product, an engineering department totransfer this new product in something to be manufactured, a manufacturing department toproduce the product and ship it to the customers, and finally a marketing department to try tosell the product to the customers. Deep down in their hearts the 'model builders' thought thatthis well-designed new product was of course instantly loved by their intended customers, andthat marketing was not really necessary. They 'sold' their models of the NPD-process in moreor less the same manner. They threw it over the wall to the 'users' and expected, not only thatthese users would be able to understand the model, but that they would use the model as theyintended.

Models, however, are always an abstraction from reality. The fact that NPD-processes can bedivided into separate steps or phases is also usual in daily practice. Managing the developingdesign content within these phases, or dealing with iterations is also common practice, buthardly ever dealt with in the theoretical models. In daily practice the design task is not clear orobjectively stated. Rather, the product developer has to deal with conflicting interests and toconsider contradictory demands. The product developer hardly ever works individuallyanymore; he is a member of a product development team, together with members from otherdepartments in the company, such as marketing, production, purchasing, or (from outside thecompany) suppliers and potential clients. This 'know-how' led to more refinement of themodels, which usually meant more stages, more definitions and more abstract terminology. Inshort 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 modelsand were well aware of the limitations and constraints, as soon as these models wereintroduced in education these models became goals in themselves. Many of the engineeringteachers left practice a long time ago and models of NPD became more important than thepractice of NPD.

We are also taught about these abstract models at university and were never taught aboutimplementing these models in real life. By applying these models to practice (and also by trialand error) we have discovered an urgent need in real life for simpler, more application-oriented models. In short there is a need for a more realistic approach towards NPD, not justoffering a stage-gate model, but also guidelines to implement it in real life situations.

2 Learning from case study material

Since 1976 we have collected case study material on NPD projects. At first these descriptionsoffered a broad view of NPD [6]. Later, data were collected for research on innovation, whichled to 120 case histories [7]. Since 1992 we systematically collect detailed case studies for usein education [8, 9].

1. Some products from our case histories: a package design for a homoeopathic medicine by Claessens ProductConsultants, a range of cosmetic organisers by Curver (producer of synthetic household products), a trafficsign 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-operationwith 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 historiespresented here provide a load of information on NPD-projects within companies. Projectsvaried 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 companiesor multinationals (e.g. DAF Trucks N.V., The Dutch Railways, Oce). Products varied fromrelatively simple consumer goods (by Curver), to complex technical systems (by The DutchRailways). For all case descriptions we interviewed at least four participating practitioners,representing project management, product development, marketing and engineering. Figure 1shows an overview of some of these products. The analysis of these case histories revealscharacteristics 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 publictransportation 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 theirstrategy and product development. Functionalities such as printing and scanning came closeto the original 'photocopying', which allowed new, multi-functional products. Besides this,the application of digital technology implies software, which makes the development ofsoftware applications as important as the development of hardware.

These examples indicate that product development is not an isolated activity. It is an activitythat 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 andcorporate strategy is crucial; the company must indicate the role of the newly developedproduct 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 caremarket. Until then such a device didn't exist. So the design of such a device would be totallynew. Nira choose to collaborate with a design firm, Well Design Associates, to fill the gaps intheir knowledge.

At DAF Trucks a lot of attention was paid to setting the aims for the NPD-project. DAFTrucks knew the importance of thinking before a project starts. In the 'definition phase' DAFTrucks extensively investigated what the new product should be like and a business case andfeasibility study were performed before the 'real' NPD project starts. In this way they try toavoid unnecessary iteration later in the project development.

These examples indicate that besides the role of the product in the company's strategy, thecompany must also have a clear view of what they want with the product, and what the NPD-project aims for. What are the strategic strengths that are built on with this project? Whatadvantages 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 Trucksa 'core team, compiled from different disciplines is given responsibility for the end result. Themembers of this 'core team' involve people from other departments or even suppliers andcustomers, if they think suitable.

At Oce team work is implemented one step further; all participants of the project, which canhave over a hundred people, are co-located. Oce has even built a special building for thispurpose, 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, butappointed to projects fulltime.

NPD being an integrated activity implies that diverse areas of knowledge are needed in NPDprojects. This means an integration of disciplines; integrated NPD implies teamwork andrevolves around people.

2.4 External orientation

DAF spends a lot of time finding out the needs of the customer. This occurs by continuousmarket analysis and interviews with drivers and distributors, which sustains new truckdesigns. Before the project for a heavy-load truck started, over 1700 interviews had takenplace with customers, truck drivers and 'non-drivers'.

In the development of cosmetic organisers for small girls, Curver paid a lot of attention tocustomer 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 toinvestigate the feasibility of the product, as well as to collect the target group's wishes for theproduct. Later on in the project Curver performed concept tests to check the product'sfunctionality, colours, expected distribution and prices.

Knowing what products to develop requires the company to be alert to developments in itsenvironment. An innovative organisation can effectively deal with changes in thisenvironment, such as activities of competitors, suppliers and customers, but also the users ofits products. Besides identifying threats from the environment, it is even more important tocreate 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 participationwithin 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 theprocess and procedures is important. In the collaboration between Nira and Well DesignAssociates, 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 andmanagement problems. By using a systematic method, the process can be structured and theparticipants 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 allparticipants agreed on the same language.

The NPD-process in all cases follows more or less the same stages. Of course, for differentproducts and different companies, the emphasis within the processes differs, but milestoneslike 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 toachieve the required quality on time and within budget, participants have to be motivated andproperly 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 allneeds and requirements, related to the new double decker trains. At the same time they triedto focus thoughts on the concepts of interior and exterior design, so later in the projecteveryone would know why decisions were made.

Nira and Well Design Associates used a creativity session at the beginning of the NPD projectto clarify the points of departure. By defining the aims of the project everyone was able toperform their own part within the project (i.e. the development of the software or thehardware) separately.

Too often creativity is associated with 'weirdness', artists, or as a trick. The case descriptionsindicate that it is especially creativity that should be integrated systematically within the NPDprocess. It is certainly useful in the creative phases of projects, such as idea or conceptgeneration, but it is also useful in the orientation of problem areas, and selecting or detailingideas. Dealing with creativity within a company and stimulating the creative behaviour ofemployees is too often ignored.

3 Ingredients of integrated new product development

Studying NPD projects provides insights, which are of importance for successful new productdevelopment. Few existing models address the integration of corporate strategy and productdevelopment, integration of knowledge from all the different disciplines involved in productdevelopment and integration of process steps and the management of the quality of the designcontent within these steps. We have developed an approach that addresses these areas ofintegration [10].

In our view, integrated new product development is a combination of methodological stepsand a way of organising and managing these steps within a dynamic business context. Wehave introduced a stage-gate model that describes four different stages in the new productdevelopment process. In the first stage, 'strategy finding', the strategic direction for thecompany 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 thirdstage, '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 shouldbe 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 modelitself. The organisation and management of this approach in a dynamic business context mustbe aimed at optimisation of the integration of knowledge. We introduce a multi-functionalteam approach to new product development, and describe how teams can deal with thiscomplex task. Such a multi-functional team is responsible for the integration of knowledgethat is needed in the product development process. We also describe other features of theapproach, such as the importance of creativity within the process, and the role of the projectleader in the project.

Both basic elements of integrated new product development - the stage-gate model and themanagement 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 themost 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 andNPD-managers want simple models in colloquial language, which are easy to communicatewith the members of the multi-disciplinary NPD-team.

We looked at numerous models of the NPD-process. NPD-Literature distinguishes fivedifferent 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 amodel with the least stages which was as integrated as possible. We came up with a four stagemodel based on the experiential learning model of Kolb [12]. Each of the four stages is aimedat one important goal of the NPD-process. The first stage, 'strategy finding', is aimed atfinding the strategic goals of the particular NPD-project. This strategic direction is describedin search areas. In the second stage, "goal finding', this strategic direction is translated intothe design brief, the specific assignment for the NPD-project team. The result of this stage isthe design objective. In the third stage, 'product finding', this assignment is executed and thenew product is designed, engineered and tested. The result is the new product. In the fourthstage, 'implementation', the new product is introduced on the market and is used by itsintended customers.

358 ICED 01 – C586/137

In the strategic steps we suggest a balance between the internal and external orientation of thecompany. The company should look at its external context; should know what its customerswant and what the competition is up to, in order to know that new future business will besuccessful. However, the company should also know its internal strengths and weaknesses tofirmly base these new businesses.

In all stages we distinguish between three streams of information. One based on thecompanies internal strengths and weaknesses and one on the external opportunities andthreads. The third stream is the actual NPD-stream in which these two different flows ofinformation are integrated into the new product to be developed.

In the product development oriented steps we suggest integration of the different orientationsthat 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 inputfrom 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 usethem are useless. So in our approach organising and managing the people in the NPD-processis as important as the model chosen. We suggest a multi-disciplinary team approach. We callthis the Multi-X-approach because maximum diversity of knowledge and insights stimulatesthe 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. Ofcourse, at the same moment you want the smallest team possible. Management in general, butNPD-management in particular is about dealing with dilemmas!

The Multi-X team itself is not enough. You have to integrate knowledge from groupdynamics and organisational development into the approach. If you do not allow time, spaceand resources for teambuilding, the Multi-X -team will never work. Teamwork requires socialinteraction and communication of the team members. This implies the challenge tosynchronise their thoughts and activities to achieve a design: communication on the contentrelated aspects of the new product development task. It is the project manager's responsibilityto achieve good communication in these difficult situations [13]. The role of the NPD-projectleader is shifting from leadership to facilitator. But in contrast to the well known idea of thefacilitator as content independent our cases and parallel research show that the NPD-projectleader should be an expert not only in the NPD-process but also in the content of theparticular new product itself. This makes the role of the NPD-project leader very complexindeed.

4. Conclusion

Thanks to our research in a large number of companies, which resulted in series of detailedcases, we were able to expand the traditional NPD-approach. From its narrow basedengineering type of abstract modelling, to a more integrated and concrete approach in which asimple NPD-model is combined with a way of working with the model. These additions arethe multi-X-team, a project management system and applying creativity. It is this multi-disciplinary NPD-team which uses the model creatively as a basis for their projectmanagement of the NPD-process.

ICED 01 – C586/137 359

We asked the participating companies to give us feed back on our case descriptions. Thisclosing our learning loop showed us that our case based approach is more realistic than thetraditional way of describing the NPD-process.

References

[1] Andreasen, M.M. and Hein, L., "Integrated Product Development". Heidelberg, Bedfor,UK/Berlin, 1985.

[2] Pahl, G. and Beitz, W., "Engineering design". The Design Council, London, 1986.

[3] Cross, N.G., ''Engineering design methods". Wiley, Chichester, 1994.

[4] Roozenburg, N.F.M. and Eekels, E., "Product design: fundamentals and methods".Wiley, Chichester, 1995.

[5] Ulrich, K.T. and Eppinger, S.T., ''Product Design and Development". McGraw-Hill,New York, 1995.

[6] Buijs, J.A., "Strategic planning and product innovation - some systematic approaches",Long Range Planning, vol. 12, nr. 5, 1979.

[7] Buijs, J.A., "Innovation can be taught", Research Policy, vol. 16, pp. 303-314, 1987.

[8] Buijs, J. and Valkenburg, R., "Integrale produktontwikkeling". Lemma, Utrecht, 1996.

[9] 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 innovationprocess". R & D Management, vol 14. nr. 1, 1984.

[12] [12] Kolb, D.A., "Experiential learning; experience as the source of learning anddevelopment". New Jersey: Prentice Hall, 1984.

[13] Valkenburg, R.C., "The Reflective Practice in product design teams", PhD Thesis, DelftUniversity of Technology, 2000.

Dr. ir. Rianne Valkenburg and Prof. dr. ir. Jan BuijsDelft University of Technology, School of Industrial Design Engineering, Department ofProduct 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 DESIGNICED 01 GLASGOW, AUGUST 21–23, 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 andvarnishes

1 Introduction

This article considers the role of material instrumentation in the dynamic of innovation andinter trade cooperation. Within a competitive context, innovation and management ofknowledge is an increasing preoccupation in the conception of products. Several actors takepart in the product design process. We can quote the designers, the technologists and themarketers: so much competence but different visions. In a first part, we would try to showhow material instrumentation can stimulate inter trade cooperation. Then, through anexperiment, we would try to show in what material instrumentation can favour innovation.

2 Inter trade cooperation

We gather under the expression " material instrumentation " all the interfaces and physicalintermediaries used in the product design process: numerical sketches, plans, instruments,schedule of conditions, models . . . Synonyms of time saving, they have as main vocation, thetotal or partial realization of the product.Through our experiments, we realized that the use of such instruments supports "a companymemory", exchange of the various points of view and communications between the differentactors during the design process. Actually, they transform ideas, knowledge, know-how andcompetence into tangible objects. " These knowledge can result from internal sources(designers memory) or from external sources (documents concerning objects conceived firstby the designer or a third" [1]The existence of these physical intermediaries allows to leave a trace of the company'sknow-how. Thus, they generate a memory and allow the re-use of knowledge and ideascrossed in a new context and through new company actors. They can thus take over " theintentions " which gave birth to the various intermediaries. " The formalization of the variousactors points of view via symbols facilitates the construction of a shared sense and enrichesexchanges. 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 andmake visible the actors decisions and, give catches to the others ". [2]Furthermore, material instrumentation provokes reactions. It allows the projection of the ownknowledge on a tool which crystallizes the various points of view.Besides the problems of respective vocabularies, it is not rare to meet communicationdifficulties among the different actors. It is not easy to change the point of view. Nowmaterial instrumentation allows scoring and clarify each actor's visuals and this precipitatetheir 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 toact of coherent way and to play the set of its advantages. [3]Continuous modeling of actor representations and intermediate materialization within aproject of conception returns more explicit action for the others. The creation of a specificphysical support clarifies the actions of the various trades and returns so more effectivecooperation. The use of these representations and realizations generates strong components ofcollective training. The set of intermediate successive realizations allows the development ofa progressive common project representation by developing its own knowledge.This reflection is illustrated by a visual and tactile inter trade communication support toencourage 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 animportant cultural deficit on the characterization of the objective visual and tactile propertiesof a building material and of its finishing, which makes difficult communication between thevarious 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 manyproducts. Therefore visual and tactile contribution becomes a strategic tool of location anddifferentiation. It becomes essential to propose to the various concerned actors a support toimprove understanding between the various actors to avoid errors of conception due todifferent interpretations.

3.1 Context

Stylistic innovation became an essential factor of competitiveness on markets general publicas different as telephony, car design, cosmetic, or household electrical appliance. Materialaspects play a dominating and increasing role.For the manufacturer, visual and tactile dimension became an effective means for consumerseduction and the differentiation of the products which bring value in the product.Various processes of transformation of material, surface treatment and decoration allow to acton this finish. In the first rank of which is situated, in number of applications, the painting andvarnish technology.Three major actors take part in the conception of product aspects : the designers, themarketers 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 metarise from different sectors (design packaging and product, car sector, sensory metrology ofcar manufacturer, paintings and varnishes applicators . . .).So,we were able to identify the fields of mastery of the various actors (table 1).

Table 1 Actor's control fields

Designers

Marketers

Technologists

DefinitionsDefine the visual and tactilecharacteristics of the finishing

Advise and sell finishingWork out the formulas of paints andvarnishes

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 paintingwhich gives an impression of leather " .The technologist chooses technical vocabularyrelating to the chemical constituents, concerning the elaboration of the finish (formulation) orthe application. " I seek a finish of tint X having a touch leather and applied by automaticpulverizing ".The marketer uses vocabulary focused on the consumer expectations , accordingto his interlocutor.This variety of vocabulary is frequently source of conflicts and ambiguities, pulling numerousconsequences : problems when designing products (identification, decision), problems whendeveloping (paintings and varnishes formulation), problems when producing (serialapplications not corresponding to the reference standard).

3.3Tool presentation

For this inter trade cooperation tool realization, we leaned on the method of multi-fieldconception developed within the laboratory ENSAM, Paris. We shall not develop [6] thispoint, it is not the purpose of this articleWe have, at first realized a state of the visual and tactile art of paintings and varnishestechnology by collecting, with formulators and applicators, representative samples of thevarious 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 looseand to confirm a first list of visual and tactile families. This list turns out necessary for ourtool conception and the sensory metrology work, used to characterize the visual and tactilefamilies.

ICED 01 – C586/572 363

The sensory metrology purpose is to describe objectively visual and tactile characteristics ofthe 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 varioususers : it is not especially a question of conceiving the same support for all. It is important thatit adapts itself to all the implied corporate actors and that the various users can communicatewith and through him.It is also very important to consider how the various actors work and how they communicatewithin the tool development. That is why we met different users, coming from differentsectors (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 whichwe 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 supportshould 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 theways of development.

So the visual and tactile support becomes at the same moment a support of inter tradecooperation and a technological watch tool. The examples of exploitation of the support arenumerous 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 variousformulation and application parameters, ingredients and processes).Meetings, associated tothe need and functional analysis allowed us to write a list of indispensable elements whichhave 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 anorganization of modules representing one by one the various visual and tactile families. Theuser can, at first constitute his tool of modules of his choice and develop it by completing itaccording to his needs. He can also feed it of virgin modules to personalize it, according to theindustrial sector for example.The shape of the visual and tactile tool favors confrontation among the three actors because itallows 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 ; themarketer can present and communicate finishes and the technologist finds there referencestandards and all the technical information to formulate and to compare finish applied withsamples. Moreover, the descriptors to which various samples are associated offer a system oflocation, which is the same for the various actors.Every actor can so use the "filter" which is convenient for him and can so understand theway 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 supportallowing the confrontation between the various actors. It offers also easier and more effectivecommunication. The points of view of the different actors converge on this tool. It is sopossible 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 theproduct conception realized by Herve Christofol [ 7 ] . This study uncorked in theimplementation of an inter trade cooperation tool intended for the designers, for the projectmanagers or for the decision-makers, helping them to understand the phenomenon of the colorand 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 aninnovation if it doesn't bring an advantage for the company, the person and the society. Inother terms, " To innovate, it is to take risks, to dash into the unknown, to go to meet theunpredictable ". [8]Innovation is also the capacity to cross of a new idea in marketable object and in a realizationof new combinations between various resources professions by the company [ 9 ]. Innovationis collectively admitted as having an individual birth. However, the reason to be is in thesharing. 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 necessarilyvoluntary [11]. Indeed, to obtain a gaining change, it is necessary to multiply exchanges enterthe 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 thedevelopment 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 combinationswithout constraints connected to the cost of these attempts. They give concrete expression tonew ideas until then little envisaged. Through the unpredictable association of newcombinations 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 thevarious actors.Our tool of inter trade cooperation is still in development and it remains completely openedand 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 productdesign process in order to avoid conception problems (due to the use of a same vocabularywhich doesn't mean the same thing for the different actors, for example) and to improvecommunication between the different actors.It is evident that this article presents in a concise way made work and that it is not the end initself. F. Daniellou explains that " competence is not passed on. If one considers them as thetrack 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 wedecided to create a tool encircling a ground of communication and enrichment : an interactiveinnovation 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 , 19Oct. 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 desfinitions; 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 lacoloration 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 fondeessur 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 lemecanisme des sens.- Thesis ENS AM, 1995 – 16093

[14] Edward T.Hall - La dimension cachee - essai, Edition du Seuil- 1966

Nadine STOELTZLEN, Dominique MILLET, Ameziane AOUSSATNew Product Design Lab. (Laboratoire Conception de Produits Nouveaux et Innovation)ENSAM (Ecole Nationale Superieure d'Arts et Metiers), Paris151 boulevard de 1'Hopital 75013 Paris, FranceTel: (+33) 01 44 24 63 80Fax : (+33) 01 44 24 63 59E-mail: nadine.stoeltzlen@paris.ensam.fr

© IMechE 2001

ICED 01 – C586/572 367

This page intentionally left blank

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

GEOMETRY USERS FROM A PROCESS PERSPECTIVE

F Fuxin

Keywords: Business process re-engineering, Change processes, Concurrent Engineering

1 Introduction

This paper describes the Process Domain, which constitutes one of the four domains thatform the Geometry Management Process (GMP). The main theme is to establish systematicmethods, processes and perspectives on Geometry Based Product Information (GBPI). Theresult will contribute to elimination of rework and to increased integration in the extendedenterprise [1]. The Function Domain and the Requirement Domain have been outlined ingreater detail in [2]. The fourth domain, the Realisation Domain, deals with ways of realisinggeometry representations, that is the tools for generating, packaging, and viewing. Figure 1outlines the structure of the GMP. The original hypothesis has been that it is possible todivide the GMP into four separate domains. The initial efforts were made in the function andrequirement domains. This publication deals with the process domain. The domain isintroduced in the following chapter. Next chapter presents the proposed process, both abroader perspective and in detail. The final chapter is conclusions.

Figure 1. The Geometry Management Process and relevant domains.

2 The process domain

The gradual transition from traditional towards digital product development will favour awell-established process for managing GBPI. The basis of the process domain relies onstudies of the evolution of geometric maturity through different stages of the productdevelopment process. All studies and surveys were conducted at the Volvo Truck Corporationin 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 ofthe obstacles to increased integration is that the various activities have to be carried outconcurrently. 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 bynew methods and procedures, will replace the physical master. In a company, there isnormally a top-down approach where a project plan prescribes different stages to be carriedout 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 acomponent, sub-assembly or module reached a level of detail (L.O.D.) where it supports allthe 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 theproject, 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 ConceptDevelopment, System-Level Design, Detail Design, Testing and Refinement and ProductRamp-up [3], The process proposed in this publication comes from application of ageometrical perspective on tasks, activities and co-operation in the development environment.It is motivated by the gradual transition from traditional towards digital product developmentand should not be considered as a stand-alone process but as a complement to existingbusiness 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 thosecomponents/modules that not are directly carried over from previous products. During a givenproject, 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 thedevelopment process is iterative during these stages [4]. The design engineer's knowledgeabout his/her new component/module grows when new problems are penetrated and solvedduring evolution towards a product that meets predefined specifications [5]. The variousactivities throughout this iterative sequence are decomposed and generic elements aresynthesised. The resulting activities, inputs and outputs are to be considered as genericconstituents that populate a generic process. A top-down approach is applied where animportant extra stage, preconceptual development, has been included, see figure 3. Thegrowing 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 adequateand accessible GBPI when generating assemble documentation, educational material, serviceinformation and marketing brochures. It should be pointed out that these users not areinterested 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 ondefinition 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 productdevelopment process should support and coordinate these activities. Almost all activities thatconstitute the major process have inputs, outputs and some controls/constraints that must befollowed. Furthermore, to realise the activity, appropriate resources and tools must exist.Inputs, outputs, control/constraints and resources/tools are fundamentals of IDEFO. They havebeen applied to the process domain. From the studies conducted, different factors thatinfluence 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 theprocess 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, thehierarchical position. The expression "carry-over" has thus far been used for components andassemblies carried over from earlier product projects. A redefinition of this expression ismade. The same signification is still valid but it may also denote geometrical input from anearlier activity together with geometrical interfaces for adjacent modules.

Resources and tools. Staff and functions that must be made available for fulfilling therefinement activities. Partners and suppliers are also to be considered as resources. Thenotation tools are the tools needed for realising the refinement activity. The range of toolsextends from modelling tools, via assembly and packaging tools to more simple viewers.

Controls and constraints. Strategies/rules and guidelines, for example demands oncommonality and modules, affect the refinement activities. Time plans are constraints thatmust be followed. Control of product and process documentation must be undertakencontinuously 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 thesubsequent activities mentioned have an obligation to provide a response. In earlier stages,this obligation may merely comprise simple viewing and communication of opinions, but thiscould 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 illustratesthe 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 initerations. Depending on the degree of the shortcoming, the iteration can be directed to theprevious activity or all the way back to preconceptual development, in the worst-casescenario. Each stage should refine its given L.O.D. to its next L.O.D. The refinementprocedure is more or less independent of the state to which it is applied. Thus, the refinementprocedure is subdivided into three chronological steps. Each step is described briefly.

Identification. Each stage, and each activity, receives some type of geometricalrepresentation 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 theobjective 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. Theassembly structure and physical functions must be optimised towards the stated objective ineach stage. In early stages it is of extra importance that these two are highlighted since therewill be no physical prototypes where optimisation of these structures and functions can beperformed. The focus will shift once the physical prototypes are introduced, and theseprototypes will serve as verification rigs where simulations must be validated.

Verification. Conclusions and verifications are always important when summing up currentstatus, especially when the same personnel do not perform forthcoming activities. Have therebeen changes from the initial geometrical prerequisites; will they affect stages and functionsdownstream? Are the physical functions verified? Is it possible to manufacture and assemblethese components and assemblies? The carry-over of components, assemblies and interfacesare verified and summed up here before being sent on to next stage.

Preconceptual development

Preconceptual development deals with compilation of relevant geometric information at earlystages before the actual development activities are initiated. The objective with this stage is toestablish geometrical preferences that are as unambiguous as possible. Some of therecommendations proposed will generate extra work during the earlier stages, in addition tothe extra effort that must be invested in summing up all the requirements. Eventually, theseextra 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 stronglyinfluence development and utilisation of GBPI. Product structure issues will be interpretedfrom different perspectives, such as modular/commonality and geometry users' perspectives.The matter of uncoupled development activities must be addressed during the preconceptualdevelopment phase. There are several reasons for conducting uncoupled development, forexample advanced engineering projects or other major systems with their own developmentcycles. Nevertheless, by properly introducing them at this stage, preparations can be made fortheir incorporation. The finalisation of the preconceptual development is completed when thedegree of refinement of the L.O.D. has reached envelope.

Identification. This geometrical input to the preconceptual development stage is composed ofcarry-over material. On top of these prerequisites, considerations must be given to variants ofthe future product and to requirements of geometry users who will participate in theforthcoming effort. In this context, carry-over material is regarded as either geometricalrepresentations from previous product projects, geometrical interfaces between differentmodules (or sub-modules/components) or modules originating from uncoupled developmentactivities. Identification of carry-over material is one of the primary objectives since it willserve as a reference for the space allocation of envelopes and decisions upon interfaces. Forcomponents and modules that are to be designed, these geometrical entities will serve asboundaries in the development work of each module. The product-planning department willspecify which variants are to be included in the project. The specified variants are generatedby a modular structure where commonality aspects are taken into consideration. The proposedmethod for categorisation of geometry users will add additional requirements to the productstructure. 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 andrework in downstream activities is reduced. The refinement procedure for the preconceptualdevelopment stage is synthesised in figure 5.

Figure 5. The preconceptual process procedures.

Optimisation. Preconceptual development does not primarily deal with physical function andassembly structures. However, since the geometrical definitions are carried out in theidentification procedures, it is feasible to undertake the first preliminary checks of physicalfunctions and assembly structure.

Verification. The output from preconceptual development is compiled here. Are the originalspecifications fulfilled? Is it possible to geometrically generate all variants in a systematicmanner? Will different categories of geometry users have access to relevant geometricalconfigurations? 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 whereimplementation 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 theproject. One such aspect concerns communication between companies and suppliers, orpartners, when there are different CAD systems [6]. Specifications should be made for neutralformats, and perhaps appropriate application protocols, for communication.

Conceptual Development

The primary objective of this stage is to evaluate several possible proposals and to reach afinal concept. The geometrical input to the conceptual stage is more rigid due to theintroduction of the preconceptual stage. For a specific module, the geometrical refinementactivities will depend on just how many carry-over parts can be used. The result is that someorganisational functions will have to start with an envelope with accompanyinginterface/interfaces. Other functions should concentrate on optimising an already existentconcept 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 adraft L.O.D. Since one or more design functions may not often be located in the samebuilding, 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 anddistributed engineering must rely on, and have access to, reliable GBPI.

Identification. The input to this stage consists of a mix of envelopes, interfaces and carry-over parts/modules. A module will always have one or many interfaces. This is valid for bothenvelopes and carry-over modules/parts. The first step towards finalising the concept is toagree upon the interfaces. Different modules are joined by interfaces and so too are theorganisational functions responsible for the modules. Interfaces are the physical connectionsto 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. Thegeometrical interfaces connect the different envelopes. All concepts generated will beevaluated against each other and against how well they fulfil the specification of the newproduct. The geometrical refinement activities depend on the amount of carry-over parts.Initially, organisational functions sharing an interface must ensure that the interface fulfils allconnection requirements. Once a mutual agreement on interfaces is established, the focus isturned to physical function and product structure requirements.

Optimisation. At this stage, preliminary evaluations must be conducted for the most credibleconcepts. Carry-over modules and parts have a well-founded geometrical basis from which tostart off. Concepts starting with an envelope will have to be further refined before evaluationscan be performed. The lack of physical prototypes implies that most decisions must be madefrom digital simulations and analyses. Even with low level of detail, it is today possible toperform extensive evaluations; e.g. technical calculation and motion/clearance analysis. Thisof course requires that the company has built up methods and procedures for supportingassessment during the early stages. Product design is one area where visualisation techniqueshave 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 beof 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 downstreamfunctions, 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, mostfunctions should have access to the draft L.O.D.

Management of variants and versions is extremely important. The more functions involved inrefinement activities, the greater the emphasis on this type of management. The digital masterreplaces the physical master, and that lasts for the entire product lifecycle. It must constitutethe master reference for all variants and versions.

Detailed design

The detailed design stage encompasses the fulfilment of the highest level of detail and in theend the introduction of physical prototypes. The gradual transformation of the GBPI, fromdraft to detailed L.O.D., is associated with rigorous efforts. The generation and distribution ofadequate geometry representations rely on competent management of the GBPI and the wayin which it should be made accessible to all personnel involved. The concept of digitalmasters must be clearly stated, communicated and utilised. The initial refinement activitiesmust focus on securing physical function and on ensuring that all suppliers are well informedabout the requirements concerning their components and systems. This is the prerequisite forthe first generation of physical prototypes. Critical areas and parameters detected fromprevious activities must be incorporated. There are several functions downstream of detaileddesign that have high requirements on the level of detail. Some of these functions are togenerate 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 co-ordination 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. Criticalparameters detected during optimisation and verification in the conceptual development stageare invaluable as input to the detailed stage. One example is critical clearances detectedduring motion analysis. There are several functions waiting for the level of detail to reachtheir set requirements. It is essential to identify when these requirements will be met at thisstage. This is necessary in order to be able to start up these activities as soon as possible. Anupdate 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 thoroughlyanalysed regarding physical function fulfilment.

Optimisation. GBPI must be optimised in several different aspects to reach detail L.O.D. It isnot until this stage that the utmost refinement can be performed. All radii, chamfers andtolerance zones should be optimised for low weight, tensile properties and cost. Packagingstudies, computational models, endurance simulations, manufacturing logistics, assemblyoperations, maintenance simulations - all these must in the end be performed on real physicalproducts. The physical prototypes that are built are thoroughly selected. The selection is basedon earlier experience and from critical specification detected in the conceptual development.In order to further refine and optimise digital product development, any detected mistakescaused by incorrect assumptions in the computer models must be properly documented. Theywill serve as input to the geometrical prerequisites in the next project.

Verification. The physical prototypes must be verified against the product specifications. Theprototypes will also verify if it is possible to assemble the products as intended. Verificationshould 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 andmeasures. One of the prerequisites for digital product development is that the GBPI willreflect reality. Some approximations will always be done and it is extremely important todocument this knowledge about what should be considered as an acceptable approximation.

3 Conclusions

The investigations and studies have clearly indicated that there is a need for a GeometryManagement Process. Furthermore, the GBPI must be viewed from a holistic perspective totake full advantage of digital product development. The method of categorisation is one wayof mapping corporate requirements on GBPI. It has been proven that it is possible to take therequirements of different categorises of geometry users into consideration in the productdevelopment process. The process perspective makes it feasible to detect when therequirements are to be met in the product development process. The breakdown of the processdomain into different levels makes it feasible to bridge gaps between project management andpersonnel working in the line organisation.

This article deliberately makes no mention of any tools or systems since it presents theprocess domain. However, it should be pointed out that in the CAD tool most geometryrefinement activities take place. Packaging and viewing tools depend on a geometry baseoriginating 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 theSwedish Strategic Foundation's national programme ENDREA (The Swedish EngineeringDesign Research and Education Agenda).

References:

[1] Mantyla, M., Tomiyama, T. and Finger, S. "Knowledge Intensive CAD: Volume 1".Chapman & Hall, 1996.

[2] Fuxin, F. and Edlund, S. "Categorisation of Geometry Users". CONCURRENTENGINEERING: Research and Applications , Volume 9, March 2001.

[3] Ulrich, K.T. and Eppinger S.D., "Product Design and Development". McGraw-Hill,1995.

[4] Prasad, B. "Concurrent Engineering Fundamentals: Integrated Product and ProcessOrganization". Volume 1, Prentice Hall, 1996.

[5] Blessing, L. and Wallace K. "Supporting the Knowledge Life-Cycle". Ifip Tc5 Wg5.2Third Workshop on Knowledge Intensive Cad, 1999.

[6] 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

CONCURRENT DESIGN OF PRODUCT AND PACKAGE - EXTENDINGTHE CONCEPT OF IPD

C Bramklev, R Bjarnemo, and G Jonson

Keywords: Integrated Product Development, Interviews, Design of Packaging, Survey

1 Introduction

As a result of the globalisation of the world economy, many enterprises that previouslyconfined their business activities to national markets are now focusing on broaderinternational markets, thus forming the basis for the establishment of global enterprises. Inaddition to the extension of markets, these global companies also seek cost reductionsthrough scale economies in logistics, marketing, product development, production andpurchasing, and through focused manufacturing and/or assembly operations - Christopher [5],Porter [10].

In order to contribute to the establishment of global enterprises, an interdisciplinary researchproject has been launched at the Department of Design Sciences, Lund University, Sweden,as a collaborative effort between two of its divisions - Machine Design and PackagingLogistics. The overall objective established for the project is to: "facilitate the establishmentof successful global enterprises by providing methods, techniques and an overall proceduremodel for integrating packaging logistics into the product development process. "

By extending the concept of Integrated Product Development (IPD) to include the concurrentdesign of product and packaging, increased efficiency and effectiveness in the productdevelopment process are conceivable. Apart from the apparent advantage of reducing thetime to market, environmental impacts in terms of a reduction in the consumption of rawmaterials due to the possibility of facilitating a "tailor-made" packaging of the product arealso conceivable. As a result of the development of more efficient and effective packaging ofthe 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, lesscostly, solutions; this especially applies to those products, which have to withstand majorstructural loads during the distribution phase of the product life cycle.

The overall concept of integrating relevant activities from the packaging logistics area intothe IPD process has been introduced in a previous paper - see Bjarnemo et al [1 ]. In the paperpresented here, the main objective is to:" establish the industrial relevance of introducing theconcurrent design of product and packaging thus supporting or rejecting the key element inthe previously developed integration concept. " The secondary objective is to: "obtain moredetailed information on the actual handling of the interaction between product andpackaging design in industry." The latter information is intended to be used either for thefurther development of the extended IPD concept or for providing a more detailed view whythe integration concept has to be rejected.

ICED 01 – C586/609 377

In order to obtain the information requested, an explorative survey has been performed inSwedish industry. The findings from this survey and its implications, as outlined above, arereported here.

2 Basic concepts

In a literature survey reported in Johnsson [7 pp 36-37], a large number of definitions ofpackaging were found. Based on Paine [9], the following definition has been derived andadopted here: "Packaging is a means of ensuring safe and efficient delivery of the goods insound condition to the ultimate consumer followed by an efficient reuse of the packaging orrecovery and/or disposal of the packaging material at minimum cost". In this definition,"packaging" should be interpreted as ranging from simple wrappings to advanced special-purpose 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 tofocus on the product features needed in the different phases of the product life cycle. Byconsidering packaging as an "extension" of the product during the manufacturing phase untilit is installed/mounted and the packaging is removed from the product, an understanding ofthe 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 importantcompetitiveness factor on the market, an efficient and effective approach to the design of theproduct-to-be alone represented the most effective and efficient means of increasingcompetitiveness. However, as the adaptation to business, industrial design, market/consumer,production, sales etc. became equally important in handling the competition on the globalmarket, new methodologies focusing on the overall development process, the productdevelopment process, were developed. Note that the creation of procedure models for theproduct development process represents an extension of the previous models provided within(engineering) design methodology. In other words, the design procedure becomes embeddedin the product development procedure model - see Bjarnemo [3].

The common denominator in these new product development procedure models is the closeinteraction 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 thework in cross-functional teams.

Undoubtedly, the most significant driving force in the development of tomorrow's productdevelopment procedures will be the rapid development in modern Information Technology(IT) - including not only hardware and software computer components, but also the links fordigital communication. Since communication is the essence of integration, it is only logicalto focus on the IPD- procedure as having the inherent potential to become the mostsuccessful development procedure of tomorrow in the light of the product developmentprocedures existing today - see Bjarnemo [2].

The product development procedure model referred to here is the original one developed bythe late Professor F. Olsson - see [8]. At the Design Policy Conference in London in 1982this model was revised and renamed. The revision and renaming were undertaken byProfessor 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 orsimply 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 underlyingstrategy utilised for the decomposition of the complete development procedure correspondsto the decomposition of the design phases of the underlying design methodology, whichmeans that the inherent logic of the engineering design process forms the basis of the wholeprocedure model. In turn, each and every one of these design phases is decomposed on thebasis of a five-step creative problem solving procedure.

The most important conceptual cornerstone in the building of the IPD procedure isintegration. 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 isreferred to. It is important not to forget "horizontal" integration, or maybe more adequatelyin the present context, the compatibility between the subactivities forming each of the stagesof a given function. In other words, the latter integration/compatibility refers to theintegration along the time-axis of the project and within each and every one of thesubprocesses, thereby focusing not only on connecting people and process but morespecifically, on connecting technologies which focus on the product-to-be.

3 Survey approach

As the IPD procedure model originates from studies of product development processes withinmechanical engineering, it is suitable to confine this survey to the same area for theoretical aswell as practical reasons. The classification of a product as mechanical is simply based on thefact 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 mechanicalworking principles. In future projects, additional product areas such as those of medical andpharmaceutical devices as well as food and dairy products will also be surveyed.

The lack of a commonly accepted terminology creates major problems whenever attempts aremade to extract information from mechanical engineering processes, especially when designand development processes in industry are surveyed. To decrease the impact of theseproblems to some extent, a survey technique based on the combination of a questionnaire andan interview was chosen - see Bjarnemo [4]. In this combination, the questionnaire is simplyintended 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), ifnecessary.

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 mechanicalengineering 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 ensuresthe existence of a corresponding number of companies within the other products areas ofinterest 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 nottotally unknown to us, at least not as far as their product development functions areconcerned, 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 andasked to be responsible for the answers given by the company. This gave the productdevelopment manager the freedom to select who was going to answer/discuss the interviewtopics 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 questionspresented in the objectives established for the project reported here. For each of the topicsabove, a number of questions were included in the questionnaire and discussed during theinterviews. Due to the qualitative nature of the questions and the fact that this survey is of anexplorative 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 thisand future surveys.

4 Survey results

As previously mentioned, each interview was prepared in advance by confronting the productdevelopment manager with the six topics and their corresponding questions. In a majority ofthe interviews, extensive discussions followed each question. For obvious reasons, fullaccounts of these answers have not been included in the presentation of the survey resultsbelow.

380 ICED 01 – C586/609

In order to limit the presentation of the findings of the survey to the relevant issues withreference to the objectives established for this paper, the main part of the answers/informationobtained is given in the form of a "Yes" or a "No". All the results have been condensed intotwo tables.

In Table 1, each of the companies is introduced with reference to what kind of products theydevelop and produce. The size of the product development staff as well as the investment inR&D (in % of the annual turnover) are also included in order to give an insight into thecompany resources available for product development and design. The final questionaccounted for in Table 1 is the use of a formalised approach to the productdevelopment/design processes. Note that the term formalised approach simply indicates theexistence of a procedure model to be followed in the development process and that thisprocedure is documented. The term is used in order to avoid any value added characteristicssuch as methodical or systematic.

Table 1. Topics 1-3: Company characteristics, PD1 staff and resources and the use of a formalised approach

Com-pany

ABCDEFGHIJKLMNOPQRsT

Products

Fuel handling systems for petrol stations

Products / systems for handling coins and banknotesPot washing machines

Sights for firearmsParts cleaners for body shops and tire shops

Dialysis machines and equipmentHeart-Lung machines and heater coolers

Web cleaners, tension control, breaks and pumpsAseptic dosing units / machines for foods

Walk-behinds and lawn mowersInjection moulding of pharmaceutical devices

Telecom heat exchangersHygiene systems within geriatric careIndustrial metal products; white goods

Brakes and brake systemsDoor automation systems

Exhaust extraction systemsPower transmission parts and componentsRecycling systems for stores and industry

Industrial door systems

PD'Staff

30256

4.55

9062

151

112155

4718712314

Investmentin R&D(% of

turnover)

8155775

252102152042

42

4.844

3

Formaliseddevelopment

process

No

YesYesNoYesYesYesNoYesNoYesNoYesYesNoYesYesNoYes

Yes

'PD = Product Development

As expected, and useful for the survey, the products supplied by the companies cover verydiversified markets. As for resources for the product development function, these range froma staff of 1 up to 90 people; consultants are not included in these numbers. When theinvestment in R&D is compared, there is a clear demarcation as to which of the companiesare relatively newly established and/or have adopted a pioneering product strategy, and thosecompanies which have established themselves on mature markets and thus keep a lowerdevelopment 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 actualdevelopment 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

ABCDEFGHIJKLMN0P0RST

YYYYYYYYYYYYYYNYYNYY

I, PI, P

I, P, EgEg, Ex,T, P, L

PP, R

PP

Au, Ce, P, LI, L, P, T

Au, H, I, PAs, P

Au, L, PI, Ex, P

PAs, P

PPP

Ce, P

YYYYYYYYYYYYYYYYYYNY

YYNNYYNNYYYNYYYYYYYY

NYNYYYYYNYYYYNYYYNYY

YNYYYNNNYNYYYYNYYNNY

NNNYYYNNYNYNYYYYYYYY

YYNYYYYNYYYYYYYYYYYY

Topic 4 - The role of thepackaging

Topic 5 - The interactionbetween packaging and product

Topic 6 - The role of the packagingin the PD-process today and

tomorrow

Y = yes, N = No

As = assembly/installation supportAu = support mfg. automationCe = cost effectiveEg = ergonomic

Ex = expose productH = hygienicI = carry informationL = logistics and distribution adopted

P = protectR = environment friendlyT = traceable

Regarding the specification of the packaging, 90% of the companies carry this out as a part ofthe overall development project. It was also clearly indicated during the discussions that notonly the packaging as such, but the whole product distribution chain, are identified today asbeing significant factors in the overall development efforts. Not very surprisingly, protectwas identified as the single most important packaging function. In i.e. 7, 35% of thecompanies, this was the only function required of the packaging. The second most importantpackaging function, corresponding to 30 % "Yes" from the companies, is to inform. In 5, or25%, of the companies, packaging was used as an integral part of assembly/installation andautomation in the manufacturing process. However, several other companies arecontemplating 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 theproduct development project. Even though 75% of the companies claim that the packaginghelps to withstand structural loads during the distribution phase, only one of the companieswas actively planning to integrate this effect in the actual design of the product. One apparentproblem for a majority of the companies, or 75%, was the necessity to decompose the productinto subsystems in order to facilitate the transportation of the product. The problem referredto here is the need for costly assembly operations in the field.

60% of the companies agreed that better packaging could contribute significantly to costreduction. 65% were aware of the customer's demands on the packaging. Note that a numberof the companies defined their own personnel installing the product as "customers". In noless than 90% of the companies, the integration of packaging and product development wasconsidered to be an interesting and promising concept.

5 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 ofpackaging and product!

A second important findings in the survey is that our previous, preliminary extension ofpackaging logistics into the IPD process can be given a more definite form. In the preliminaryversion, packaging logistics was simply considered the "fifth function" to be accounted forduring the IPD process. The reason for not integrating packaging logistics into one or more ofthe four existing functions (market, design, production and business/finance) was the lack ofinformation provided by the second question under topic 4 - see Table 2.

On the basis of this information we have drawn the conclusion that packaging developmentshould be integrated into all of the functions. In order to provide substantial support forfacilitating this integration process, we have identified packaging design as the key elementin the process. Consequently, a parallel research project has been launched, in which acomputer based analysis tool to support the designer during the combined efforts ofdesigning product and packaging is under development.

The tool is based on newly derived constitutive models of corrugated board material andEPS, utilising a combination of powerful FE-codes such as ANSYS and LS-DYNA. Dr. AkeBurman and Lie. Eng. Martin Eriksson, both at our department, carry out the project. Anexample is given in Figure 1 below.

We have also found a far greater interest in these matters than we anticipated at the beginningof the project. In some of the companies, our survey was considered to have started aninternal process of discussing the benefits of paying greater attention to the development ofpackaging. It should be noted that this process might actually have started long before thecompanies participated in our survey. The number of considerations and measures alreadytaken by the companies evidences the existence of such a process. One example is the widelyadopted concept of integrating, at least formally, the development of the packaging into theoverall product development project.

ICED 01 – C586/609 383

Figure 1. FE-simulation of packaging and product-courtesy A. Burman and M. Eriksson

6 Acknowledgements

The authors would like to acknowledge the generous support given by the Swedishcompanies participating in the survey.

References

[1] Bjarnemo, R. et al, "Packaging Logistics in Product Development", Proc. ICCIM 2000.Singapore, pp 135-146

[2] Bjarnemo, R., "Product Development in the Virtual Enterprise", Nord Design98, RoyalInstitute of Technology, Stockholm, 1998, pp 137-146

[3] Bjarnemo, R., "Product Renewal by Using IPD", Proc. ICCIM'97. Singapore, pp 951-960

[4] Bjarnemo, R., "Evaluation and Decision techniques in the Engineering Design Process- in Practice", Proc. ICED 91, Zurich, pp 373 - 383

[5] Christopher M., "Marketing Logistics", Butterworth-Heinemann. London, 1997

[6] Hein, L. et al., "Integrated Product Development", Proc. Design Policy, Vol. 2, TheDesign Council, 1984, pp 86-90.

[7] Johnsson, M., "Packaging Logistics - a value added approach", Department ofEngineering Logistics. Lund University, Lund, 1998

[8] Olsson, F., "Systematisk Konstruktion", (in Swedish), Department of Machine Design,Lund Institute of Technology, Lund, 1976

[9] 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 DESIGNICED 01 GLASGOW, AUGUST 21–23, 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 requirementsof a support system for distributed conceptual design. Distribution offers a number ofadvantages 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 inindustry, but conceptual design has received little attention up to now. Based on the "DesignAssistant" by Schuster [1], a support system that guides a distributed design teamsystematically 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 amethodology for a distributed team of designers in comparison to classical methods for co-located 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 productdevelopment offers a means of including the know-how of experts from all over the world andof making use of resources at different company sites, in different countries [4]. This resultsin reduced costs and lead-time, as well as in increased quality. The challenge is to connectdesigners and design teams worldwide and to make formal information exchanges amongthem more effective and user friendly. Support systems for distributed design must strive toprovide the same functionality and convenience that the designers are used to in working withtheir co-located colleagues.

Currently available support systems, e.g. the framework of Huang & Mak [5], implementmethodical conceptual design in a distributed environment, but fail to provide proper tools forcommunication, information transfer and design-content input. A system of three segments,which complement one another and can interact closely, is necessary. The segment "DesignMethodology" places a methodology that guides designers through the conceptual designphase and offers tools for concept generation and evaluation at their disposal. The segment"Communication and Information Transfer" co-ordinates the communication between thedistributed 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 ofthe 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

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 segmentsmentioned above. The segments and the accompanying framework components will bedescribed 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 establishedapproach to the design process. These methodologies were analysed to determine theirsuitability for a distributed design scenario and recommendations for improvement weremade.

3.1 Specification development

The design process starts with an idea or a need for a new product or a product redesign, asexpressed by a customer. The customer can be an external client and/or a department withinthe company. The recording of the customer requirements usually does not involve the wholedesign team. This step has therefore to be carried out as accurately as possible, in order toreduce later enquiries to a minimum. In particular, distributed team members far from thecustomer'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 andquestionnaires make the distribution of design specifications easier, since the conversionbetween file formats, a common source of errors and omissions, is reduced. Checklistscontaining general and specific objectives and constraints support the process of creating andupdating the requirements list.

Ullman [3] bases the development of the engineering specification on the "Quality FunctionDeployment" (QFD) technique, although Suh [7] states that it is only useful for redesign. Fora distributed design environment QFD is particularly valuable because of its high informationcontent and the comprehensible graphic representation in the form of the QFD "House of

386 ICED 01 – C586/049

DESIGN METHODOLOGY

• Distr. Conceptual Design Methodology• Methods and Tools

- Lists of Requirements / QFD- Morphological Charts- Creativity Techniques

COMMUNICATION ANDINFORMATION 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.

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'srequirements and establishing the engineering requirements. Every customer requirement hasto be linked to at least one engineering requirement and vice versa. Every team member canmake contributions to both lists. The team manager can organise all entries into categoriesand check the lists for completeness. A "House of Quality" can also be created. Since groupdiscussions cannot always take place, each matrix entry can be annotated to inform the otherteam 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 functionand multi-level sub-functions. For distributed design teams a hierarchical, numbered tree-structure is more suitable than graphic-oriented diagrams, e.g. functional flow charts, sincethe tree-elements, their positions and their linkages with each other are easier to record, tostore and to impart to the other team members than graphical components. After thedecomposition, 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. Thisprocedure 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 theprevious step, one or more suitable solutions must be found. Various techniques to supportthis process are included in the framework. The proposed solutions for the sub-functions arethen combined to a number of concept proposals to satisfy sub-concepts, i.e. functionalpackages, 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 canalso be made, e.g. when these can be satisfied by the same solution or when an off-the-shelfcomponent is a practical answer. By using one solution for multiple sub-functions it ispossible to reduce the component count of the developed product. Each designer can gothrough the concept proposals generated by the other team members to stimulate creativethinking and eventually lead to more and better solutions. In case too few or unsatisfactorysolutions have been identified for a particular sub-function, the team manager can initiate abrainstorming or brainwriting session. Brainstorming and brainwriting are valuable methods,especially when used as computer-based tools in a design group [9]. Brainstorming sessionscan be held in the form of group-chats or videoconferences, with the team manager or anotherperson guiding the discussion, taking notes and distributing the collected information to allteam members. The biggest problem here is the coordination of a suitable time for allparticipants. Brainwriting sessions are time-wise unrestricted, since they can runasynchronously. Brainwriting, also called "Method 635", makes use of forms that circulate inthe 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 brainstormingsessions depend on the knowledge and experience of the participants rather than on theirlocation. 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 onthe 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 dueto the lack of personal contact.

For the generation of concept proposals, the "Concept Generation Assistant" provides a list ofthe functions and sub-functions and their possible solutions. Each user can select one solutionfor every sub-function and combine them into a number of concept proposals. This approachis similar to the use of a "Morphological Matrix" [2], but does not automatically create a vastand incalculable number of concepts. Instead it allows for the development of numerousdifferent concept proposals that already went through an initial selection process, namely thechoice by the user. This increases the chances of obtaining a large number of high qualityconcepts.

The number of concepts generated by each designer is dependent on the time available, thecompany 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 donot meet the previously established requirements or that are regarded as not worth furtherconsideration, based on the designer's "gut feel" [3]. Discarded concept proposals are notdeleted from the pool, but marked as rejected. In this way they can still serve as a source ofinspiration for the designers during the refinement of the other concepts. Different techniquescan be used, from simple yes/no-voting to short group discussions, depending on the teammanager or on the company's policies.

The remaining concept proposals are evaluated in order to determine the most suitable onesfor further development. The "Decision-Matrix-Method", or "Pugh's Method" [10], is used toscore each alternative concept, relative to another. According to Ullman [3] this method ismost effective if each team member performs it independently, to avoid any influencing, andthe individual results are compared. The distributed team is therefore not at a disadvantagewhen using this method.

The "Concept Evaluation Assistant" helps each designer to check for compliance with theinitial customer requirements and the evaluation criteria. It supports the designers inweighting 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 veryimportant. The team manager has to decide on an applicable strategy and to coordinate theseparate steps of the design process. In many cases the team manager does not directlyparticipate in the design process, but rather supervises the progress of the team. The proposedframework includes a "Team Management Assistant" which provides, among other tools, aquestionnaire-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 orasynchronously with the other team members, depending on the scenario and availableequipment. Each phase should be concluded with a design review, moderated by the teammanager. These reviews are important elements of the methodologies described by Ullman[3] and Blanchard & Fabrycky [8]. hi a distributed environment the meetings and theexchange of notes provide a deep insight into the project (this is natural in co-located designgroups). The users are also encouraged and aided in documenting all their steps in order toallow the fellow designers, or designers of follow-up projects, to understand the decisionsmade.

A "Documentation Assistant" provides templates and guidelines for the proper compilation ofthe conceptual design specification and other reports. It also assists in integrating the varioustables, notes and graphics generated during the conceptual design phase into the projectdocumentation.

4 Communication and information transfer

A greatest disadvantage of distributed design is the restricted communication between theparticipating team members. Designers in a co-located environment can call for a meetingwhenever necessary, but conferences in distributed design teams have to be planned morecarefully. Considerations such as office hours in different time zones as well as theavailability and suitability of communication tools have to be taken into account. With thecontinuous expansion and the increasing capacity of the World Wide Web, communication isno longer restricted to telephone, fax and postal mail. Traditional and modern communicationmeans are complementary and should be used in an optimised way.

The "Communication Assistant" is a support tool for all communication issues. It keeps trackof team members logged into the system, displays the status of availability for synchronouscommunication, i.e. phone, chat or videoconferencing, together with the necessary contactdetails, and provides an interface for e-mail, chat and a message board.

Information transfer during the conceptual design stage differs from the later phases incontent 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 increasesit 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 participatingdesigners now do not have to send every bit of information to every team-member that theyassume will be interested in the information. Instead, the designers upload their data onlyonce 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 ofconsistency, i.e. all team members can work with the same version of a file, as earlierinvestigation by the authors have shown [12]. Designers need a global perspective of theproject they are working on and therefore should have access to as much information aspossible, 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. Whilestandard 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 increating or annotating a sketch. The proposed framework takes this into account byintegrating 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 andasynchronous collaboration in distributed conceptual design. Of particular interest was thesuitability for the exchange and discussion of difficult-to-grasp design information, such asideas and hand-sketches. The tools included telephone, fax, e-mail, videoconferencing and ashared workspace environment, as well as various input devices, such as a scanner and agraphic tablet with pen. The case study confirms the advantages of pen-based sketch inputover standard input devices, like the computer mouse, in terms of speed and quality. Personalexperience of the first author also indicates the value of digital cameras and WebCams tocapture and exchange design information in form of sketches, notes on white-boards, andthree-dimensional mock-ups.

6 Conclusions

The investigation into the practicability and the requirements of a support system fordistributed conceptual design shows that most elements of classical design methodologies arealso applicable to distributed design. Especially the structured approach is an advantage indistributed design environments. But it is not enough to develop a number of tools for designmethodology and provide access to this system from different locations. Ullman [3] statesthat "communication is one of the key features of concurrent engineering, and effectivecommunication is essential among design team members." A methodical approach must beaccompanied by a system to enhance the communication and information transfer between theparticipating designers and support their interaction. The framework segments "DesignMethodology" and "Communication and Information Transfer" cannot be put to good usewithout the provision for advanced input devices, fast and accurate enough to capture a flashof inspiration before it disappears.

The framework for distributed conceptual design is currently under development and will beused for validation case studies.

Acknowledgements

The financial support of the National Research Foundation (NRF grant GUN 2034084) andthe Stellenbosch University Research Committee is gratefully acknowledged.

References

[1] Schuster, H.R., "A Computer Aid for Specification Development, Conceptual Designand Manufacturing Cost Estimation in Mechanical Design", Ph.D. Thesis, University ofStellenbosch, South Africa, 1997.

[2] Pahl, G. and Beitz, W., "Konstruktionslehre - Methoden und Anwendung". Springer,Berlin, 1997.

[3] Ullman, D.G., "The Mechanical Design Process". McGraw-Hill, Boston, 1997.

390 ICED 01 - C586/049

[4] Gierhardt, H., Gaul, H.-D., and Ott, T., "Distribution in Product Design andDevelopment Processes", Proceedings of the 1999 ASME Design EngineeringTechnical Conferences. Las Vegas, 1999, DETC/DTM-8777.

[5] Huang, G.Q. and Mak, K.L., "Web-based Collaborative Conceptual Design", Journal ofEngineering Design. Vol. 10(2), 1999, p. 183-194.

[6] VDI, "VDI Guideline 2221 - Systematic Approach to the Development and Design ofTechnical Systems and Products", VDI-Verlag, Diisseldorf, 1986.

[7] Sun, N.P., "The Principles of Design". Oxford University Press, New York, 1990.

[8] Blanchard, B.S. and Fabrycky, W.F., "Systems Engineering and Analysis". PrenticeHall, Upper Saddle River, 1998.

[9] Holt, K., "Brainstorming - From Classics to Electronics", Journal of EngineeringDesign. Vol. 7 (1), 1996, p. 77-82.

[10] Pugh, S., "Total Design - Integrated Methods for Successful Engineering". Addison-Wesley, Wokingham, 1991.

[11] Bentley, R., Appelt, W., Busbach, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J. andWoetzel, G., "Basic Support for Cooperative Work on the World Wide Web",International Journal of Human Computer Studies: Special issue on Novel Applicationsof the WWW. Academic Press, Cambridge, 1997.

[12] Schueller, A. and Basson, A.H., "Case Study on Synchronous and AsynchronousCommunication in Distributed Conceptual Design", to be published in Proceedings ofthe 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. BassonDepartment of Mechanical Engineering, Stellenbosch University, Private Bag X1, Matieland7602, 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 DESIGNICED 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.

1 Introduction

Design of large made-to-order products invariably involves design activities which areincreasingly being distributed globally in order to reduce costs, gain competitive advantageand utilise external expertise and resources. Designers specialise within their domainproducing solutions to design problems using the tools and techniques with which they arefamiliar. They possess a relatively local perception of where their expertise and actions areconsumed within the design process. This is further compounded when design activities aregeographically distributed, resulting with the increased disassociation between an individualdesigner's activities and the overall design process. The tools and techniques used bydesigners rarely facilitate concurrency, producing solutions within a particular disciplinewithout using or sharing information from other disciplines, and seldom considering stageswithin the product's life-cycle other than conceptual, embodiment or detail [1, 2].Conventional management and maintenance of consistency throughout the product model cansubsequently become difficult to achieve since there are many factors that need to besimultaneously considered whilst making a change to the product model.

Concurrent Engineering (CE) is often regarded as a means of significantly reducing designtime 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 relatedprocesses, including manufacture and support. This approach is intended to cause thedevelopers, from the outset, to consider all elements of the product life-cycle from conceptionthrough disposal, including quality, cost, schedule, and user requirements."

This definition is representative of many of those encountered in that the main emphasis isplaced on its systematic approach to the design process as it reduces the design time and hencetotal design cost, which is one of the main considerations in the entire design process. CEhowever cannot be fully realised without co-ordination [4] and given a co-ordinated approachwithout de-coupling dependencies, concurrency will only be achieved where the designprocess permits.

The DMS is intended to tackle some of the issues arising from the above statements byproviding a formalism that would enable the design process to be co-ordinated in a tacticalmanner. This involves determining the actions required to be undertaken to perform a specifictask 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 communityand is aimed at improving the performance of the engineering design process. One of the mostprominent frameworks associated within design co-ordination is the Design Co-ordinationFramework (DCF) [5]. The DCF presents a number of frames, each of which is aimed atrepresenting different aspects of design co-ordination. The DCF also describes themanagement of the links between the frames. The research presented in this paper identifiedthat tactical co-ordination may be represented by: the goal/result model; thediscipline/technology model, and, the task model frames within the DCF. These models aredescribed within section 3. The focus of this tactical design co-ordination system is themanagement of design tasks, information, goals and rationale within the product developmentprocess such that the process may be performed in a timely and appropriate manner. TheDesign Management System (DMS) was used to manage and co-ordinate these tasks, andevaluate the constraints, maximising concurrent design activity, whilst maintaining inter-taskdependencies.

Close contacts with industry were maintained during the research programme which focusedon the development of the DMS system towards tackling design issues that were consideredpertinent to the companies such as reducing design time, ensuring informational consistency,and facilitating, not automating, the decision making process. An application of the DMSwithin an industrial case study is demonstrated within section 4. The case study represents anumber of inter-dependent tasks that need to be performed and constraints that need to besatisfied for the design of a stage of blades within a steam turbine. Conclusions andrecommendations are made within section 5.

2 DMS architecture

The DMS was constructed to co-ordinate the design activity of an agent-oriented designprocess with respect to managing design tasks, information, goals and rationale, andfacilitating the decision making process. A basic representation of a software-based designagent was produced to: manage the functionality of existing design tools; enablecommunication with the DMS and other design agents, and, demonstrate how the distributeddesign problem may be managed and co-ordinated. The focus of this work was, however, nottowards the development of autonomous agents. Malone et al. [6] proposed two designprinciples for the design of agent-based systems which were used during the development ofboth 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 humansdo is a flexible one."

"Don't build agents that try to figure out for themselves things that humans could easily tellthem. Instead, try to build systems that make it as easy as possible for humans to see andmodify 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 theproduct 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 thedisciplines and technologies are distributed over the artefact.

Within the context of an agent-oriented distributed design architecture, thediscipline/technology model represents the structure of the agents and the technologies thatthey utilise. That is, the agents and associated design tools often reflect the disciplineknowledge and technologies within the domain. The model also contains informationpertaining to the tasks that the design agents are capable of undertaking. Through theproduction of a design process displaying the inter-dependencies between the tasks, it ispossible 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 wellas 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 performedare defined by the functions that the associated design software may achieve. However,developments are underway to define and model tasks and their associated disciplines andtechnologies 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 engineercontaining a description of the task that needs to be performed as well as the informationrequired to perform the task and the information that the task will produce. When the task iscompleted 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 thedesign 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, whichcould 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 andinter-task relationships within the design process [7, 8]. This concept has been extended suchthat iteration and decision based branching may be represented within the design process witheach process having its own matrix representing the tasks that need to be undertaken toachieve a particular goal. Providing individual representations in this way has enabled theoverall goals of a process to be identified based upon the tasks contained within it, as well asenabling the DMS to manage more than one design process simultaneously. Allowingsimultaneous management of processes further increases the functionality of the DMS sincedifferent aspects of the same design problem may be modelled and evaluated concurrently, forexample 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 alsomanages the dependencies between process models that are required to co-ordinate concurrentdesign activity.

The new Design Structure Matrices also include decision based dependencies to provide anexit condition from an iterative loop. A number of partitioning and concurrency based criteriawere 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 anobject-oriented approach. Currently, four different types of information have been developedbased upon this formalism: Parameter, Option, File and File Group. The formalism requiresall design information used within the DMS to inherit from a base class which providesmechanisms for comparing different pieces of information, serialising information such that itmay be communicated across a network or stored persistently on a disk, and enablinginformation to be displayed graphically within the DMS. Extending the base class enablesnew types of information to be developed to suit the intended application. For example, if thedesign problem is to develop an internal combustion engine, the base class could be extendedto produce a new information type which provides all of the information required to representa 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 alsobe included within the new information type to constrain how the information may bechanged.

Each design process has an associated information model, containing information that hasbeen either provided or produced, which is stored centrally within the DMS. When a newpiece of information has been generated as a result of performing a task it is placed into theproduced area of the information repository, replacing existing or outdated information asnecessary. 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 whichwould enable decisions to be made more appropriately.

Using parametric information made available from within the process information model, it ispossible to construct and evaluate mathematical expressions which represent certainrequirements or constraint-based goals of the design process, such as, for example, checkingthat the calculated efficiency is greater than a minimum efficiency. The design goals will beevaluated automatically when the design process has been enacted and the design solution fora particular design concept produced. If a goal has not been satisfied, then the user is notifiedof the problem, such that decisions may be made with respect to the design concept in order tosatisfy the goal.

The DMS currently lacks optimisation-based goals, i.e. there are no mechanisms forexpressing the goal, "maximise efficiency". Current developments within the DMS include asuite of optimisation software for both the optimisation of the design process and the designproduct. The optimisation software includes: a robust design tool which may be used to eitherincrease the robustness of a product, or give a good "ballpark" design which is near theoptimum, a multi-criteria genetic algorithm which either may be applied to optimising thedesign process or product, and a multi-criteria simulated annealing algorithm which may alsobe applied to optimising the design process. Both the multi-criteria genetic algorithm andsimulated annealing algorithm have been implemented within the design structure matrix andhave successfully demonstrated that the design process may be improved with respect to bothconcurrency and partitioning.

396 ICED 01 -C586/114

3 Implementation and case study

The industrial case study used to validate the DMS software consisted of the co-ordination ofa number of disparate design agents that were used to evaluate particular aspects of theperformance of a stage within a turbo-generator.

The associated tasks are represented within the design process seen in Figure 1, whichdescribes the activity that needs to be performed to determine aerodynamic, stress, andvibration characteristics of the turbine, as well as providing information regarding thedependencies between the tasks. The design process area also contains a list of theinformation that is provided as input to the design process which describes the design conceptto be evaluated, a list of output information which describes the corresponding designsolution, 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 designprocess and provide evaluations of design process based performance criteria. A number ofoptimisation algorithms may be used to re-sequence the tasks within the design structurematrix with the objectives of improving the process performance with respect to thepartitioning and concurrency criteria. Different weightings may be applied to the dependenciesto represent strong and weak relationships. In this particular example however, all of thedependencies are defined as being strong since it is not possible to start a tool prior to thecompletion of a preceding tool.

3.1 Previous implementation

A typical evaluation of a design concept started with the production of a preliminary conceptwhich 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 themanual execution of each of the tools in the order depicted by the design structure matrix. Theflow of execution through the process is from top to bottom, although it may be modelled inany direction within the DMS. It can be seen from Figure 1 that certain tasks may beundertaken 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. Uponcompletion of each task, the information generated required moving to the correct location forthe following tasks to maintain informational dependencies. This process was undertakenmanually, and found to take approximately 11 minutes. The design solution, spread across alarge number of files and a number of different disciplines, would then be examined to extractcertain information which would be used within additional manual calculations to determinewhether the design concept satisfied the design constraints. Rules would then be applied basedupon the designer's experience to vary the parameters, changing the design concept to satisfythese 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 areregistered within the discipline/technology model of the DMS. This initial communicationinforms the DMS that the specified agent is capable of undertaking some design activity. TheDMS then makes a request that the design agent provides information regarding the nature ofthe 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 satisfiedprior 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 individualatomic task or a group of tasks depending upon the level of abstraction of the implementationof the design agent. The design process may then be designed by decomposing it into therelevant tasks available. Informational dependencies must be maintained during the design ofthe process. The DMS will notify the user if a task has been included within the process thatrequires information that has not yet been produced. The task would then disable itself untilthis informational dependency has been satisfied. The consequence of ensuring informationaldependency is that tasks may not be decoupled, and concurrency may only occur as defined bythe process.

The design concept to be evaluated may be selected and modified by viewing the input fileswithin the design process. Once a suitable design concept has been defined, the process isstarted with the DMS communicating to the design agents in turn providing them with thenecessary information to undertake the current task. Once the design agent has processed theinformation and executed the associated tool, the design agent will notify the DMS of theinformation that has been produced from the tool. The DMS then determines from the designstructure matrix which tasks are now capable of being enacted and communicates with thoseagents in a similar manner. Once the process has been completed, the DMS will evaluate anygoals 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 sameworkstation 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 manualenactment. The experiment was repeated with the agents distributed across a number ofworkstations, 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 wasdue to concurrent design activity across a number of computational resources. The DMS alsoensures that if an application failed to produce a solution, a warning would be issued to theuser with a description of the nature of the failure, and the remaining tasks would besuspended.

4 Conclusions

A new approach to tactically co-ordinating distributed, agent-based design activities has beenpresented. The approach enables concurrent engineering to be realised through themanagement of dependencies. From a CE perspective the focus is more towards enablingconcurrency, rather than maximising concurrency by de-coupling activities, thus allowing thedesign process to progress naturally.

The approach was evaluated using an industrial case study that had a well-established designprocess. The activities within the process as well as the management of the informationresulting from the activities were previously performed manually using a number of differentcomputer-based design tools. Upon completion of the process, the results from the designactivities would be used within calculations to check that the design concept satisfied theconstraints. Alterations would subsequently be made to the parameters that were thought to bepreventing the concept from satisfying the constraints, and the process would be repeated untilthe design concept fulfils these requirements. The time taken to evaluate a design conceptthrough the manual enactment of the process was approximately 11 minutes.

Each design tool was subsequently managed by a design agent within the DMS. The designprocess was then constructed using information obtained from these agents. Through themanagement of the dependencies within the process, two threads of concurrent activities weremade apparent. The evaluation of a design concept was managed using the DMS using thesame platform as the manual test with the agents distributed across three Ultrasparcworkstations and produced a reduction in process time of approximately 46%. This timeobviously depends upon the amount of the resources available to the agents, however, thesame principle applies for the manual case, and in both the manual and DMS experiments, theresources had 100% of the cpu available to the user. This time may be considerably reducedfurther with the inclusion of a generic "operational co-ordination" module [4] through thedynamic co-ordination of resources.

The DMS was also responsible for managing the constraints such that the stresses within theblades and the vibration characteristics met certain pre-determined requirements. This wasachieved by altering various geometrical characteristics of the blades using specificguidelines.

5 Acknowledgements

The authors gratefully acknowledge the support given by the Engineering and PhysicalScience Research Council who provided the grant RES/4741/0929 that enabled this work tobe 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-ordinationApproaches and Systems - Part II: An Operational Perspective", Research inEngineering Design, Vol. 12, No. 2, 2000, pp. 73-89.

[2] Whitfield, RI, Coates G, Duffy AHB & Hills W, "A Review of CoordinationApproaches and Systems - Part I: Strategic Perspective", Research in EngineeringDesign, Vol. 12 No. 1, 2000, pp. 48-60.

[3] Winner RI, Fennel JP, Bertrand HE & Slusarczuk MMG, "The Role of ConcurrentEngineering in Weapons System Acquisition", IDA Report R-338, Institute of DefenceAnalyses, Alexandria VA. 1988.

[4] Coates G, Whitfield RI, Duffy AHB & Hills W, "Enabling Concurrent EngineeringThrough Design Co-ordination", 6th ISPE International Conference on ConcurrentEngineering, Bath, United Kingdom, September 1-3 1999.

[5] Andreasen MM, Duffy AHB, MacCallum KJ, Bowen J & Storm T, "The Design Co-ordination Framework: key elements for effective product development", Internationalengineering design debate: The design productivity debate, Meeting; 1st Sept. 1996,Glasgow, pp. 151-174.

[6] Malone TW, Lai K & Grant KR, "Agent for Information Sharing and Co-ordination: AHistory and Some Reflections", Software Agents, AAAI Press, 1997, pp. 109-143.

[7] Eppinger SD, Whitney DE, Smith RP & Gebala DA, "A Model-Based Method forOrganizing Tasks in Product Development", Research in Engineering Design, 6, pp. l-13, 1994.

[8] Kusiak A & Wang J, "Decomposition of the Design Process", ASME Transactions:Journal of Mechanical Design, Vol. 115, No. 4, 1993, pp. 687-695.

Dr. R.I. WhitfieldCAD Centre, Department of Manufacturing and Engineering Management, University ofStrathclyde, 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.ukFormerly:Newcastle Engineering Design Centre, Armstrong Building, University of Newcastle uponTyne, Tyne and Wear, NE1 7RU, England. Tel: +44 (0)191 222 8556 Fax: +44 (0)191 2616059 E-mail: r.i.whitfield@ncl.ac.uk

© IMechE 2001

400 ICED01-C586/114

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

DISTRIBUTED PRODUCT DEVELOPMENT - A CASE STUDY IN INTER-ORGANIZATIONAL SME BUSINESS NETWORKS

J Pilemalm, S Gullander, P Norling, and A Ohrvall-Ronnback

Keywords: Industrial case study, industrial co-operation, SMEs

1 Introduction

The globalisation increases the competition and causes many companies to live under aheightened strain. Companies are faced with completely new demands and challenges. Somecompanies are, however, creating new opportunities by increased co-operation acrossboundaries. Small and Medium sized Enterprises (SMEs) working together in inter-organisational business networks enable entirely new business opportunities by means ofaggregation of their resources and knowledge. Such networks make it possible for SMEs todevelop and to offer more complete systems and products that could not without greatdifficulties, or at all, be offered by individual companies alone. This implies a need forresearch and knowledge development in the area, especially regarding how to performdistributed development of new products.

2 Objectives

The purpose of this paper is to present the results of a study investigating how companies inbusiness networks communicate and collaborate between themselves and with customers,throughout the complete product development process. More specifically, the objective is toinvestigate factors that facilitate successful collaboration in networks, and if distributedproduct development can be applied in the Integrated Product Development (IPD)methodology, even when the team is dispersed. IPD is a concept for increasing efficiency andlearning in industrial Product Development (PD) [1].

3 Theoretical framework

In order to respond to new challenges companies have to be dynamic and fractal. A fractalcompany 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 inter-organisational business networks enables SMEs to develop and to offer more completesystems and products in virtual organisations. There are several possible ways for creation ofsuch organisations. One is when a leader enterprise builds a virtual organisation by involvingpartners to a specific business venture. A second is when one or several companies seek tojoin forces with similar partners to achieve a whole greater than the sum of its parts. A third iswhen 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 actorsin networked biomedical projects, it is indicated that there are certain factors inherent innetworks contributing to the success in PD. Examples of such factors include ambiguitiesabout authority relations, geographical dispersion, sensitivities about intellectual property, andproblems with knowledge capture and information flow. Further, the importance of differentissues 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 typeand the project scope influence the design process. Accordingly, three models based on thetype of design activities performed, are proposed: Original design that includes alldevelopment steps, and the intended product is new to the company and has no prior designhistory. Evolutionary design that is intended to development of a new product that is basicallybased 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], Thisindicates that SMEs could perform PD jointly in inter-organisational business networks.

IPD is a concept for achieving efficient PD where integration refers to multifunctionalintegration between organisational functions, hierarchical levels, activities, divisions andacross companies. The performance of IPD is characterised by parallel activities, cross-functional collaboration, structured processes, and front-loaded development [1], [7], Toperform IPD, using network structures is supposed to be a suitable organisational approach tomake 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 tocomplementary abilities as well as quality, cost and time advantages [8].

4 Research method

The research project "Distributed Product Development" (DPD) is one of several sub-projectsin a project named "New Industrial Cooperation". The overarching project aims at industrialguidance to SMEs in cooperation in PD, but also at long-lasting collaboration betweenSwedish manufacturing industry, a research institute and several universities. The researchquestion to be answered in DPD is: How should distributed product development in businessnetworks be performed to enable efficient development from idea to final product? This willbe answered through identification of important factors that, when exploited in the distributedPD, enhance the probability for obtaining the desired outcome compared to when an ad-hocdistributed PD is practiced. The question will also be answered through analysing to whatdegree and how IPD has been performed in the cases.

In this paper an inter-organisational SME business network (IOBN) is defined as a virtualcompany consisting of SMEs and connected to a regional or local network. Two types oflOBNs will be discussed in this paper: IOBN with an own product (IOBN-P), and IOBNdeveloping a subsystem as a consultant to an external customer (IOBN-S).

In order to answer the research question, three lOBNs were investigated. Approximately 25companies and organisations have been involved in the study. First several regional networkswere contacted with the aim to find and select three regional networks containing at least oneIOBN. The key persons at the regional networks were interviewed to identify and elucidatethe main actors in three lOBNs (Case A, B and C), one in each regional network. Then thepersons involved in the PD at the lOBNs were interviewed. Finally the customers wereinterviewed. 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. Theanalysis was carried out through a process were the material was structured through allocationof codes. The researchers represent different subject fields: Industrial -engineering, -organ-isation, -marketing, and -economics, which imply a multidisciplinary approach.

5 Results

The analysis indicated that some aspects were particularly important for the PD and thesuccess of the lOBNs. Those aspects are presented in three sections below. First the two typesof lOBNs are described. Thereafter factors judged as important for successful collaboration inlOBNs, 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 andFigure 2 the two IOBN-S cases. Both figures visualise the cases over time andorganisationally. In the left section of the figures the involvement of the customers, thecollaborators (e.g. C1A in Case A), and the supporting organisations (e.g. S1C in Case C) arevisualised over time. The organisations are marked as dark grey horizontal bars. Dotted linesindicate surrounding organisations that might have played some role for the project. The timewhen the main contract came into enforcement is also indicated. In the right section of thefigures, the organisation of the lOBNs and the surrounding organisations are shown. IOBN-Pare visualised with a solid rectangle and IOBN-S with a dotted rectangle. Each organisation isvisualised with a circle. The adjacent regional network is visualised with a large dotted circlewith minor circles symbolising the members.

The regional networks surrounding the lOBNs

The three regional networks were started during the 1990s. The regional network in whichCase A was found, acts in mechanical industry and has approximately twenty members. CaseB was found in a regional network that is active in the electronics industry and has only threemembers. The regional network in which Case C was found, acts in the polymer industry andhas approximately twenty members. The main goal of the three regional networks is tosupport the members, especially by creating new business opportunities. There exist differentopinions among the interviewees whether some of the specific lOBNs studied are results ofthe 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. Theinventor 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 thefirst phases of this original development. The customer, which is a government authority, hadrealised the same problem as the inventor and issued a purchasing request. To continue withthe next step it was realised by CIA that more actors were needed. Company C2A wascontacted first, thereafter C3A to C5A. The regional network (S3A) might have played a partin finding the right companies. An external independent project leader (S4A) was engaged tomanage 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 theorder, 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 previousversion of the current subsystem, which is a regulation system (Subsystem B) to specificventilation equipment. When the customer (Customer B) was planning for a new generationof the product, a dialogue was held with C1B. The dialogue ended up with a contract for anincremental design between C2B and the customer. The reason for choosing C2B was theirexperience of project leadership and of assembling similar products. One person at C2Bperformed most of the development alone. However, to some extent he had support fromC1B, C3B, the customer, some suppliers and other personnel at C2B. The result from thedevelopment 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 (CustomerC), which held the formal leadership of the development of the complete product. Customer Cdelegated the development of the mechanics (Subsystem C) to a firm of consultants (C1C) butdeveloped the electronics itself. The PD can be judged as a compromise between original andevolutionary 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 thebulk of the development work unaccompanied. However, to some extent he had support fromC2C, CSC, the customer, some suppliers, and staff at C1C. The regional network (S2C) mighthave played a part for finding the right partners. The result from the IOBN-S was judged assuccessful 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 successfulcollaboration in lOBNs are presented. The factors are intensive dialogue, geographicallyproximity, clear goals and responsibilities, complementary resources, straight businessrelations 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-Pwere all the participants were involved in regular discussions. The physical meetings werefrequent and according to the interviewees the participants worked as a real team. Thephysical meetings within the lOBN-Ss were fewer, but there was an almost dailycommunication through telephone and e-mail. Consequently there were intensive dialogues,mainly between two persons at each time. In the IOBN-P problems and possible solutionswere discussed together which led to better solutions than if the work should have beenperformed individually. The prevalent intensive dialogues in the IOBN-P indicated increasedunanimity, openness and confidence, which was not equally evident in the lOBN-Ss. Therequirement specifications were made in terms of functions rather than in technical details andthis lead to an intensive dialogue between the customers and the lOBNs. The communicationwas mainly held between the contacts at the customer and the contractor. The dialogue wasespecially intensive at the lOBN-Ss. It was mentioned that the contact people shouldpreferably possess equivalent technical competence and be on the same level, and also that thecustomer 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 CaseC in which the involved organisations were dispersed across large distances. According to theinterviewees the geographical distance affected the frequency of physical meetingsnegatively. This was not estimated as critical, but the cooperation could have been even betterwith less distance.

ICED 01 - C586/145 405

Geographical dispersed teams with less physical meetings imply increased importance ofclear goals and responsibilities. However, the distribution of the work differed between the1OBN-P and the lOBN-Ss. In the latter the responsibilities were fairly clear, which wasfacilitated through clear interfaces in the products and the subsystems. In the IOBN-P both theteam and the product were integrated to a high degree, which made clear responsibilitiessomewhat less important. Nevertheless, the activities surrounding the PD, e.g. purchasing andmarketing were clearly distributed in all the lOBNs.

The need for complementary resources was important for the lOBNs. In all the three cases theresources were complementary even though exceptions existed. In the IOBN-P the potentialorder was so big that the manufacturing resources had to be partially overlapping. Further, inCase C the designing company was replaced due to close down.

The lOBNs were based on straight business relations. This was obvious between the lOBNsand the customer as well as between the lOBNs and their subcontractors. None of thecustomers considered the network organisation form at the lOBNs as important. From theirpoint of view they made a business agreement with one single company. The main importancein the business agreement was mentioned as threefold: the function of the product or thesubsystem, the price, and the time for delivery. Previous contact and references, and personalchemistry were also mentioned, but only at the IOBN-S. Finally, ISO 9000 certification wasmentioned as important. The contractors mentioned previous contacts as important regardingtheir choice of partners and subcontractors. There was also some degree of favouritism; thecontractors preferred partners and subcontractors from the local region. The contractors'cooperation differed much between partners and subcontractors. The latter's knowledge wasmainly used in the late PD phases, and the adjustment of detail to their manufacturingprocesses was lesser than to the partners' manufacturing processes.

To the majority of the companies, the business deals were relatively great. Therefore, earlydetermination of reward and risk system was judged as important. The IOBN-P had apotential for a very large order and even larger in the future. The partners invested much timeand money in the PD, but did also receive financial support from external organisations. Thepartners 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, butthe PD was paid trough payment for prototypes. In case C the contractor had no potential for amanufacturing order, but the other partners and the subcontractors had. The customer paid perhour for the development and took the main risk of the project. This was formalised before thedevelopment began. Thus, the main risk as well as the possible profits was shared by thepartners in the IOBN-P and by the customers in the lOBN-Ss. However, the manufacturingpartners 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 thetheoretical framework.

Even though the participants in the IOBN-P knew each other the least in the beginning of theproject, the PD in this network was more integrated than in the other two lOBNs. Theinvolved persons worked as a team and thereby the companies become integrated in the actualproject. This was particularly obvious in the work just before formal deadlines to the customerand when problems had occurred. The team was very committed to its task and the focus onbringing 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 theparticipants. 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 integrationbetween individual, functions and organisations were poor. The integration was most apparentbetween 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 companyworked 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 aproblem in the lOBNs. At the frequent physical meetings in the IOBN-P there was greatopenness and the results were documented. After the order was settled the partners establisheda common enterprise and the knowledge was transferred to that. In the lOBN-Ss theinformation and knowledge handling were somewhat restricted to what each partner andsubcontractor needed. In all the cases there was a frequent communication through telephoneand 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 CaseC was following a structured process. The contractor in that IOBN had a settled process andthis was followed throughout the project. In Case A and B PD was a new experience for thecompanies. Customer B had an internal PD-process, but the contact at that companyappreciated the less bureaucratic PD performed in the IOBN, even though the lack ofexperience was a risk. In the IOBN-P the goal was to produce ten prototypes that fulfilled therequirement specification. This was focused throughout the complete PD process after thecustomer issued a purchasing order for manufacturing. Other aspects like e.g. the price-fixingwere largely secondary. In the lOBN-Ss the PD were performed more gradually with differentprototypes as goal. In all the three cases the project leader and to some degree the team settleda list of activities with a time schedule.

According to the interviews the development time, the cost and the quality have not beenmentioned as problems in the lOBN-Ss. However, in the IOBN-P, technical problems delayedthe project several times. According to the interviewees it is doubtful if the PD in the IOBN-Pwould have succeeded if the key persons were experienced in PD. The project would probablybe judged as a dead end due to the technical problems and the success it resulted in wasjudged as a consequence of a very great interest. On the other hand, some of the intervieweesrequested a more structured PD.

6 Conclusion

The IOBN-P studied is certainly a product of an entrepreneur choosing complementarypartners for a specific business venture. In one of the IOBN-S, the contractor had previouscontacts with the customer, but chose complementary partners for this specific businessventure in the regional network. There exist different opinions regarding whether thosespecific lOBNs are results of the regional network or not. To know for certain, probablyanother research method following the emergence of the lOBNs would be needed. The otherIOBN-S studied act as a united front toward the market and it is clear that such an approachmight 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 thethree cases. They are somewhat supplementary to the theoretical framework. To decide on theimportance 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 possibleprofits 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 withincremental 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 possiblereasons for this. The PD concerned an original design, the team was very committed to itstask and the team had a possibility to bringing home a large order. In addition the partnersown the future product jointly. The fact that the tendency to integrate the individuals in a teamincreased just before formal deadlines and when problems had occurred indicates that this is anatural way of working at critical situations. The integration in the lOBN-Ss was narrow andmost apparent between the contacts of the customer and the contractor and within thecompanies. This could be a result of a strong contractor, the fact that the network isdeveloping a subsystem, but also on the type of subsystem developed.

Finally, our results confirm that the project scope influences the design process. A conclusionis that the difference of design practices between companies [5] is true even between differentlOBNs. The need for maturity in PD seems to be dependent on if the IOBN is developing anown product or a subsystem as a consultant, but also on the complexity in the project. Thedegree 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 129-136

[2] Warnecke, H.J., "The Fractal Company A Revolution in Corporate Culture". Berlin,Germany, 1993

[3] Hedberg, B., Dahlgren, G., Hansson, J. and Olve, N.-G., "Virtual Organizations andBeyond. Discover Imaginary Systems" Chichester, England, 1997.

[4] McCormack, U. and Oliver, N., "Networked New Product Development in theBiomedical Industry: An Organisational Perspective", Proc. EIASM '99. Cambridge,1999, pp 771-785

[5] Carlson, S., Kemser Skalak, H.-P. and Ter-Minassian, N., "Defining a ProductDevelopment Methodology with Concurrent Engineering for Small ManufacturingCompanies", Journal of Engineering Design. Vol. 8, No. 4, 1997, pp 305-328

[6] Hietikko, E. and Parkkinen, H., "Principles and Tools of Concurrent Engineering inNetwork of Small and Medium Sized Companies", Proc. ICED '99. Munich, 1999, pp329-332

[7] Andreasen, M. and Hein, L., "Integrated Product Development". London, U.K. 1987

[8] Vajna, S., Burchardt, C. and Richter, A., "Organizing Integrated Product Developmentwith network Structures" Proc. ICED '99. Munich, 1999, pp 393-396

Jorgen PilemalmRoyal 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

ORGANIZATIONAL DESIGN - A TOOL FOR EVALUATINGALTERNATIVE EXTENDED ENTERPRISE STRUCTURES

A McKay and A de Pennington

Keywords: extended enterprise design, supply chain design, interfacing to customers,suppliers and manufacturers

Abstract

3D Concurrent Engineering (3DCE) draws upon parallels between product and supply chainarchitectures to provide insights into supply chain performance and design. In essence,3DCE argues for the parallel development of product, process and supply chain. Threedimensions from which supply chains can be viewed (organisation, technology and businesscapability) and four kinds of proximity (organisational, cultural, electronic and geographic)that are features of supply chains are provided; in integral (as opposed to modular) supplychains the proximities are close. More broadly, these proximities can be seen as indicators tothe likely success of proposed supply chain configurations. For example, data exchangebetween organisations is more likely to be successful when the organisations have similarhardware and software platforms: a high electronic proximity. This paper reports on researchthat resulted in the establishment of a software tool that drew upon learning from productdesign and data representation and applied it to the representation and analysis of alternativesupply chain structures. The purpose of this paper is to illustrate how learning from therepresentation of products, and specifically product structures, can be applied to therepresentation and design of enterprise architectures. A data model for the representation ofextended enterprise structures is presented; supply chains can be seen as paths throughextended enterprise networks. This data model has been successfully implemented in arelational database. Its use to support a prototypical software tool that allows alternativeextended enterprise structures to be visualised is discussed.

1 Introduction

Research on the operation of retail packaging supply chains has indicated that there aredrawbacks 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 leadtimes, by considering and implementing chains for the flow of information that are notnecessarily 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 theproduct and the kind of product that is being produced. These can be seen as requirements ina supply chain design process. Krishnan and Ulrich identify four kinds of productdevelopment 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 designdecisions, 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 thealternatives to be evaluated. The research reported in this paper asked the question, "Cantechniques used to support product design decision-making processes be transferred to thedomain of supply chain design?"

Research with industry sectors that produce large systems (for example, aircraft and marinevessels) has concluded that there is a need for people to be able to consider a number ofextended 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 in-service support, rather than the supply chain alone. For example, at the early stages ofproduct development, a prime contractor on a long-term project might wish to explore therisk of key suppliers becoming insolvent through a cash flow enterprise structure. Here,decision-making processes related to the configuration of extended enterprise structures, oneof which might be a supply chain structure, are needed; both representations of alternativeextended enterprise structures and tools that allow the alternatives to be evaluated arerequired to support such processes. This paper describes such a tool and its associatedextended enterprise representation scheme. The tool allows people to visualise alternativeextended enterprise structures. Its use in support of an analysis of the electronic proximitieswithin alternative supply chain structures is described. A case study is used to is used toillustrate the capability of the representation scheme.

2 Case study

The case study that is used in this paper is a synthetic supply chain based on the fast movingconsumer goods sector. It has been synthesised from a number of specific examples fromretail packaging chains. A key player in the chain is a sandwich maker that has been requiredto work, by a supermarket that it supplies, with a given package manufacturer and a givenlabel manufacturer. The supermarket demands that these suppliers will supply the packagingfor a new style of pre-packed sandwich. The sandwich maker is a packer/filler during theoperation of the supply chain. It also has overall responsibility for designing the packagedsandwiches which includes both labels and a container for the sandwiches. The supply chainis 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 asimilar 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 tocustomer). In fact, experience dictates that teams of partners are more effective in carryingout design processes than chains of suppliers. Hence, discussions within productdevelopment projects lead to questions such as, "What are the best extended enterprisestructures for the product development and production processes?" An alternative designchain structure is given in Figure 2. Here the package, label and sandwich makers worktogether collaboratively on the design of the packs of sandwiches. The dashed circle denotesa "virtual" organisation that works on the design [7]. Later in this paper, these two scenariosare modelled and their electronic proximity evaluated.

Background

Supply chain modelling and research has directed much effort towards improving theperformance and operation of supply chains [8]. Supply chain design, on the other hand, hasreceived far less attention [3]. In supply chains the key players are customers and supplierswith information, artefacts and money flowing between them. The research reported in thispaper builds upon an alternative view. It considers the notion of an extended enterprisewhere the key players are stakeholders. A benefit of taking this view is that players who aretypically considered to be outside the supply chain, for example, designers according toSCOR (The Supply Chain Council's Supply Chain Operation Reference model'), can beconsidered as a being a part of a system that is the extended enterprise. Fine [9] argues thatsupply chains should be designed concurrently with the product and the process: namely, 3Dconcurrent engineering (3DCE). A logical conclusion from Fine's work is that peoplecarrying out 3DCE will need such tools when they are synthesising and analysing supplychains in addition to product and process design tools [10]. Tools for visualising supplychains are an early step on a path towards tools to allow people to design products in parallelwith the organisations [supply chains] that will make, deliver and use them, and then evaluatetheir potential effectiveness.

2.1 Extended enterprises

An extended enterprise is a collection of organisations related to each other through anetwork of relationships. Some relationships create pathways along which things flow. Forexample, a supply chain includes paths through which goods and services flow; supply chainprocesses are what make the goods and services flow between the organisations in the supplychain. During the operation of a supply chain, supply chain processes make the flows(material and information) flow. The Supply Chain Council's Supply Chain OperationReference model (SCOR) describes four key processes for each organisation that are neededto ensure effective supply chain operation: source, make, deliver and plan. Supply chains arenot the only kind of path that exist. Extended enterprise processes in general make flowsflow around extended enterprise networks. An important factor in determining what flowsand the most appropriate pathway depends upon the stage of the product life-cycle. Differentkinds 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 typesinclude complementation (doing things that improve the product of another organisation'sproduct 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 anddecision 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 theleast risky. Alternatively the extended enterprise designer could decide to create moreextended enterprise scenarios. The research reported in this paper used the data model (seelater) to capture the alternative extended enterprise scenarios and underpin an electronicproximity tool with which to analyse the scenarios. Presently, clearly defined and rigorousmechanisms for selecting the "best" design are unclear. However, it does appear that whatconstitutes a desirable supply chain structure depends upon the nature of the flows and theproduct life-cycle process that is to be carried out. For example, if flow is a commodity andwidely available then the closeness of a customer and its supplier might be less of a prioritythan for a flow that is critical to the success of the customer's own product or process. Anearlier example highlighted the importance of life-cycle stage.

3 Electronic proximity data model

When considered as a structure, a supply chain can be modelled as a collection of relatedelements and relationships. Lee [13], for example, models a two-level supply chain in termsof the companies on each level and the relationships, in his case an information flow ofdemand data, between them. In product structures, composition relationships are typicallyused in administrative tasks (such as planning and purchasing) whereas connectionrelationships are typically used in technical tasks (such as design, planning to manufacture,manufacture and maintenance) [14]. As in product design, in supply chain design theinterfaces 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 theEXPRESS-G diagrams in this paper. In the EXPRESS language [15], entities are used todescribe the concepts that are being modelled and the attributes of entities are used todescribe relationships between these concepts. EXPRESS-G boxes represent entities and finelines between boxes represent attributes. The plain end of the fine line is placed at the boxrepresenting the entity to which the attribute belongs and the circled end is placed at the boxrepresenting the [data] type of the attribute. Boxes are labelled with the name of the entityand fine lines are labelled with the name of the attribute. Thick lines between entities are usedto show EXPRESS sub/supertype (specialisation/generalisation) structures. The "(1)'" labelmeans 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 electronicproximity 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 theorganisation entity. The organisation_deflnition entity allows a given organisation toparticipate in multiple chains whilst the characterised_organisation_definition entityallows each participation to be characterised in a number of ways. For example, theelectronic proximity for exchanging product requirements may be different to that forexchanging product definitions (such as shape models) because different computingenvironments 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 explicitlycharacterise each communication channel in the extended enterprise or supply chain. Theorganisation_E_charas entity captures the data about an organisation in a communicationchannel that are needed for the electronic proximity analysis to be carried out. Thecharacterised_organisation_definition_relationship entity allows each relationship, in thiscase communication channel, to be characterised. In practice we found a need for only onecharacterisation of each communication channel but in principle there appears to be no reasonto prohibit multiple characterisations. Similarly to the organisation_E_charas entity, there!ationship_E_charas entity captures the data about a communication channel betweenorganisations 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, aregiven in Figures 4 and 5 using the EXPRESS-1-G notation [17]. Figure 4 shows therelationships between the sandwich maker and the package maker in Scenario 1. It can beseen that each flow, that is one of product requirements and one of product definitions, arerepresented separately. This is to allow for the fact that different computing environmentsare 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 fewerrelationships because each of the flows concerned in Scenario 2 are bi-directional. Inpractice 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 electronicproximity of alternative configurations and not necessarily to reduce the number ofrelationships that are present. A key point to note in Figures 4 and 5 is that the real differenceis 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 wouldneed to be made.

Figure 4: Partial representation of Scenario 1

4 Electronic proximity software tool

The purpose of this research was to examine whether insights can be gained by applyingproduct data engineering techniques to the representation of extended enterprise structures. Ifappropriate, tools to support supply chain designer in their decision making processes [3]become a real possibility. Emphasis was placed more on the underlying representationscheme than on the calculation of electronic proximities. The software that was implementedcalculated electronic proximity by considering each defined relationship in turn. For eachrelationship 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 sameas each other and 6 if they were not the same as each other. Thus, for example, a pair ofcompanies using the same software in the same context but on different operating systemsand hardware platforms are less electronically close than a pair of companies using the samesoftware 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 wasimplemented in a relational database [Microsoft's Access] and the electronic proximitysoftware was implemented using SQL queries.

414 ICED01-C586/431

Figure 5: Partial representation of Scenario 2

5 Conclusions

There is a real need for tools that will support extended enterprise and supply chain designdecision-making processes. Research issues include identifying the key attributes ofextended enterprises and, initially at least, supporting the quick visualisation of alternativestructures. Extended enterprises are socio-technical systems and many of the issues to beresolved relate to human issues, for example trust [18], and to the dynamics of theiroperation; the latter leads to a need to link work on extended enterprise design withsimulation tools. It is not clear that extended enterprise structures can be optimised for allparticipants. However, given the appropriate tools, it is possible to build robust extendedenterprise structures that are fit for purpose. There is an intrinsic interdependency betweenan extended enterprise and the products and processes of the participating organisations. Assuch, an extended enterprise system will only perform as desired if it reflects the policies andprocesses used by the various stakeholders within the system. The research reported here hasstarted to provide an integrated modelling and analysis tool for extended enterprise supplychains. 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 Universityand the industrial partners are BAE Systems and Rolls-Royce plc.

References

[1] Christensen, C.M., The Innovator's dilemma: When New Technologies Cause GreatFirms to Fail. 1997: Harvard Business School Press.

ICED01-C586/431 415

[2] Fisher, ML., What is the right supply chain for your product? Harvard BusinessReview, 1997: p. 105-116.

[3] Krishnan, V. and K.T. Ulrich, Product development decisions: a review of theliterature. 1998, Department of Operations and Information Management, The WhartonSchool, Philadelphia, USA. p. 1-33.

[4] Checkland, P.B., Achieving Desirable and Feasible Change: an Application of SoftSystems Methodology. Journal of Operational Research Society, 1985. 36(9): p. 821-831.

[5] Warboys, B., et al., Business Information Systems: a Process Approach. 1999:McGraw-Hill.

[6] Andreasen, M.M., C.T. Hansen, and N.H. Mortensen. On the identification of productstructure laws, in 3rd WDK Workshop on Product Structuring. 1997. Delft Universityof Technology, Delft, The Netherlands.

[7] Venkatraman, N. and J. Henderson, Real strategies for virtual organizing. SloanManagement Review, 1998: p. 33-48.

[8] Towill, D.R., Supply chain dynamics - the change engineering challenge of the mid1990s. Proceedings of the Institution of Mechanical Engineers, 1992. 206: p. 233-245.

[9] Fine, C.H., Clockspeed: Winning Industry Control in the Age of Temporary Advantage.1999. Perseus Books

[10] Malone, T., et al., Tools for inventing organisations: Toward a handbook oforganizational 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 Two-Level Supply Chain. Management Science, 2000. 46(5): p. 626-643.

[14] McKay, A. A framework for the characterization of product structures, in 3rd WDKWorkshop on Product Structuring. 1997.

[15] ISO10303-11, EXPRESS Language Reference Manual. Industrial Automation Systemsand Integration - Product Data Representations and Exchange. Vol. ISO 10303-11.1994: ISO.

[16] ISO10303-1, Overview and fundamental principles. Industrial Automation Systems andIntegration - 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 EXPRESSUser's Group (EUG'93) Conference. 1993.

[18] Clegg, C.W., M.O. Gray, and P.E. Waterson, The "Charge of the Byte Brigade" and asocio-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, LS29JT, telephone: 01132332217, fax: 0113 233 2150, a.mckay@lecds.ac.uk

© IMechE 2001

416 ICED 01 - C586/431

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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 thatare more concurrent. One approach is the Integrated Product Development (IPD) Process. Aprinciple of IPD is to organise around multi-functional Engineering Design Teams orIntegrated Product Teams (IPTs). IPT members are not only multifunctional but also likely towork for different companies, have different nationalities and languages and stem fromdifferent sites of one company or even be scattered across the globe. This paper presentsresearch carried out to understand the cultural issues faced by these IPTs in the aerospaceindustry, and why culture differences are important. Existing approaches to culturalassessment are reviewed, as well as their limitations. A description of a new assessmenttechnique is presented. Based on findings from this technique the paper discusses somecultural issues faced by IPTs. It concludes with suggestions for future work and thoughtsabout how this information can be used for other means such as training, partner selection andto support distributed IPTs that are increasingly being used.

2 Background

IPTs are composed of representatives from all appropriate functional disciplines, majorsubcontractors, and customer representatives, working with a team leader to identify andresolve issues and to make sound and timely decisions throughout the design and manufactureof a product. Once on a team, the role of an IPT member changes from that of a representativeof a particular function focusing on a given discipline, to that of a team member who focuseson a product and associated processes. Getting people together from several functions isintended to promote a complete understanding of requirements resulting in superior products,which satisfy the customer needs appropriately. In the very basic circumstances IPTs ensurethat engineering and manufacturing agree with the product design. In addition, IPTsencourage the integration of customer representatives and the main suppliers to workalongside the prime contractor in the initial development phases. This is primarily tounderstand the needs of the customer to a greater extent, and to ensure that the customers andthe key suppliers are happy with a design at the outset of the development process. In anincreasingly global industry, IPTs can include individuals from different countries.

Initial investigations were carried out to understand the key issues faced by IPTs. Theinvestigations used techniques such as workshops, surveys and semi-structured interviews,involving IPT members from more than 30 different aerospace organisations. The informationcollected 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 todefine what they meant by 'culture', and identify which elements caused the greatestproblems. A large amount of literature in this area focused on cultures of different nations, forexample [1] and [2]; or organisational culture, for example [3] and [4]. The limitations of thisare that many existing models fail to consider regional cultures of nations, or organisations. Inaddition, the structure of IPTs can mean that the culture composition is more complex thanprevious models can accommodate.

2.1 Subcultures

Culture does not only occur at national or organisational levels. It is incorrect to assume thatany nation or organisation is solely influenced by a single culture. In reality there can be anynumber of subcultures, and it is inappropriate to assume one culture per organisation [5]. Bymaking such an assumption, it should not matter who describes the culture, or at whathierarchical level or geographic region or product division the individual is from, the resultingconclusion should be the same. This is unlikely to be the case. The assumption of a singleculture fails to recognise that each hierarchical level; geographic region or product divisionmay be the potential site of a distinct culture itself. This phenomenon is even more likely toapply 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 betweenindividuals. 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 someindividuals will interact with others more frequently if they share the same problems, or areworking on the same product or project. From these interactions, subcultures will develop.The division of organisations into functions and specialist areas has promoted a greatercreation of subcultures. The specialisation of functions narrows the number of employees whoare 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 teameffectiveness1 due to poor communication [6]. Effective communication between members ofan IPT is vital as it allows focus on what is important. Ineffective communication discouragesthe free exchange of ideas, up and down the product development cycle. With ineffectivecommunication comes the danger that deficiencies discovered in the downstream activities ina 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 parochialperspective neither recognises other people's different ways of working nor appreciates thatsuch differences have serious consequences. Parochialism can be observed when things gowrong and individuals point the finger to somebody else with the refrain of, "If only they hadmade it the way I had designed it." [8]. A third barrier, ethnocentricity or judging another byone'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 perceptionsof effectiveness rather than specific measures.

418 ICED01-C586/035

distortions of what is meaningful to others through one's own eyes, causing a failure tounderstand that another's ways have their own meanings and functions in life and these maybe different to one's own. Related to parochialism is arrogance, which reflects one's closure tooutside opinion [9]. Arrogance is a similar expression of an unwillingness to value andincorporate the contributions of other cultures. Ignoring these barriers has the potential toreduce team effectiveness; it creates conflict between members and causes misunderstandings,which can lead to engineering changes occurring later in the product development process. Italso prevents opportunities for recognising cultural diversity within team members. All toooften, cultural diversity is seen as an area of difficulty rather than as an opportunity to build acompetitive advantage for the team [7].

3 Culture Assessment

Whilst it is evident that differences are present between different cultural groups, and thesedifferences can be detrimental to IPTs, it is less obvious how to assess the differences andtheir impact. There are different ways that culture assessment has been carried out. There aremany different cultural assessment techniques available. The first type of culture techniques isquantitative in nature. They typically require respondents to rank, or rate their respectiveculture along a particular dimension, for example, "On a 1 to 10 scale, rank the extent ofinformation transfer within your organisation" [10]. This may involve completing theassessment twice - the first response based on the culture of the respondent's organisation, andthe second response based on the culture of another organisation. The technique can also beused to assess differences between actual and desired cultures. Other quantitative techniquesrequire respondents to allocate points between statements, awarding the highest points to thestatement 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 theinterpretations of the statements, or rating scales. For example, two individuals rating verystrong agreement with a statement may be rating it for different reasons. Quantitativeapproaches do not capture these reasons. Finally, quantitative assessment techniques assumethat the assessor (and the scale developer) fully understand that the exact item being assessedis known and can be evaluated (or quantified) using a single number. This is unlikely to be thecase due to the complexity of the phenomenon of culture.

The second type of techniques is qualitative in nature. Qualitative data contain richinformation that is often deep in content and context. Whilst qualitative information is harderto analyse, it is useful in assessing culture where contextual information is important forunderstanding meaning. It provides a basis for further exploration and identifies areas of theculture that quantitative assessment would not. An example of a qualitative assessmenttechnique is the Cultural Web [4]. This requires respondents to answer questions relating tosix 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 themhave been developed for generic use across different industries. This has a practical benefit asthe same technique can be used across many industries, but may be less reliable than atechnique developed in, and used in a single industry. The cultural factors that are importantfor 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 differentrelationships with customers and suppliers, different motivations and goals, and differentproduction characteristics. For example, the aerospace industry is a low-volume manufacturerof products with typical lead times of 10-15 years, with new products developed every 10-20years. The customer plays a strong role in product development and selects the manufacturersof the main sub-systems. In contrast, the automotive industry is a high-volume manufacturerof products that have lead times of (typically) 24-36 months, occurring relatively frequentlywith 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 theproduct, 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 EdgarSchein [12] who questioned whether the phenomenon was understood adequately. He claimedthat the label of "culture1 had been hung on everything from behavioural patterns to newcorporate values that senior management wished to incorporate into an organisation. How is itpossible to measure something that isn't understood properly? If this is the case, then one ofthe first objectives in the development of any cultural assessment technique is to understandthe 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 differencesand the creation of barriers to effective team performance, including language, motivation,values, politics, and structure. Following an extensive literature review and the identificationof 55 cultural factors creating barriers to working together, an industrial survey was carriedout to determine which of these 55 factors had the greatest impact on individuals workingtogether. A factor analysis was carried out on the data and based on the results, a five-factorframework was produced to provide a basis for understanding those components of culturethat have the greatest impact on IPTs and team members working together. The total varianceexplained by the factor analysis model was 60.649%. Table 1 presents the percentage ofvariance explained by each of the resulting five factors. The five factors of the frameworkconsisted of 19 variables from the original 55 variables, about Communication; Leadership;Practices undertaken; the Structure; and characteristics of the working Environment. Table 2presents the distribution of the variables in the five factors.

Table 1. Variance explained in factor analysis model

Factor12345

% of variance19.63715.4499.6398.1357.789

Cumulative %19.63735.08644.72652.861

60.649 (total)

The factors and associated variables were assembled into a workbook. This provided detailsof each variable and it's relative impact on the culture of the environment, including 49 openquestions relating to the variables. For example, "What is the 'working language of yourculture?"; "What traditions are present within your culture?".

420 ICED 01 - C586/035

Table 2. Variables within each factor

FactorPractices

Structure

CommunicationLeadership

Environment

Variables within the factorKnowledge sharing; Expertise; Decision making; Trust;

Roles & contributions; Motivation; Work ownershipReporting hierarchies; Values held; Structure; Management

control; FlexibilityLanguage; Approach to communicationSupport for initiative; Leadership styleStability; Politics; Goals & objectives

5 Case Studies

The workbook was partially validated using three case study applications in order to assess it'seffectiveness 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 mergedorganisations from the military aerospace sector. The merger had created a project set-upwhere individuals from both organisations were expected to work together. Seven individualstook part, four from organisation A and three from organisation B. One issue was that prior tothe merger, organisation B had been a major supplier to A. Individuals from A felt thatindividuals 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 jealousydue to changes in the way that projects were distributed following the merger. In addition, theprime customers of both A and B (pre-merger) had very different influences on the respectiveorganisations. The customer's culture can heavily influence the culture of a supplier. To alarge extent, the main customer of A tends to be defence ministries, both in the UK andabroad. The organisation is driven by (possibly dictated by) the need to develop products tosuitable design and cost for government(s) in order to retain their custom. Defence ministrieshad less direct influence over organisation B.

The leadership style of A is perceived as close to manager-centred with a desire to be team-centred, and possibly attempting to shift to a more democratic direction. The leadership styleat B is perceived as being autocratic and manager-centred to a greater extent. Within A, thereappears to be a greater focus on responsibility to the functions, whereas in B, responsibilityappears to be towards projects. The values held by individuals at B are strongly financial inorientation, i.e. Finance has the last word, and is seen as highest in order of importance. Incontrast, individuals at A tend to value 'people' aspects of the work. The main reason for thisculture was thought to be the legacy from a Managing Director of B who was known formaintaining 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 militaryapplication. The project comprised individuals from several different nationalities, butworking 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 thiswas 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' betweenindividuals of different nationalities, even in the same organisation and at the same site. TheItalian 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 byBritish members. The values of the British and Italian respondents differed. The values of theBritish respondents tended to relate to the organisation, yet for the Italian respondent thevalues were towards hard work and perseverance. The Italian respondent described howBritish people value time, and how they will leave work when it is time, rather than staying tocomplete work. This reflects the British' sequential culture concerning time orientation,identified by Trompenaars and Hampden-Turner [2]. There were issues concerning languagedifferences even though both groups used English as the working language. For example, theBritish 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 organisationworking on a military aerospace project. The IPT comprised eight individuals at threedifferent military aerospace sites. Four individuals were from site X, three were from site Yand one from site Z. The team had recently been created for a short-term aerospace projectinvolving the improvement of specifications of an existing aircraft. Findings highlighted thatdifferent sites of the same organisation have different cultures. For example, there weredifferences in leadership and decision-making styles. Individuals at site X were encouraged tobe involved with other projects and information was shared openly, yet at site Y, individualsfelt that there was very little information sharing between projects, and "people held theircards very close to their chest". One cause of the culture at site Z is the recent threat ofclosure. This has meant that individuals have operated in a flexible manner to accommodatechanges, there is little formal organisational structure, and the company has carried out workoutside of the aerospace industry in order to survive.

The differences in cultures may be due to several reasons. The first may be company heritageof 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, severalindividuals commented that "culture is in the walls", implying even if you change thepractices and processes of the people, the basic culture remains. All three sites are located inthe 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, "theyhave whippets and flat caps" (a characteristic Northern stereotype), even though the sites areonly 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 isconcerned with culture change. Whilst the desirable solution may be to change the cultures ofteam members to match other's culture, this is problematic in the context. IPTs are formed ona temporary basis and team members move to new teams on completion of the project. Inwhich 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) andappreciation, to be carried out. This would allow team members with different cultures towork 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 ofculture. The inherent nature of an IPT means that at the very least, an IPT will comprise teammembers from different functions, and major subcontractors. Increasing use of globalisationand consortiums has meant that IPTs frequently comprise team members from differentnationalities, different organisations, and different sites (especially for large organisationsoccupying 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. Thethird issue to consider is that the role of leader of an IPT may be more than simply ensuringthat 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 tocontrol how resources are allocated, how individuals behave, how decisions are made and soon. In addition, there is also an issue as to whether cultural behaviours should be encouragedin an environment in which they are not widespread. For example, a typical Europeangreeting 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 teamfrom 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 aperson on the basis of a general categorisation. It occurs when an individual is judged on thebasis of the group, to which they belong, for example, individuals belonging to a group are allseen as having the same characteristics. Mullins provides examples of stereotyping, "AllGermans are orderly and industrious" (Nationality); "All accountants are boring"(Profession). The danger is that stereotyping is a limited view of the average behaviour in acertain environment, and exaggerates and caricatures the culture of another. It also ignores thefact that individuals in the same culture do not necessarily behave according to the culturalnorm, or the stereotype [2]. The impact of customers and suppliers can affect the cultures ofteam members. In some situations, suppliers can develop cultural traits similar to theircustomer. Being dependant on major customers for business can mean that companies listento their customer's needs intently. In some cases, customer's needs and wants have become theraison d'etre of the company's philosophy, [14].

Based on the findings from this research there are implications for training programmes forawareness of the complexity of the IPT structure and it's potential effect on problems that canarise between individuals. IPT members need to be aware of these issues, the origin ofcultural behaviour and possible detrimental effects on IPT performance. In addition, there arequestions to be considered, for example, do individual differences such as personalitycharacteristics and gender have any effect on the extent to which culture differences mightcause 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 fewerengineering changes); and enhanced collaboration within IPTs. This research was carried outwithin 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 isresource consuming to spend time understanding the culture of colleagues to appreciate whythey might work differently. Tools, such as the one described, allow distributed members toappreciate culture differences and their origin. The value of qualitative information extendsbeyond cultural assessments. The data help to build scenarios to accelerate the introduction ofnew team members into an IPT. This technique may also provide due diligence potential priorto selecting team members, or to allow customers selecting suppliers, or organisationsselecting partners to assess the culture in order to favour those that are most culturally alignedto themselves. It may be more effective to chose teams to work with that are more aligned toone's own culture, to reduce the likelihood of conflict occurring.

References

[I] Hofstede, G. Identifying Organizational Subculture: An Empirical Approach. Journal ofManagement Studies, 35 (1), 1-12, 1998.

[2] Trompenaars, F. and Hampden-Turner, C. Riding the Waves of Culture, NicholasBrealey Publishing Ltd., Naperville, IL, 1999.

[3] Handy, C. Understanding Organizations. Penguin Books Ltd., Middlesex, 1993.

[4] Johnson, G. Managing Strategic Change: Strategy, Culture and Action. Long RangePlanning, 25(1), 28-36, 1992.

[5] Frost, P.J.; Moore, L.F.; Louis, M.R.; Lundberg, C.C. and Martin, J. OrganizationalCulture. Sage Publications, Beverly Hills, CA., 1995.

[6] Clark, K.B. & Fujimoto, T. Product Development Performance Strategy. HarvardBusiness School Press, Boston, MA, 1991.

[7] Adler, N.J. International Dimensions of Organizational Behaviour. South-WesternCollege Publishing, Ohio, USA, 1997.

[8] Ashkenas, R.; Ulrich, D.; Jick, T. and Kerr, S. The Boundaryless Organisation:Breaking the Chains of Organizational Structure. Jossey-Bass Publishers, SanFrancisco, 1995.

[9] Fishbein, M. & Azjen, I.Belief, Attitude and Behaviour. Addison Wesley PublsihersInc., Reading, MA. 1975.

[10] Galpin, T.J. & Herndon, M. The Complete Guide to Mergers and Acquisitions, Jossey-Bass 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 PayneSchool of Industrial & Manufacturing, Cranfield University, Cranfield, Beds MK43 OAL, UKTel: 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

SUPPORTING THE TEAMWORK BY NEW MEANS OF THEINFORMATION TECHNOLOGY

A M Kunz, S Miiller, T Kennel, K Lauche, and K Mbiti

Keywords: collaborative design tools; methodology; information technologies; productdevelopment process; design teams; computer supported collaborative work; humancreativity;

1 Abstract

With increasing divulgence of the information technology also possibilities to support theteamwork are arising. In many fields of the product development process an IT-based supportis available as for example in the design stage (CAD and PDM). However, the early stages inthe 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.

2 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 theteamwork - the concurrent engineering - urgently necessary. In many enterprise processesmodern information technologies are already used, for example in the design process and alsoin the sales process. In the early stages of a product development process, where in particularnew ideas are created, the information technology is hardly used because the current availabletechnology is not suitable to support a teamwork decisively. The early stages of thedevelopment process as a basis for a new product are based on creativity and imaginativenessin the individual person as well as in the team. At the present time the teamwork is based on apaper-based working method which is in a multiple way inadequate, however, in particularwith larger groups. Also the documentation of a session is difficult since the integration of theresults is complicated due to the unwieldy format of the paper presentations.

3 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 verystrongly on the composition of a group. Trained teams with personal experience show higherproductivity than spontaneously gathered groups. In this case social competence or differentlevels 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 ofthe 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 beprovided in a hard-copy form which must be clearly and readable. However, in most casesthese requirements are not fulfilled. Taking the protocol of a teamsession often becomes verydifficult because most of the ideas are created on flipchart papers that are not suitable for aprotocol and the flipcharts must be processed afterwards. Additional mistakes arise from thatwhich can noticeable reduce the success of a teamsession. Also very frequently informationare needed which are not spontaneously available. This results in delays of the team session.

4 Contributions

In order to examine how a new technology can be used in the early stages of the productdevelopment process to avoid the above-mentioned difficulties a room was furnished with thecurrently available technique and practical investigations about his use were carried out. Theobjective was to find out whether this additional technique is usable or leads to a technicaloverkill. In a next stage the room will be redesigned and complemented by software tools inorder to optimize the teamwork. The technology based conference environment is supposed tooffer the following possibilities: presentation from system or laptop; mixedmedia-presentation(for example video, slides, overhead projector, plans, posters, rough paper drafts); simplifiedtaking of the protocol; common sketching possibilities; smaller groups (for a short period oftime a smaller formation of groups is possible); providing of external information fromdatabases or out of the internet; integration of external participants by the use of video-conferencing; integration of conventional media and methods; possibility of mixedmode andall-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 inconnection with a touch-sensitive surface, the so-called SmartBoard. The third projectionscreen can be used for a stereoscopic projection or video.

The touch-sensitive boards can be used for sketching. The color and the pen position areregistered 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 asimplified recording and archiving because the data can be stored at any time. The touch-sensitive boards represent the common sketching-possibility where the common ideas arecreated and visualized [4]. A video-conferencing equipment allows the transmitting of pictureand sound to a remote station as well as an application sharing. This will allow tocommunicate and to work collaboratively with additional team members. Thus, it is possibleto obtain additional information from further persons and to allow a teamwork via a physicalnetwork as well as acquiring spontaneously needed information. For the visualization ofexisting objects an additional camera is installed. The camera's picture can be projected ontothe third projection screen. Small objects and prototypes can be shown to the team as well asconventional overhead slides or pictures. The technology based conference room is completedby the possibility to present videos as well as slides. With the linking of previous media it ispossible to realize a mixed-media presentation. An additional connection at the conferencingtable gives access to the projectors so that presentations can be directly carried out from aprivate laptop. The technical installation of the moderation room is completed by thepossibility to plot large scale sketches from the touch-sensitive boards as well as thepossibility for scaled printouts.

Several test were made with the completely equipped conference room. The scope of thesetest is to find out the benefits of the new conference room and the way how the persons canwork with this new technology. Furthermore it is supposed to be examined, whether previousworking methods can be moved in the new moderation environment.

5 First ResultsThe series of experiments were carried out as far as possible with realistic problems. Anessential criterion for the successful use of the conference room was the result and theduration of the session. The tests were carried out with students, with members of the instituteand with industry partners in order to receive a representative sectional view. It was essentialto the carried out series of experiments were made on real existing projects and not onartificial settings. Thus there was a real demand for moderation technique, for presentationtechnique or for the metaplan technique in order to carry out the team sessions (up to 10persons) with maximum efficiency. For the teamsession traditional means were available aswell as the described new technologies. The scope of the carried out experiments was to findout where the new technology could not be used anymore and the traditional means were usedinstead.

The working with the new technologies and the different conferencing techniques needs acertain effort. Thus the usage of the moderation room and its technology requires basicknowledge in the information technology in order to take full advantage of the room within ashort time.

6 Influence on the moderation techniques

In the following fields changes of the moderation technique arose that must be considered bythe user:

ICED 01 - C586/040 427

6.1 Writing and sketching

The writing and sketching on touch-sensitive boards distinguishes considerably from that onpaper. The recording of the pen position and color by the computer has a latency time whichcan lead to a confusion while working the first time with this device. Furthermore it has to beconsidered that the person causes a shadow onto the pressure-sensitive face when a frontprojection is used. Unlike the writing and sketching on normal paper the line drawn from thepen is only visible as soon as the person is out of the projection way. The shadow caused bythe person can be eliminated when a back projection is used together with the touch-sensitiveboard. This solution is much more expensive and requires more space for the projectionsystem.

Although conventional pens are used for writing and sketching, the time delay, which isinherent to the system, must be considered at the presentation. The delay causes quantizationmistakes when the speed of the tip exceeds the maximum value. This will result in aninterrupted line although it was drawn continuously. The user must draw consciously slowerin order to avoid those mistakes. The tests showed, that the user wasn't disturbed anymore bythe effects from the above after a short training stage. After the training phase the writing andsketching on the touch-sensitive boards were possible as fast and simple as on traditionalpaper. Thus the traditional method and the technology based method are equivalent on thisfield.

6.2 Gallery method

During a discussion the writing and sketching is done on a poster. This poster will be usedwithin the gallery method as an elaborated point when the discussion proceeds. The postersare in the person's field of view so they can refer on them if required. The gallery methodallows a parallel visualization of several aspects, which can become important in case ofcomparative discussions.

In a contrast to the above the usage of a touch-sensitive board allows only a serialvisualization of the currently processed poster. A cross-reference is only possible by pagingbackward. However, this backward paging represents a break in the moderation processwhich should be avoided as far as possible. Through the serial representation of the processedposters on the touch-sensitive boards it is not possible to compare the individual posters. Inthe 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 theposters before. Thus it is possible to generate a new poster and to represent the precedingrelevant posters simultaneously. By that the previously described break in the moderationprocess can be eliminated. Furthermore there is the possibility to print a poster on a A0-plotterand to use this printout for the gallery method.

However, the practical test of these possibilities showed that the use of two touch-sensitiveboards 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 printedposters because these modifications cannot be digitized for a later on usage. However, duringthe realization of the sessions it becomes clear that two projection screens for the realizationof a fluid moderation are sufficient. The additional plotting of the constructed posters during asession 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 findout opinions. This method also can be used for larger amount of session members. Within thismethod short contributions for a defaulted subject are written onto cards. On a commonpresentation wall the cards are arranged and combined to an entire unit. This method has theadvantage that the participants can create their ideas in a certain anonymity without beingdisturbed by other influences.

At the present time it is not possible to realize a technical supported metaplan method. Thereis no technique available to label a card, to digitize it and to displace it onto a common workarea from the participant's place. If a metaplan technique is needed for a team session it mustbe done with the use of conventional means. This causes an interrupt in the technology-basedteamwork. The results that are elaborated with the metaplan method are not digitized andmust be processed afterwards for further use. Beside the time consumption further mistakesand corruption can arise from that. Therefore the metaplan method is not feasible in the abovedescribed environment.

6.4 Presentation

Presentations normally consist of two parts. This is the performance of a preparedvisualization and the need of supplementary comments. The usage of the touch-sensitiveboards offers two possibilities: on the one hand existing PowerPoint-slides can becomplemented through additional rough drafts and comments, on the other hand complementscan 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 toadd complements on the second visualization equipment while the presentation was runningon the first visualization equipment. The usage of both touch-sensitive boards did not causeany irritating media alternation but raised the listeners attention since the line of vision couldbe changed. The presenter must get used to the functionality of the touch-sensitive boardstogether with a PowerPoint-presentation. It allows to switch to the next slide by touching thesurface. In the beginning mistakes occurred during the explanations of the slides combinedwith the human gesticulation (pointing).

6.5 Providing the information

During a session there is the need to provide additional information. The demand for suchinformation arises spontaneous and is not foreseeable. If this information requirement can notbe covered by existing materials, an information gap remains that complicates the furtherprocess of the session. With the technique installed in the conference room it is possible toretrieve information via the internet or intranet. The carried out test-sessions indicated thatmany information were already processed by the participants of a session and were providedon servers. Out of this reason the possibility of an information retrieval over a network is veryuseful. 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 oncomputers or a missing information is procured during conversation or discussion. The delaywhich arose from the procuring of the information is marginal in comparison with a delayedsession due to missing information. In total the availability of a network is very useful tosupport an effective teamwork.

ICED01-C586/040 429

6.6 Moderation

The technique installed in the conference room enables the presenter to form the moderationof a session more effectively. This is based mainly on a very good visualization of thesubjects of interest. This is of interest when a discussion is based on these objects. If theobjects are very small only a few members of the discussion can see them while all othershave to wait. This causes an unnecessary delay of the discussion until everyone has seen theobjects. The problem is eliminated in the conference room by the use of a camera, whichtakes the picture of the object and visualizes it on the third screen so it can be seen byeveryone simultaneously. Tridimensional objects can be turned by moderator and facilitatethus the recognition of specific qualities or functionalities [5]. The sketching on the touch-sensitive board can be visualized via two channels. Thus, the problem of hiding the sketchesby the presenter is solved. The second projection screen is not masked and allows the listenersto perceive the visualization and the relevant explanation synchronously.

The available technique enables the presenter to choose a fitting visualization device in orderto present almost any information without any spill [2] [3]. However, this will result in newrequirement profiles for the presenter, which are totally different from the conventionalmoderation techniques. An example will be the performed visualization with the use ofprojectors. This requires a partial or completely darkened room unlike a visualization onposters. Thus, the presenter and his gesticulation becomes less important and an importantinformation channel between the presenter and the team-members is disabled. The classicalrules of the presentation technique can only be relatively used in the technology basedmoderation environment. The usage of the devices is an additional task for the presenter andrequires also new rules in the moderation.

The result of the series of experiments was that persons without experience in moderationtechniques are unable to handle both, the presentation and the technical equipment. In thiscase no benefit arises from the new technology. The available technique encourages thepresenter 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. Theseteams have to process exactly defined subject areas. The teamwork is followed by apresentation for the other workshop members. For the effective realization of the teamwork itis 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 isprohibited by the high costs. Due to the missing technical equipment conventional means likeblackboards, flipcharts etc. are used instead. Using these conventional devices causes that thetechnological chain is disturbed. This implies that identical devices must be used for a laterpresentation of the teamwork in front of the group. From that a break of the technologicalconcatenation results in a deactivation of the technological support. If a further work of theplenum is needed based on the results of the teams the plenum has to use the same means. Inorder to use the results of the teamwork later on the conventionally generated posters have tobe post-processed and digitized. This results in additional work combined with a restructuringof the poster. Since any change can corrupt the poster's contents it is not recommended tomake any modifications.

430 ICED 01 - C586/040

Furthermore a teamwork distinguishes considerably from a presentation. Beside thecompletely different working methods another essential difference is that the work area ishorizontal during a teamwork while it is vertical for a presentation. The available touch-sensitive 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 frequentlytouch the sensitive surface at several places. Placing the hand on the pad during the writing orsketching will cause digitalization errors. This problem was recognized very fast by the testedpersons. However, the above described mistake occurred again and again. The reason for thisis that the required single-point input for the touch-sensitive board is not corresponding to thenatural movement of the human being. The unnatural way the write or to sketch on ahorizontal surface results in a cramp and in fast exhaustion. Combined with that is a clearreduction of the efficiency of a group [1]. Another difference between a teamwork and apresentation is that the teamwork uses other techniques than a presentation, for example it isnot 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 technologyof the touch-sensitive boards. Therefore the touch-sensitive boards cannot be used for such ateamwork.

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 creativegeneration 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 arenot suitable to be taken into a protocol without any modification. Large scale documents likeposters have to be reformatted or post-processed in order to make them suitable for theprotocol. Very frequently important context information is lost and a later reworking of asession becomes complicated. In addition the preparation of such posters is time-consumingand cost-intensive. In part important posters are linked into a protocol as a photograph. Inorder to keep the document size small for an electronic forwarding the pictures are embeddedwith low resolution which complicates the later on use.

The carried out series of experiments showed that the possibility of the immediate printout ofthe posters is regarded as very useful. These printouts can be full-scale by the use of a plotteror they can be scaled down in order to realize smaller formats for a printer. In part the digitaldata which were created in the plenum could be taken over directly into the protocol. Anessential advantage of the digitizing by the touch-sensitive boards consists in archiving andreworking. All written or sketched inputs are in a digital form and can be distributed forexample 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 processingprogram. All the required tasks could be done by the tested persons very easily and result in ahigher effectiveness of the carried out sessions.

7 Conclusions

The different situations of a teamwork were examined, both the work in the plenum as well asthe work in smaller teams. The carried out investigations made clear that the technology ofthe 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 ashort training phase the further use of these elaborations as well as the usage of the peripheralunits 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 conventionalmethod 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 veryhelpful. On the other hand other techniques as for example the metaplan technique or theteamwork cannot be supported very well by the new technology. The currently availablecomponents only can be used in particular fields. However, they do not offer yet acomprehensive solution for the realization of a complete meeting.

8 Future work

Future work will aim at eliminating the recognized problems. This will be in particular therealization metaplan technique as well as the realization of an teamwork supported by newinformation technologies. A continuous technological chain over an entire teamsession issupposed to be achieved. On the one hand this can be done by better software- and hardwareand also in the networking of existing components. On the other hand the construction of newinteraction devices and procedures have to be realized. In order to keep on optimizing themoderation technique the writing and sketching on the two touch-sensitive boards must beexchanged between the two projection screens as desired. This will realized by extending thecurrently used software.

9 Acknowledgements

The above project was funded by the Swiss research fund KTI 4475. 1PMS. We thank inparticular 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; ,,CreatingShared Understanding through Collaborative Deisgn"; University of Colorado, Boulder;CHI-Proceedings

[2] Thomas P. Moran, Patrick Chiu, William van Melle, Gordon Kurtenbach; JmplicitStructures for Pen-Based Systems Within a Freeform Interaction Paradigm";Proceedings og CHI 1995

[3] Jason A. Brotherton, lanak R. Bhalodia, Gregory D. Abowd; ,,Automated Capture,Integration, and Visualization of Multiple Media Streams"; Proceedings IEEE 1998

[4] Peter Troxler, Kristina Lauche, Kyeni Mbiti; ,,The Use of Interactive Boards forCollective Design Processes"; International Design Conference, May 23.-26, 2000

[5] Orfeo Niedermann; ,,Nutzenanalyse des Einsatzes der Virtual Reality Technologie inder Failure Mode and Effect Analysis"; ETH Internal Research Report 1999

© IMechE 2001

432 ICED 01 - C586/040

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

THE IMPORTANCE OF INFORMAL NETWORKS TO EFFECTIVEDESIGN 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 theorganisation inside the functions are? ....A (product development) project or a set of projects arenothing more than conversations and relationships with people. How you have those conversationsand 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 theway in which this work has highlighted the importance of informal networks of organisationalrelationships in design management. The 'Working the Boundaries' project was an eighteenmonth project funded by the Engineering and Physical Sciences Research Council and basedin the Wolfson School of Mechanical and Manufacturing Engineering in LoughboroughUniversity 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 theformal organization. Researchers and practitioners have concentrated on changing formalorganizational structures often to make them more project-focused and have introducedformal processes and procedures for developing new products. This is especially evident inthe 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]. Althoughsignificant individual project success has been reported through the adoption of thesemethods, 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 inprojects either because of low volume or scarcity of resources to perform them.

• organizational learning issues - functional specialists allocated into project teams maygradually lose the distinguishing features that initially made them so desirable.

One response to these undesirable sides affects may be to further change the formalorganization but, given the changing external and internal environment this may be animpossible 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 notthe prime determinant of product development success. Instead she identified that thecompanies who sought to overcome formal boundaries wherever they were positioned werebetter at developing products successfully. This immediately begs the question of whatmechanism can be used to overcome formal organizational boundaries and whether it can beharnessed in some way to improve the way design is managed and hence assist in improvingproduct 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 organizationalnetworks.' The phenomenon of informal networks within organisations has been widelyrecognised for some time [13],[14],[15],[16]. Some work has been undertaken to characterisethese networks. For example Boutty [17] has identified how different types of relationshipshare R&D information across organisations. However the role of informal networks indesign management remains largely unexplored and no-one has yet addressed the issue ofwhether 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 environmenti.e. to establish if other organisational factors than formal structure had an impact onsuccessful design management

• If formal structure was not of prime importance, to identify what organisationalphenomena was associated with 'working the boundaries' to result in productdevelopment 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 automotivedesign and manufacturer who agreed to act as a case-study subject for the 'Working theBoundaries' project's investigations. The project sought to undertake a longitudinal analysisof twenty years of small and medium-sized automobile product development in case-studycompany. Using a time-line approach, it aimed to map the major product introductions andthe 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 thechanges 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 theperformance of design managment and organisational characteristics present at that time.

Because the research team were highly uncertain as to what they might find when undertakingthe 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 useda 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 particularproblems were encountered in generating a time-line for the case-study:-

Measuring the success of design management The research team began by trying to findobjectively 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 askingindividuals concerned with a particular project to rate it from 1-5 (where 1 representedminimum performance and 5 a maximum level of performance) against the followingcriteria:-

• 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 individualto 'mark up' a project in which she or he was concerned. Given the alternative (i.e. not tryingto measure at all,) the team decided to proceed with this imperfect measurement of designactivity.

ICED01-C586/272 435

Matching structure to project. The second difficulty encountered was matching a formalstructure with a particular design and development project. The formal structure was neverstable. 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 someprojects found themselves operating, over time, with completely different organizationalstructure. The research team only mapped significant step changes in organisational structureassociated with significant resource re-allocations.

4 Research Findings

A simplified time-line for product introductions during the past twenty years is given inFigure 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 engineeringresources were allocated to a particular project and reported to a project director. The finaltype of formal organizational structure adopted was a 'lightweight' approach where a projectgrouping of primarily commercial and some limited engineering resource was maintained butthe vast majority of engineering resource was organised functionally. When looking at theorganisational success of these different structures, a first glance may suggest that a formalproject structure was most successful. However this viewpoint must be tempered with thethematic 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 promotedinformality and allowed the interviewees to use the informal networks to achieve tasks. Thefollowing quotation illustrates this:-

"Networking, very important. I mean that's how project teams ... that's how the whole companyworks. 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 theright 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 fora common aim and we're moving forward. "

This suggests that the period of success during the 'project' formal structure was due toflourishing informal networks. The following quotation illustrates how informal networkscould be used to improve performance:-

"If there's a problem, say it's a body problem, and you know this problem, there's probably twoways of getting the problem sorted out. Maybe it's a very big problem the body falls apart after 1000miles or something. Then using the formal organisation structure you 'd contact the head of thisdepartment and he would contact his junior who 'd contact the guy who does the work and then he 'dprepare a report for him and he 'd prepare a report for him and he'd give the information back toyou.. The way Chinese whispers work....it means, you know, that you've lost something. You lose theproblem definition, you don't quite get the answer to the question that you wanted to ask. You 've gotto know that man. If you know him, you can ask him that question. You can have a much broaderconversation than saying I've got a problem, please fix it. You can understand why is the problemthere ? He understands why you are concerned about it "

Using the thematic analysis of the interviews, it was possible to characterize the informalnetworks that were designing and developing new products. (See Table 1). It is important toremember that the interviews were non-directive (i.e. they were not specifically asked aboutthe themes outlined).

Table 1: Thematic Analysis of Interviews

The informal organisationis important to successfulproduct development

The informal organisationis formed formrelationships

Informal networks last

Productive relationshipsneed trust, commonexperience a social contextand respect

of interviewees stressed the importance of theinformal organisation to successful product development33% said the formal structure had little impact on projectperformance

80% stated that a network of productive relationships wereneeded for product development success

60% recognised the longevity of relationships over severalprojects

40% highlighted the importance of trust to productiverelationships33% highlighted the importance of common experience(e.g. similar educational background, similar career history)25% highlighted the importance of social context (i.e. therelationship is not solely work-based)15% highlighted the importance of respect

ICED 01 - C586/272 437

If the findings of the 'Working the Boundaries project are viewed in the conjunction withHenderson's work, it is the informal network of relationships that overcomes the boundariesof formal structure. Individuals use informal networks to obtain and disseminate informationand 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 needfor circumspection. The results were case-study based which immediately limits their widerapplicability and the research methods adopted were, of necessity, subject to simplification. Inspite of these limitations, the 'Working the Boundaries project' fulfilled its aims within itsresearch boundaries. It identified that other organisational phenomena than formal structurewere associated with successful product introduction. It identified these as informal networksof relationships. The conclusions of the 'Working the Boundaries' project can be summarisedin the following statement of speculative theory:-

• Successful introduction of new products is associated with using the informalorganisation

• The informal organisation is a network of relationships initiated by an individual that re-allocates tasks and re-directs information

• These informal relationships are strengthened by trust, common experiences, a socialcontext and, to a lesser degree, respect.

• These informal relationships are long lasting and survive may changes in the formalorganisational structure

The implications of this speculative theory are immense. They suggest that successfullymanaging design may be much less about formal 'managing' (in terms of directinginformation flows, allocating tasks and identifying formal structure) and much more about'letting go.' Managing design successfully may mean providing individuals with the skillsand opportunities to enhance their own networks of relationships and allowing individuals touse their own networks.

Further work is needed to confirm the findings of the 'Working the Boundaries' project on amuch wider scale. This needs to not only to investigate other design and development projectsin the pharmaceutical and automotive sectors but also to widen the industrial sectors involvedin research Given the potential cultural sensitivity of informal networks, it would also beextremely 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 managementtool. This would enable organizations to assist individuals in developing and enhancing theirown personal networks during the design process.

438 ICED 01 - C586/272

References

[1] Clark KB and Fujimoto T, "Product Development Performance:Strategy . Organizationand management in the world auto industry". HBS, Boston Mass, 1991.

[2] Wheelwright, S.C., Clark, K.B.. Revolutionizing Product Development: Quantum Leapsin Speed. Efficiency and Quality, 1992, (Free Press, NY)

[3] Kusiak A Wang J "Efficient Organizing of Design Activities." International Journal ofProduction Research v31 pp 753-769, 1993

[4] Eppinger AD, Whitney DE Smith RP Gebula D "A Model -base Method for OrganizingTasks 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. DesignCouncil/Gower, 1996

[6] Shina S G (ed). Successful implementation of Concurrent Engineering products andprocesses. New York: Van Nostrand Reinhold 1994.

[7] Shenas D G and S Derakhshan. Organisational approaches to the implementation ofSimultaneous 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. PhDThesis. The CIM Institute, School of Industrial and Manufacturing Science, CranfieldUniversity, UK 1995.

[9] Francia, A, Macintosh, The Market, technological and industry context of businessprocess re-engineering in the U.K. International Journal of Operations and ProductionManagement, v17 n4 pp344-364 1997,

[10] Sobek DK, Liker JK and Ward AC, Another Look at How Toyota Integrates ProductDevelopment, Harvard Business Review, July-August 1998

[11] Cusumano MA and Nobeka K Thinking Beyond Lean: How Multi-project Managementis Transforming Product Development at Toyota and Other Companies. The Free Press. ,1998,

[12] Henderson R, Managing Information in the Information Age Harvard Business ReviewJan 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 HarvardBusiness Review Januray February 2000

ICED 01-C586/272 439

[17] Boutty I, Interpersonal and Interaction Influences on Informal Resource ExchangesBetween R7D Researchers Across Organisational Boundaries. Academy of ManagementJournal, 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, pp1-11, ISSN 0954 4054.

Corresponding Author's Details:

Naomi Brookes PhD DICLecturer - Wolfson School of Mechanical and Manufacturing EngineeringLoughborough UniversityLoughboroughLeicsLE11 3TUUnited Kingdom

Tel: +44 (0)1509 227668Email: n.j.brookes@lboro.ac.uk

© IMechE2001

440 ICED 01 - C5 86/272

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

MANAGING UNCERTAINTY IN DESIGN COMMUNICATION

M K Stacey and C M Eckert

Keywords: Ambiguity, uncertainty, design information management, design teams,collaborative design tools, computer supported cooperative work.

1 Introduction

The design of complex engineering products involves communicating design ideas andspecifications - requirements, constraints, functions, parameters, behaviours, structures andcomponents. These ideas are often exchanged when still tentative, imprecise and incomplete;moreover the forms in which they are expressed can be imprecise and ambiguous. Inconversations, sketches, gestures and words are used in combination to disambiguate eachother, and designers convey their degree of commitment to ideas by modulating phrasing andtone of voice [1]. But in large-scale design processes, the different elements of designs alsoneed to travel through space and time, to places where misunderstandings can have severeconsequences. How can engineers separated by space and time avoid misunderstandings andmake effective use of the uncertainty and provisionality inherent in design idea development?

2 Uncertainty in design communication

In any team designing activity designers need to express ideas for parts of the design that areprovisional, imprecise or incomplete. This is obviously true for early conceptual design. Earlyin the design process designers expect that some information is provisional and may questionthe status of parameter values and other decisions. But designers have to deal with uncertaininformation and provisional proposals at all stages in the design process. This provisionalityand imprecision is usually apparent to the participants in meetings where ideas are putforward, though there is plenty of scope for misunderstandings. But coping with uncertainty ismore problematic in the interactions between separate tasks and activities dealing with relatedaspects 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 effectiveuse of provisional and uncertain information. In the design of complex products, designersneed to made decisions when they cannot assess their consequences; and the designersresponsible for mutually dependent aspects of the design need to influence each other'sdesigning 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 amanageable 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 theprocess; 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 externalrepresentation of the design, such as sketches, drawings, CAD models and prototypes.Moreover, communication between design activities is largely through artefacts such as CADmodels, drawings and specifications; they often convey information between designers withdifferent expertise and sets of concepts for thinking about designs, who read them in differentways [see 4]. Often these representations are ill suited to expressing imprecise and provisionalinformation. Many companies feel that once the entire organisation uses CAD models todesign and communicate all their problems will be solved, but contemporary CAD systemsrequire precise values, and do not support imprecision or other uncertainty information [butsee 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 earlyconceptual design, where design ideas are typically vague, provisional, imprecise andincomplete. In design conversations sketches, gestures and words are used in combination toexplicate and disambiguate each other [6, 7, 8, 9]. The participants in joint designing usuallyget rapid feedback on whether they have been understood (though clarification is a majoractivity within meetings). So they can interactively negotiate an understanding of each other'spositions, as well as negotiate about decisions, before the (provisional or imprecise) decisionsare represented in precise-seeming forms [8]. Designers use rhetorical techniques forargumentation, including subtleties of phrasing and tone, to modulate the degree of belief theyexpress 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 individualaspects 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, orlater. Resolving conflicts between different aspects of a design is often an important activity.

Designers who receive messages and specifications and interpret graphic representations needto 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 withwhat they have done [see 10]. Design handover situations still exist in many industries. Evenif a handover is accompanied by a meeting, the recipients usually get little or no indicationabout what aspects of the design are fixed and essential and which are mutable; and they mayonly become aware of problems once they are working on their own. They thus have muchless scope for interactively negotiating a common understanding of the situation with theircolleagues, and so depend much more on clear and complete design specifications. Asproducts become more complex their development becomes more multidisciplinary andincreasingly more international. Despite the best efforts of groupware system developers, jointdesigning in virtual meetings across different locations remains cumbersome, and is hard tomake 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, andsymbolic or deictic gestures [see 9 for examples]. What referents are available depends on theinterpreter'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 needfor the recipient to recognise graphic codes and ascribe the intended referents to words andsymbols. Representations of designs are abstractions in which aspects of the design are notfully specified. Understanding how much of what is not shown is fixed, and what can bevaried, is as essential as understanding the explicit content of a representation. Alternativeinterpretations of the omitted elements of a design are made possible by uncertainty ormisunderstanding about the interpretive conventions to be applied to a representation, as wellas the context in which it is embedded and the assumptions the generator makes about howthe gaps will be filled in. Thus it can be ambiguous by omission. In other words, what isimplicit in any representation depends on the interpretive skills of the recipient and the extentof 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 distinguishbetween intended imprecision and poor drawing, or between a qualitative placeholder and arelatively exact depiction, or between a simple form drawn roughly and a more subtle formdrawn more accurately [10, 11]. One sketch or drawing often stands for a whole space ofpossible designs, but the viewer and the creator cannot know whether they interpret this spacein 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 constituteaccurate and unbiased representations of the generator's understanding of a design isproblematic: people don't mean exactly what they draw. Idiosyncrasies and poor drawing intheir sketches and diagrams bias interpretation by others towards different central meanings aswell as different judgements of imprecision and provisionality.

While the reasons for decisions are usually apparent to the participants in joint designingactivities, they can be opaque to other readers of design representations. Understanding thereasons for decisions is often essential for interpreting the uncertainty of design information,as well as for interpreting omissions. Methodologies and computer systems for processmanagement place increasing importance on recording the rationales for decisions, as part ofmanaging 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 currentlyinfluential view that ambiguity (more narrowly defined as the availability of more than onequalitatively distinct interpretation) is beneficial in design communication, and that aiming touse computer tools to create unambiguous descriptions of designs is a discredited enterprise;this we doubt [10]. However Minneman argues that designers sometimes do exploitambiguity. Nonetheless joint designing is very different from communication betweenactivities; 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. Ifone 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 inturn can lead to delays in the design process. Many tasks are mutually dependent, becausedifferent aspects of the design influence and depend on the same parameters. Designmanagers can use methods such as Design Structure Matrices [13] to identify the informationdependencies between tasks and find the shortest design process requiring a minimum amountof provisional information. Design Structure Matrices also make it possible to identifyclusters 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 toconverge to compatible parameter values in a tightly integrated design process [2, 3].

Planning design processes to use uncertain information has three conflicting goals: tominimise development time; to minimise the risk of starting tasks with provisionalinformation; and to exploit provisionality and imprecision in solutions to underconstrainedproblems in optimising other aspects of the design. To meet these objectives designers need toidentify those tasks that can be undertaken with provisional information (for example it wouldnot make sense to start finite element analysis with estimates). They need suitable ways toestimate parameter values. And they need to find ways to communicate which decisions andparameter values are fixed and which are provisional, and how far they can be modified.

3 A typology of forms of uncertainty in design

Greater conceptual clarity about the different forms of uncertainty is needed both forunderstanding human design behaviour, and for planning and managing design processes toachieve better coordination between design activities. The following concepts areconceptually distinct and potentially useful for interpreting what design actions arecompatible with the current state of the design. This typology is discussed with more carefulattention to the conceptual status of the different uncertainty concepts in [10].

• Precision. How exactly the aspect of the design is specified. (Does x=10 mean9.998<x<10.002 or 8<x<12?) Less quantitatively, how far the details of the representationare 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 possibleacceptable choices, or shows a central value in a quantitative range. (A sketch or diagramoften represents an entire space of possible designs by showing a relatively concretetypical design. The interpretation of what is a typical case varies between individuals.)

• Commitment (the opposite of provisionality). The degree to which the project iscommitted to keeping this aspect of the design the way it is (and conversely, how easily itcan be changed to meet other needs). Representations of designs such as sketches ofteninclude elements embodying provisional decisions (or even non-decisions) to provide acontext for other elements with a greater degree of commitment.

• Sensitivity. How far the aspect of the design can be changed without significantlyaffecting the rest of the design. (Analyses of sensitivity include the consequences ofchanging it more than that.)

• Input Confidence. The degree to which the inputs and assumptions on which the aspect ofthe design was based are stable and reliable.

• Understanding. The extent to which the user has sufficient information and expertise todecide the form of this aspect of the design from the input information. Hence, the degreeto which an aspect of the design can be relied as being satisfactory in relation to theparameter 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 theirideas. However designers' perception and phenomenological experience of uncertainty iscertainly often more wholistic and conceptually messier, for instance in the modulation ofsubjective degree of belief (confidence x commitment?) [see 1]. What uncertainty informationengineers and other designers can, in practice, both use and pass on is a significant openresearch question. Clarkson et al. [2] argue from extensive experience of industrialengineering 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 thescope for further designing. Similarly, uncertainty about these factors (as well as about whatthe values of parameters or other choices are) causes doubt about how to proceed with adesign. This is the consequence of vagueness. Ambiguity in design communication is theavailability of interpretations as qualitatively different alternative models, either forindividuals, or for those different people with different knowledge and interpretive skillswhose interpretations are relevant to the task or situation.

4 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 outpartly in parallel; and to avoid premature closure of design decisions resulting from imposinga linear sequence on tasks that could achieve better results if treated as interdependent. In allthese situations all team members must understand in which way information is uncertain, andwhat is the likelihood and scope of possible variation. To do this managing uncertainty mustbe treated as an integral part of managing information flow through a design process.

• Supporting informal channels. Many studies of complex organisations have found thatinformal communication channels are vitally important and often poorly understood [forinstance 14]. Communication between the people who need to exchange informationshould be easy and efficient, but is often blocked by the social organisation of the designprocess [see 15]. When a design process is restructured, for example when parts of it aresub-contracted, it essential to identify the information that flows through informal contactsto ensure that it is not cut off. Meta-information about uncertainty that is never formallyrecorded is sometimes an important part of this.

• Understanding task dependencies. Understanding how different aspects of the designare mutually dependent, and what design activities can and cannot achieve with impreciseor provisional information, is an essential first step towards planning the interactionsbetween design activities that are needed for achieving an effective sequence of tasks.This includes making decisions about the priorities of parameters, and providing for theexchange of provisional information between activities so that they can convergeiteratively to a compatible design.

• Assembling negotiation groups. This leads to the question of who needs to be involvedin a design activity to ensure that all the relevant issues are considered, and how thedesigners responsible for one task should interact with their colleagues who are affectedby their decisions. Therefore it is important to establish who needs to meet for rapidnegotiation and informal briefing; and who needs to be provided with meta-informationby 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 qualitywithout adversely affecting lead times, and locally, in that the communication ofuncertainty information by individuals must not impose a burden on designers that isonerous or not clearly justified. Endless meetings often take up a lot of the designers' timeand stop them from working productively on their own.

• Composition of design teams. How team members interpret information depends on theirbackground and experience. The more diverse they are the more likely they are to bringnew ideas and insights into the process, but the less likely they are to understandambiguous information in the intended way or know how widely to interpret uncertaininformation. Members of task teams who understand connected tasks can anticipate andjudge the exactness and commitment of the other tasks' outputs.

• Assessing the power of design representations. Designers and their managers must beaware of what can be expressed in a certain design representation, and how differentpeople will read it. All representations make some aspects salient and obscure others.

• Assessing the role of the design representations. Representations of designs serve tostructure the design process [4], sometimes in ways that their creators are only partlyconscious of, for example when faults in specifications are used deliberately to force faceto face communication [12]. Understanding how involvement with the design is organisedaround CAD models and other information artefacts will help understanding howuncertainty information is used.

• Coordinating understanding. Designers with different expertise and awareness ofcontext will read sketches and representations of designs differently. They are likely tointerpret gaps in incomplete descriptions and indications of provisionality and imprecisiondifferently. However this can be alleviated by coordinating understanding, not just bynegotiating over individual designs, but by developing a vocabulary of terms with agreedcompatible 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.

5 Computer systems for communicating uncertainty clearly

Computer support for communication in design has concentrated largely on facilitatingremote real time communication, thus supporting handling uncertainty indirectly by enablingthe use of speech, gestures and sketching, with rapid feedback, in situation that otherwisewould be dealt with by telephone or by sending messages. But computer systems can alsoenhance the effectiveness of message passing and communicating through designs.Nevertheless the human designers still need to make sure that their colleagues can understandthe degree and type of uncertainty they wish to communicate.

• Increasing the bandwidth of asynchronous message passing. One strand of researchaims to use remote meeting technology for sending messages using the full resources offace-to-face conversation (sketching, gesturing and referring to objects in theenvironment, 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 communicationcould be enhanced by enabling designers to create more exact or detailed designinformation cost-effectively, or by solving technical problems for them [see 12]. Systemsthat generate designs from user specifications, or guided by user selection, can producedesigns that are technically correct and certain at a certain level of abstraction. We discusselsewhere the role of generative systems in design creativity and communication, arguingthat automatic design systems can facilitate creative designing and can fit naturally intosome commercial design processes [17]. We present a technological solution to some ofthe communication problems in knitwear design caused by ambiguity and conflictingindicators of uncertainty: a garment shape design system that uses mathematical modelsand 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, andquick and easy methods for adding annotations to CAD models and other representationswould make indicating appropriate degrees of uncertainty substantially easier, and hencemore likely to prove cost-effective in practice.

• Planning interactions between tasks. We are developing Signposting systems to supportdesign planning that break task dependency loops and coordinate interdependent activitiesby exploiting estimated and preliminary parameter values. The first systems useconfidence 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 currentlyexploring how a much wider range of uncertainty information might be used to guide taskplanning and task selection in further Signposting systems [3].

Acknowledgements

This research was supported by the EPSRC rolling grant to the Cambridge EngineeringDesign Centre, and by GKN Westland Helicopters Ltd and Lotus Engineering Ltd. We aregrateful 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 DesignTeams: 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.

[2] Clarkson, P.J. and Hamilton, J.R., "'Signposting', A Parameter-driven Task-basedModel of the Design Process", Research in Engineering Design. Vol. 12, pp. 18-38,2000.

[3] Stacey, M.K., Clarkson, P.J. and Eckert, C.M., "Signposting: an AI approach tosupporting human decision making in design", Proceedings of the ASME 20thComputers and Information in Engineering Conference, University of Maryland,Baltimore, USA, 2000.

[4] Henderson, K., "On line and on paper", MIT Press, Cambridge, MA, 1999.

ICED 01 - C586/516 447

[5] Guan, X. and MacCallum, K.J., "Adopting a minimum commitment principle forcomputer-aided geometric design systems", in J.S. Gero and F. Sudweeks (eds.),Artificial Intelligence in Design '96. Kluwer, Dordrecht, Holland, 1996, pp. 623-639.

[6] Bly, S.A. "A Use of Drawing Surfaces in Different Collaborative Settings" another linefor this.

[7] Tang, J.C., "Listing, Drawing and Gesturing in Design: A Study of the Use of SharedWorkspaces by Design Teams", PhD Thesis, Department of Mechanical Engineering,Stanford University, Stanford, CA, 1989. Xerox PARC report SSL-89-3.

[8] Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies ofGroup Engineering Design Practice", PhD Thesis, Department of MechanicalEngineering, Stanford University, Stanford, CA, 1991. Xerox PARC report SSL-91-22.

[9] Neilson, I. and Lee, J. "Conversations with graphics: implications for the design ofnatural language/graphics interfaces", International Journal of Human-ComputerStudies. Vol. 40, pp. 509-541, 1994.

[10] Stacey, M.K. and Eckert, C.M., "Against Ambiguity", Computer SupportedCooperative Work, in press.

[11] Stacey, M.K., Eckert, C.M. and McFadzean, J., "Sketch Interpretation in DesignCommunication", 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 andComputing Solutions", Computer Supported Cooperative Work. 2001.

[13] Eppinger S.D., Whitney, D.E., Smith, R.P. Smith and Gebala, D.A., "A Model-BasedMethod for Organizing Tasks in Product Development", Research in EngineeringDesign. Vol. 6, pp. 1-13, 1994.

[14] Medland, A.J., "Forms of Communications Observed During the Study of DesignActivities 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 EngineeringCompanies: 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 distributedand 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: anempirical approach", Artificial Intelligence in Engineering Design, Analysis andManufacturing, Vol. 13, pp. 303-320, 1999.

Martin Stacey Claudia EckertDepartment of Computer Engineering Design Centre

and Information Sciences Department of EngineeringDe Montfort University University of CambridgeMilton Keynes MK7 6HP, UK Cambridge CB2 1PZ, UKPhone: +44 1908 834936 Phone: +44 1223 332758Fax: +44 1908 834948 Fax: +44 1223 332662mstacey@dmu.ac.uk cme26@eng.cam.ac.ukwww.mk.dmu.ac.uk/~mstacey www.eng.cam.ac.uk/~cme26

© IMechE 2001

448 ICED 01 - C586/516

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

MANAGING THE INTEGRATION BETWEEN DESIGN, RESEARCH, ANDPRODUCTION IN THE AUTOMOBILE INDUSTRY

H V de Medina and R M Navciro

Keywords: design management, product planning, design integration, design teams

1 Introduction:

The way companies design products is widely recognized as crucial to their success. Thecompanies are being challenged to achieve an integrated environment to develop theirproducts and are acquainted that their success is strongly dependent on their ability toorganize, to process and to learn from information that is related to the product developmentcycle. In fact the development of a new product is nowadays part of a global system ofinnovation that actually supports the ongoing industrial restructuring for the years 2000's. Anintegrated strategy for technical, social and cultural change inside the companies is promotinga revolution from the shop floor to the R&D bureau, based on new forms of designingmanagement 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 carmanufactures' and suppliers, and so the automobile has been reinvented, as it embodies aninvisible 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 reducingthe supplier base, as well as enlarging the role of the first rank suppliers in the design of newproducts. Furthermore, partnerships between suppliers and carmakers are established since thelaunching 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, forkeeping and sustaining their market share, were focused on technical and organizationalinnovations, specially concerning the reduction of the time lag between conception andcommercialization of new models. A wider range of options among standard cars and a greateffort on improving the quality and reducing environmental impacts were the main goals.

These objectives were reached by integrating research, design, and production as parts ofdifferent fields of knowledge, in a multidisciplinary system represented by the disseminationof simultaneous engineering methods for the whole company. By doing so the distancebetween research and production has been drastically reduced, avoiding back and forth effortsthat usually take a lot of time and money from the governments, enterprises and society ingeneral.

A number of case studies on automobile industry were developed from the middle seventiesup to the nineties. There are still many long lasting international research projects aiming toevaluate and enhance technological and organizational innovation such as the ULASB (ultralight 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 Companyin the world has its own research driving innovation named "Product Engineering for GMAdvanced 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 newprogram. At the onset of $350 million EVl program 150 people -including GM engineers,manufacturing engineers, material engineers finance representatives, and suppliers - trainedand practice over six months period on design for assembly dynamics. (...) Training timeallowed product development teams to address assembly requirements up front (...) if wedidn 't design for assembling considerations the EV1, than the plant layout would be radicallydifferent - probably twice as large and more complicated".

The introduction of new materials in Renault cars followed this pattern: a team of materialexperts, product designers and production engineers have worked side by side in order todefine the requirements for new advances in the materials field. This is the core idea claimedby the so called Concurrent or Simultaneous Engineering where a cross-functional group ofexperts from all relevant disciplines that affect the project, are supported by computertechnology and communication systems. "Concurrent Engineering represents a way ofconducting the design work where the various activities related to the product realizationprocess 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 isdone through early release of partial design information within the team in order to allowdownstream preliminary considerations just from the beginning.

For materials producers, for instance auto-parts suppliers and automobile manufacturers thekey factor for succeeding in the next century seems to be the continuous and largercooperation keeping themselves side by side defining together requirements for new advances.And the coordination of this network during the development phase of such complex productas 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 oldones. The shortcomings of this approach were that it did not profit from the functionalintegration opportunities enabled by new materials processes. During the late eightiescarmakers had implemented the engineering approach, and took advantage in reducing thenumber of parts in a vehicle by integrating functions embodied in new parts. Boujut andJeanet [3] give to us a good example of how hard is to involve suppliers from the beginning ofa product development and how crucial is to create instruments to a cooperative type ofcoordination for the so called "interface actors".

In fact this choice was enabled by a process of global innovation that can be defined as theresults of an integrated system of car designing from R&D, to production level redefining allphases 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 partsproducers, electronic systems dealers, and, together, they have to rethink globally theconception of new cars balancing technical performance and environmental impacts, from thebirth 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 theassembly to the disassemby specifications to enhance the recyclability of the automobile as awhole. And they have to do this as fast and as "innovatively" as possible in order to becompetitive for the next century.

This means that companies are being challenged to achieve an integrated environment - whatthey call "plateau project" in France - to develop their new products in order to compress thedesign cycle and improve project effectiveness. So the costs of the design phase seems to beincreased by the incorporation of R&D activities as well as the investments done on pilot andindustrial plants. Actually, design activities were enlarged including, in a broader view, fromthe first marketing idea till the end of car's life, passing by R&D, prototypes; vehicleengineering, up to final assembly, "disassembling" and recycling. Furthermore, they have topass through all those phases together with their partners and always keeping the final clientin mind, as the Clio project schematic view shows to us [see the picture at the end of thisarticle].

2 The Automobile life cycle: Designing for innovation

In the last twenty years, the automobile industry established a new pattern of innovation andproduction management that incorporates systematic and continuous technological advancesand that enables organizational evolution as well. As a result, the innovation process is gettingmore 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 thedesign activity was enlarged in order to cope with innovation requirements from productresearch to the industrialization phase. Moreover, technological and organizational change isnow part of the same process of global and continuous innovation supported by flexible newcar's projects. In this context, technological and organizational learning is enabled, by meansof this integrated environment, where design activities are developed and managedsimultaneously [4].

In this scenario partnership is a key word. Different kinds of knowledge are shared by theautomobile designers and suppliers, and a multidisciplinary know-how has been created as aresult 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 theirfirst 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 abetter way of life, a place to live in, to work in, or a tool for leisure? For the MIT definition acar 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 isrecognized by its shape but not by its technological and social complexity. We would say thatit is not one product but multiproduct conceived and assembled as a jigsaw puzzle. And thisgrysaw puzzle is not a regular one, which is formed by articulated parts, because in the case ofthe automobile these parts are not only articulated but also integrated in a synergic way soevery little detail affects the final result [5]. In this sense Clark and Fujimoto [6] have a betterdefinition: "a car is a complex 'fabricated-assembled' product, comprising a large number ofcomponents, functions, and process steps. " These authors have pointed out the diversificationof 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 andhard 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 findnew technology in brakes and suspensions, engine control systems and materials andelectronics "[9, page 8]. This is a good picture of a two-decade effort in speeding innovationsto bridge the technological gap of car industry compared to the high-tech sectors, such as forexample aeronautic, space, and electronics. These sectors were the pioneers in the use of newmaterials. 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 thanever, materials research and development is critical for satisfying customers. Now, as fromthe dim beginning of this proud industry, the role of materials people is often backstage. Theautomobile designer will always be creative. Many ideas and design have been spawned, onlyto 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 morecomfortable, safer, easier to drive, and environmentally friendly. To meet these needs, theindustrial project of a new model has to be «alive» in order to incorporate the continuoustechnical advances that can provide new functionalities to the car. This is achieved by meansof an integrated design environment where simultaneous engineering methods are the keymanagement tool employed. This new pattern is no more a top car makers issue, as it used tobe two decades ago, it is now widely spread throughout automobile world companies as aphilosophy of work organization to keep their competitiveness by means of continuousinnovation strategy. The redrawing of the project coordination as well as its physics andorganizational basis allowed the car companies concentrating on what differentiates themcompetitively. This strategic choice that demands a hard job on coordinating internal andexternal partners-actors' contributions, as can be confirmed by the Renault Clio project andthe Technocentre story that we have studied.

3 Managing the Designing Integration for the New Renault Clio

This successful story was written by 600 persons that have shared an integrated engineeringenvironment called "plateau-projet", physically located at Renault Technocentre andsupported by updated technology in communications that enabled cooperative andsimultaneous work. The design group was formed including people of inside and outsideRenault, such as partners like GE Plastics and Omninun Plastiques. GE was in charge of thedevelopment of a new composite for car's wing use. So it is also the story of the Noryl 974, anew polymer-based composite developed during the project result of the partnership betweenRenault, GE and Omninun Plastiques, which would be the wing's producer.

The New Clio was designed at Technocentre Renault, considered by SIA -Societe desIngenieurs Automobile- the most advanced research center for automobile R&D. By all theindicators of technical and economical evaluation this project overpassed the Renaultmillestones 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 goalsestablished 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 apool of sponsors and permanent collaborators who believe that working together in tightnetworks is the only way to do the best job they can. The architecture of the Technocentre wasconceived to permit people to work as they were playing together,e.g. acting as synchronicallyas possible. They are functionally placed in order to get easily all the information orcollaborations needed in all phases of a new car project. Everything was planed to facilitateeveryone's job and to increase overall efficiency. The three main blocks of this complex aresited in order to put the progressive phases of the development of a new vehicle side by sideor in the same sequence they are suppose to follow to. So engineers, managers, techniciansand highly skilled workers combine all their competencies working on researches, designers,product/process, quality, information etc. and purchase all the specialists needed for cardevelopment. The first building contains the advanced engineering and design units; thesecond one at the heart of the Center houses the project department and the project platformteams, surrounded by the Vehicle Engineering and the Research Department as well as thePurchasing Department; the third is the Prototype Building Center where a new productdevelopment ends by having the project specifications validated at manufacture level. Otherfacilities such as laboratories for materials certification and quality control are also part of thisResearch-Development and Engineering (R&D&E) complex.

In a word, the Technocentre is a tool designed to aid research, as defined by Renault corporatecommunication in the special issue of Renault Magazine R&D. The same source states whatwe had already seen during the time we had been there: "The concept of this Center wasRenault response to the key strategic challenge of reducing the development time for newvehicles to 36 months by 2000 and 24 moths subsequently, and ultimately saving at least 1billion French Francs (150 million Euro) on the development costs of each new vehicle. TheTechnocentre 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 toTechnocentre to work on the prototype and to assemble the first 30 cars at the mini plant theyhad 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 newautomated 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 AirtonSenna plant in Sao Jose dos Pinhais near Curitiba in Brazil. It comes in 7 versions concerningthe engine specifications and the fuel systems adopted: four gasoline versions (1.0 -only forBrazil- 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 anew 1.0 16 V for Brazil market, which associates a 1.6 regular engine performance to a lowergasoline consumption. [14] Besides in Brazil Renault is also doing some high tech research onfuel 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 betweenauto makers and suppliers and also promotes new forms of flexibility for industrial innovationonce 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, enginesystems and materials to meet new environmental requirements as well as to make it moreperformance and cost effective. While the discussion at the European Parliament to establishEuropean Directive on end of life Vehicles was still taking place the New Clio was launchedin 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

Results

3,3 billions of Francs

4,2 billions of Francs

12%

25%

19%

6 hours

25%

20%

37%

15%

12%Change rate: USS 1.00 = 6.00 FFSource: Medina 2000 [2]

These successful results were obtained by means of a new style of project management the socalled the "plateau project" where all the groups in charge of each automobile systems workedtogether at the conception, design, prototyping and assembly line. Outside partners sharedeven the patents obtained as was the case of the Noryl 974 for the Clio wings. And asmentioned before, this project is still alive and is now being improved by an internationalgroup including Argentine, Turkish and Brazilian engineering teams that had joined theFrench team at Technocentre.

4 Concluding Remarks

Managing design for innovation was the main strategy adopted by the world car companiesregarding all these requirements integrating activities such as R&D, design, prototyping andindustrial production.

Although different actors are affected to this context the coordination of internal and externalpartners is crucial to the success of the project. The best trajectory for keeping competitivemarket share is to work in simultaneous parternships for R&D, design, and engineeringactivities up to the industrial level. Working in network partners share risks and profits andalso get more innovative solutions to reach the sustainability of the automobile for one morecentury.

454 ICED 01 - C586/400

This is surely a great opportunity for the less developed countries' automotive plants to getinto design activities, which up to now have concerned only the headquarters bureauemployees. Especially for Brazil we think that is important to get into new projects designingfrom the very beginning to participate at the materials selection as well as the research forinnovative technical solutions. The only way we have to do so is to establish long term R&Dpartnerships with the carmakers, as Renault and COPPE/ UFRJ have been doing since 1999concerning materials for fuel cells engines.

References1. 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 thepurchasing 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 DevelopementofProducts 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 19986. Clark K.B., Chew. W.B. and Fujimoto T., «Manufacturing for Design: Beyond the DichotomyProduction/R&D», in SUSMAN, G.I., (editor), Integrating Design and Manufacturing for CompetitiveAdvantage. 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 lavenirRenault" 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, N14, October 1999.10. Birch S., «Design, development and globalization> in Automotive Engineering. July 1996, pp.80-87.11. Boyer R., Freyssenet, M., "The world that changed the machine: some conclusions; successfulfirms 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 AutomotiveEngineering. 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, emL'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 inthe 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 ReviewMay-June 1993, USA.18. Naveiro, R.M. and O'Grady, "A Concurrent Engineering Approach for Desing Assistence ofCasting 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.

456 ICED 01 -C586/400

©With Authors 2001

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

RESEARCHING THE THINKING PROCESS IN DESIGN TEAMS - ANANALYSIS OF TEAM COMMUNCIATION

J Stempfle and P Badke-Schaub

Keywords: Prescriptive models of the design process, thinking process, design teams

1 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 productdevelopment. A similar sequence is postulated for general problem solving processes incognitive psychology [3]. Our research reveals, however, that the actual thinking process ofdesign teams seldom matches the postulated step sequence. Despite the fact that the thinkingprocess does not follow this postulated step sequence, regularities can nonetheless beobserved that shed light on the "natural" thinking process of design teams. A two-process-theory of thinking in design is being proposed capable of explaining the thinking process wehave observed empirically.

2 Theory

Team communication in design teams can be differentiated with regard to two communicationfocuses, 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 mustalso structure their own interaction process (for example, teams have to decide in what ordersubtasks are to be addressed).

Content

Goal Clari f icat ion

*Solution Generation

Analys is

*Evaluation

1Decis ion

*Control

UnderlyingBasic Thinking Operation

Exploration

' Generation

- - - - - Comparison - -

Selection

Process

Planning

1Analysis

1Evaluation

1Decision

+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 asimilar 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 beproposed. 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 canbe described in similar terms, with the same basic thinking operations underlying bothprocess- and content-related activity. Concerning content, the above step sequencedifferentiates between actions focused on the goal space (goal clarification) and actionsfocused on the solution space (all of the remaining steps).

Two of the four basic thinking operations proposed above, generation and exploration, arealso stressed by creativity researchers Ward, Smith and Finke [5], who in their GENEPLOREmodel propose generative and explorative processes to be the main ingredients of creativeactivity. Both generation and exploration of ideas serve to enlarge the solution space. In orderto work out a solution to a given problem, however, design teams must also carry outoperations that serve to narrow the solution space. This narrowing of the solution space isdone by comparing one or more solutions to each other and to the requirements of the taskand by selecting the most viable option.

The steps above are arranged in an intuitively compelling order that matches the step-modelsproposed 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 tofrequently interpolate between the different steps in various ways. The aim of this research isto investigate whether transitions between the steps are arbitrary, or whether systematictransitions can be found that frequently occur in design teams.

3 Research MethodsIn this paper we present results from one field study and three laboratory studies. In the fieldstudy we have investigated a design process in a German automotive supplier. A team of fourpeople working on a joint task has been observed over a period of six weeks. In the laboratorystudies three student teams majoring in engineering have been presented with a complexdesign task that they were to solve in a one-day-period. The communication observed in thestudies has been recorded and categorised by means of a multilevel coding system. The toptwo levels of the coding system correspond to the main communication focuses and thedesign steps that have been described above. Communication in the team has been analysedsequentially in order to investigate the underlying thinking processes of the team.

4 Main findings

4.1 Distribution of utterances among the categories

Figure 2 displays the distribution of utterances in the four groups among the two majorcommunication 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 amongthe main categories results. This distribution can roughly be described by the "2/3-rule": In2/3 of their communication design groups deal with the content whereas 1/3 of the groupcommunication aims at structuring the group process. Similar results are reported fromproblem-solving groups in non-design contexts [6].

On the level of steps in the design process, the distribution of utterances among the steps isquite similar in the four groups as well, with a medium correlation between the distributionsof .98 between the four groups. The following figure displays the average frequency of designsteps 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 ofcontent (15%) and process (5%).

ICED 01 - C586/215 459

Regarding the pure frequencies of the communication categories, the observed design groupscannot be very much differentiated. On the other hand, differences in performance and styleof the groups exist that apparently cannot be explained by the findings reported so far. Thequestion that remains is how do groups go about in their design process? What are thesimilarities 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 categorieshave been analysed. The question to be answered is: Is team communication "chaotic" in thesense that any sequence of categories is likely to appear or are there regularities, with onecategory systematically following after a specific other category? In order to answer thisquestion, the transition probabilities between all of the categories have been calculated andthen compared to the baselines of the categories. If, for example, content analysis occurs in42% of all team communication, but after a content analysis in 65% of all cases anothercontent analysis follows, this means that sequences of content analysis are highly likely tooccur in team communication.

The following figure displays transition probabilities between the two communication focusescontent and process (average of all four groups). In the figure, a connection that ends with anarrow 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 transitionthat is significantly less likely to occur compared to the base rate. The first number behind theconnection 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 allfour studies, transitions within the same communication focus are highly likely to occurwhereas transitions between the two communication focuses are highly unlikely to occur. Onaverage, teams spend 6.3 utterances on content-related communication before switching toprocess-related communication, whereas sequences of process-related communication have anaverage duration of 3.2 utterances before the group switches to content-relatedcommunication. These findings reveal that the design process in teams is best described by aconstant interweaving of content-directed sequences with process-directed sequences, both ofsome - but different - duration.

460 ICED 01 - C586/215

In the following analysis of transitions between the design steps, we focus on content-relatedutterances 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 orderto 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 aresignificantly 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 transitionwithin the same step is highly likely to occur. The proposed design steps thus seem to be stepsindeed in the sense that groups tend to spend more than one utterance on the same step beforemoving 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 repeatedinterplay of analysis and evaluation thus seems to be at the core of the collective thinkingprocess in the laboratory groups. While analysis enables the teams to widen the solutionspace, evaluation serves to narrow it down again. The constant interpolation of analysis andevaluation might enable the groups to keep the size of the solution space at an acceptablelevel.Of special importance is the fate of solution ideas. When a new solution idea is beingproposed, the team's immediate reaction often decides on the acceptance or the rejection ofthe idea. Regarded from a methodological perspective, one would expect new ideas to befollowed by a thorough analysis. What one would not expect is an immediate evaluation. Infact, creativity techniques such as brainstorming [7] explicitly prevent groups from prematureevaluation. Our results show, however, that groups frequently do not follow such recommen-dations, but do evaluate solutions immediately without prior analysis. In three of fourobserved groups, a new idea is highly likely to be followed by an immediate evaluationwithout prior analysis. Only two (because the lab group 3 shows both loops) of four observedgroups frequently progress from solution generation to analysis.

From a theoretical viewpoint, an immediate evaluation of a solution idea without prioranalysis must be regarded as problematic. Two errors are likely to occur. One is prematurerejection 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 toproduce 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 becomesobvious. A second error that is likely to result from a premature evaluation of solution ideas isthe premature adoption of a solution that proves problematic later on. A complex design taskis comprised of many different requirements and constraints, often too many for people tokeep in mind. Thus, a crucial constraint may be forgotten, with a false positive evaluation of asolution idea resulting. Both errors are grave. In the first case of premature rejection of asolution idea, an ingenious idea may be discarded and lost for the group. In the second case ofpremature adoption of a problematic solution idea, groups may spend considerable timeworking 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 weexplain the proceedings of the three of four observed groups?

5 A second look at the step-by-step-paradigm: A two-process-theory of thinking in design

We do, in fact, propose that the observed sequence of solution ideas being followed byimmediate evaluation is not simply an error committed by some teams, but that this processrepresents the "natural" thinking process teams adopt by default. We will thus call thesequence of solution generation - evaluation process 1. As a reason for this proceeding ofteams, 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 donot strive to find the best of all possible solutions, but rather strive to find a workable solutionwith minimum effort. In a first, quick screening process, the number of possible alternatives isthus immediately reduced to a few remaining options. In the same manner, the prematureevaluation of solutions in design teams may serve to a priori limit the solution space to ahandful of promising alternatives. This behaviour can thus be explained by the tendency ofteams to spend minimal cognitive effort on the problem. We do not propose that teams strivefor cognitive economy consciously. A limited memory capacity and the fact that ourconscious thinking works in a serial, not in a parallel mode, forces us to reduce problems tosmall chunks and to limit the number of options we consider. In problem spaces of little ormoderate complexity, process 1 will frequently be quite successful. In problem spaces of highcomplexity 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 proceedingdifferent from process 1 has been observed. In these teams, solution ideas were frequentlyfollowed by analysis before an evaluation took place. We will call the sequence of solutiongeneration - analysis process 2. Out of four observed teams, two teams frequently employedprocess 2 (lab study 2 and 3). The performance of these two teams has been ratedsubstantially higher by independent design experts, who had no knowledge of the hypothesispresented in the paper, than the performance of the two teams who primarily employedprocess 1 (field study 1 and lab study 1).

Process 2 violates the principle of cognitive economy, since teams using process 2 will mostlikely spend time on the analysis of solution ideas that are later on being discarded. If this isthe 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 ideaswithout coming up with a workable solution, the team may be forced to re-analyse thesolutions that have already been discarded for the lack of alternative solution ideas, thusswitching from process 1 to process 2. Beach [9] has observed a similar process in decision-making tasks, with subjects conducting a second screening process with a relaxation in theconstraints if the first screening failed to produce an acceptable alternative. The lack of newsolution 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 ofthe groups one team member frequently contested solution ideas that others had alreadyaccepted. 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 groupmember kept uttering one solution idea repeatedly although the team had already decided todrop the idea. After the fifth re-analysis of the solution idea, however, the idea was finallyaccepted by the team. Disagreement thus seems to enhance analysis, a result that is alreadyimplemented 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 usedcreativity techniques such as brainwriting, thus consciously separating the processes ofsolution generation, analysis and evaluation. This approach enabled the team to avoidpremature judgements. Many creativity techniques suggest suspending judgement, thusallowing oneself to explore even "off-the-wall"-ideas. The use of such techniques may help totransgress from process 1 to process 2.

Self-reflection: We agree with Schon [10] in stating that self-reflection is the key to successfuldesign for both individuals and teams. Self-reflection may lead teams to consciously realisethat 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 bythemselves. 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 theteams we have observed. The teams seemed to be rather reluctant to criticise their own actionsand thinking. This may be caused by the fact that if a group member criticises the team'sapproach, this may be perceived by others as a threat to the team as a whole. In the fewinstances where we have observed such criticism in the observed teams, the reactions of theteam have been unfavourable. We therefor conclude that if self-reflection is to occur in teams,it must be actively encouraged.

6 ConclusionsThe results and interpretations presented in this paper have important implications for theeducation and training of designers. While we agree with Schon [10] that conventional designmethodology [1,2] with its strongly scientific approach is counterintuitive to manypractitioners and therefore difficult to employ in practice, we are convicted that sole relianceon 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 thedesign task. Solution ideas are often quickly being evaluated without careful analysis, apremature 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 simpletasks, it will create problems when dealing with tasks of high complexity. For such tasksprocess 1 should be replaced by process 2. Solution ideas should be analysed carefully beforeevaluation takes place.

In order to achieve this end, we suggest educating design teams in the active and conscioususe of self-reflection and in a new way of using design methodology. Teams should not useany methodology "by the book", but should be capable of flexibly using any method ortechnique suitable to their momentary needs. What we observe is that it is not knowledge thatis lacking, but competence. This competence can best be perceived as "meta-knowledge", theknowledge about how to use what you know. Self-reflection and meta-knowledge shouldbecome prime objectives in the future education and training of design teams as it iselaborated for the critical-situation approach by Badke-Schaub [11].

References:

[1] Pahl, G. and Beitz, W. "Engineering design". London, Springer, 1984, 1995.

[2] VDI Design Handbook 2221, "Systematic Approach to the Design of TechnicalSystems and Products". Dusseldorf, VDI-Verlag, 1986.

[3] Dorner, D., "The logic of failure". New York Metropolitan Books, 1996.

[4] 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.

[5] Ward, T. B., Smith, S. M. and Finke, R. A., "Creative Cognition", in R. J. Sternberg,Handbook of Creativity. Cambridge, Cambridge University Press, 1999

[6] Fisch, R., "Eine Methode zur Analyse von Interaktionsprozessen beim Problemlosen inGruppen" [A method for the analysis of interaction processes in problem-solvinggroups], Gnippendvnamik. 25, 1994, pp. 149-168.

[7] Osborn, A. F., "Applied Imagination - Principles and Procedures of CreativeThinking". New York, Scribner,1957.

[8] Beach, L. R., "Four Revolutions in Behavioral Decision Theory." In M. M. Chemers &R. Ayman (eds.), Leadership Theory and Research. Perspectives and Directions, SanDiego, Academic Press, 1993.

[9] Ehrlenspiel, K., "Practicians - How they are designing? .. and Why?" Proceedings of theICED '99. Miinchen, 1999, Vol. 2, pp.721-726.

[10] Schon, D. A., "The Reflective Practitioner: How Professionals Think in Action". NewYork, Basic Books, 1983.

[11] Badke-Schaub, P., "Group effectiveness in design practice: Analysis and training by acritical-situation-approach", Psvchologische Beitrage. 41, 2000, pp. 338-355.

Dipl.-Psych. J. StempfleDr. P. Badke-SchaubUniversity 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 DESIGNICED 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

1 BACKGROUND AND OBJECTIVES

The last few years have witnessed a renewed interest in various typologies to classify thedominant or preferred behaviors (cognitive and social) of engineering designers during theproduct development process. See for example research on p-designers (high experience andlittle or no training in formal design methodology) and m-designers (low experience withtraining in formal design methodology) conducted by Gunther et al [1]; research on therelationship of individual styles of problem solving to representations in the design process byEisentraut et al [2]; research on the relationship between the diversity in the personality ofteam members and design performance by Wilde [3]; study of how individual particulars suchas theoretical education and demand for quality affect the outcomes of critical situations inindustry by Frankenberger et al [4]; behavioral and electrophysiological study of effect ofexperience (novice vs. expert) on design problem solving by Goker [5]. Coincidentally, thisrenewed interest comes at a time when new technologies, which increase our capacity toobserve designers in action, have become widely available. Among the new technologies thathave come into recent use by researchers are the video camera, the functional magneticresonance image scanner, and the computer. Furthermore our ability to process the observeddata has also improved, such that we can better determine the relevance and predictiveaccuracy of these typologies. These improvements in the instrumentability of design teamssuggests that in future we will be able to build better models of the workings of design teamsand formulate hypothesis which can be readily tested and validated. This paper is conjecturaland represents an attempt to plan future research by building on past empirical work in thecontext of modem tools.

Today we compose teams primarily based on the background experience in a given field ofknowledge and the task requirement. For example we may compose a team consisting of twoelectronics engineers and one mechanical engineer. This kind of composition, based ondomain 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 otherhand a composition that considers the cognitive style of the individual members, theirtemperament, their response to stressful situations, and the pattern of interaction with otherteam members is analogous to one based on the "chemistry" of teams. The objective of thispaper is to explore a future scenario in which such a science can be applied to real worldsituations. A priori this exploration will be based on three key ideas. First is to select acommonly observable design phenomenon. We believe this will keep us grounded in designpractice and help in prioritizing our research questions. Second is to build on the "observe-analyze-intervene" research methodology [6]. This methodology is a form of action researchthat 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 drawon the results of empirical studies we have done and other related studies in coming up withtestable hypothesis. Based on our previous work [7,8] we were struck by the high number ofconcepts 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 intosymbolic models, which can then be easily shared and manipulated. We believe this approachwill make it much easier to consolidate our findings and develop our understanding. In therest of the paper we elaborate on each of these ideas using concrete examples. We will thenconclude by reflecting how such a science of design teams as we propose could be applied tofuture design scenarios.

2 Classic design problem: "Requirements Deviation"

Our first idea is to choose a commonly observable design phenomenon. We believe thisstrategy will appeal to practicing engineers and thus make it easier for us to find subjectswithin this population. Furthermore we believe that grounding our theories in practice willgive us an important criteria for prioritizing our research questions. Figure 1 illustrates acommon problem we believe most designers are familiar with. This is a problem in whichover the course of time the request of the client becomes transformed into an artifact that failsto meet the client's needs.

What the clientrequestedDay 1

What marketing thoughtthe client requestedDay 10

What engineering thoughtmarketing said the client requestedDay 15

What productionmanufactured for the clientDay 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 thisdeviation or "creep" from the original intent. In other words we would like to makepredictions 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 predictionsabout the performance of design teams. We believe our research approach using acombination of multiple observation methods and simulation-based analysis is the necessaryand sufficient situation to address such a complex issue. We will elaborate on the specificelements of this approach in the next two sections.

466 ICED 01 - C586/477

3 Research Methodology

The "observe-analyze-intervene" method is an iterative approach to research that emphasizesthe development of interventions as a way to perturb a system and test underlyingassumptions. Illustrated in figure 2, the method begins with the observation phase whereby areal world phenomenon is observed and recorded. In the next phase, the data collected isanalyzed and interpreted. This interpretation is then used in the third phase to inform thedesign of new tools and methods that will impact the behavior observed in the initial realworld situation.

Figure 2. The Observe-Analyze-Intervene methodology, through its intervention step allows a complex systemto be perturbed and reveal hidden assumptions.

The cycle is then repeated in such a way as to deepen one's understanding of the real worldphenomenon and, refine or change the tools and methods that were earlier introduced. Themethod has been very useful to us in the design of computer and communication tools tosupport design work and we believe it offers a practical way to develop a science of designteams.

As we discussed and thought about the new technologies mentioned earlier (video camera,functional magnetic resonance scanner, and computer simulation) we realized that essentiallyall 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 itslimitations. For example video/audio recordings were useful for observing external actionsand audible utterances, but were of limited use when it came to knowing anything about thenature of the designer's thought process. Brain imaging would allow observation of theinternal 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 adesigner's beliefs, motivations, and attitude, but nothing about what the designer actually doesin practice. We shall now describe each of the three primary observation methods in turnusing illustrative examples from empirical work.

3.1 Video Observations

Effective communication between engineering design team members is essential for highperformance in product development. In turn effective communication depends on successfultransfer (sending, receiving and processing) of information. This information may range fromdata and facts to creative ideas. Previous work by Felder and Silverman has shown thatindividuals 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 describeindividual 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 indesign teams. Figure 3a shows a sample profile for an individual in the information receptiondimension.

468 ICED 01 - C586/477

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 learnvisually. 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 receivinginformation and their methods of sending information. It was initially anticipated that eachindividual's mode of presenting information would match his or her preferred mode ofreceiving information, and that this match would result in improved communication. To studythe congruency (or incongruency) of how individuals prefer to receive information and howthey go about sending information an experiment was designed and conducted. Theexperiment consisted of four teams of engineering educators engaged in a design exercisewhich was videotaped. Their information reception preferences are shown in Figure 3b.

Results based on analysis of the video tapes and individual Learning Styles Inventoriesshowed that most participants preferred to receive information visually and engaged indrawing very little during the design exercise. If the definition of "visual communication"was expanded to include using drawings, communicative gesturing (i.e., using hand gesturesto describe a physical object or action), using hardware, and referencing hardware, visualcommunication went from comprising an average of 3.8% of the design time to an average of21.1% of the design time. This means that a large majority of the communication wasmismatched 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 ofinterviews and questionnaires to complement our video-based observation is imperative. Fromthe types of data that could be gathered through these methods we can learn more aboutindividual attitudes and beliefs. Not only will this be important in explaining behaviors weobserve, 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 beenthe degree of resolution (2D versus 3D) and the invasiveness of the technique. Goker, M. atDarmstadt University for example conducted an electroencephalography study to comparebrain 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 magneticresonance 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 venousblood increases in the region of activation; 2) when a human is placed within a magnetic

resonance field, the increased blood flow causes an increase in magnetic resonance signalintensity.

The resulting techniques of brain imaging essentially allow us to explore structure-functionrelationships in the brain i.e. how activities in distinct neural processing come together toperform complex tasks such as reasoning, reading, remembering, and visualizing. In recentyears, a number of physiological studies, which have shown strong implications for designperformance, have been reported in the literature. In a more recent study at the StanfordCognitive Neuroscience Laboratory, the researchers were able to identify specific brainactivities that differentiated between visual experiences, or images, that were laterremembered 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 subjectsare representatives of the marketing department. Consider therefore the situation in which werecorded the brain activity of the subjects during the design exercise, where they aregenerating and refining a space of images that describe a potential solution to the designproblem, and a week later, we have them describe this space of images to another set ofparticipants representing the engineering department. Brewster et al's work should potentiallyenable us to know the strength of the memory of the images for each marketingrepresentative. Conceptually then, this will enable us to predict which representatives willhave a higher probability of relaying incorrect information.

4 Computer Simulation

We see from the foregoing that the number of variables that would be required in a science ofdesign teams could be very large. We would definitely make simplifying assumptions buteven when we do this, we still need to keep track of the variables we eliminate, and therationale for each assumption. In earlier work, we used a computer simulation program namedvirtual design team (VDT) to model and simulate the project performance of an engineeringorganization [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 ouradaptation 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 variablesand organizational variables affect the duration and quality of an engineering project. Actorvariables include elements such as the skill of the actor with respect to a particular task, herpreferences for using certain communication devices during task execution and her positionwithin the organizational hierarchy. Task variables include a description of the level ofcomplexity 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 ofinformation processing in firms [12] and heuristics for estimating the duration of tasks andquality of decision making during the execution of a project. These heuristics focus on theprocess by which the first line actor handles exceptions. In general, there are three options:doing nothing (default delegation), reporting to a colleague (lateral communication) orreporting to a supervisor (vertical communication). In communicating with the colleague orsupervisor, 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 thecommunication policy within the organization. The consequences relate to how the choicesaffect 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 intervalbetween 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 unansweredcommunications and number of uncompleted rework. When these numbers are high, qualityof work is judged to be poor. For our purposes, we define a product development process as aseries of team meetings inter-spaced with individual work and in the next section we willdescribe a hypothetical situation in which we combine our three observation methods toestimate 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 aperson 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; theimage invoked in the receiver's mind could be the same as the senders, very different, or thereceiver 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 variableshas an attribute of quality, we can proceed to explore how quality can be measured in eachcase. Transmission, verification, and confirmation quality could be determined by comparingthe input image with the output image. Alignment is found by comparing the mode in whichthe information is sent by person A with the preferences for reception of person B. Forexample, reception preferences lie along the continuum from visual to verbal. Send modesare speech, sketches, communicative gestures, using hardware as a simile, referencingsketches, and metaphoric speech or some combination of two or more of these modes whichcan 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 beingcommunicated using a factor that is the product of the qualities of transmission, attention,reception, alignment, verification, and confirmation. Using the same model we can alsoestimate the time it takes to communicate an image as the modified sum of the transmissionthe reception time, the verification time and the confirmation time. We expect individuals willdiffer in terms of their likelihood not only to expend time in these areas but also to iteratethrough the process until confirmation is achieved. Armed with these estimates we can forexample estimate the number of meetings it would take for a given team to successfullycommunicate a given set of images. We can similarly estimate the failure rate we can expectgiven their likely behaviors as observed from their interview and questionnaire data, brainscan recording and video recording, thus predicting the likelihood of the team to deviate fromthe client requirements. Figure 5 shows how computer simulation can be used in the analysisphase of our work and in so doing complement our observation methods and lead to moreinformed interventions.

470 ICED 01 -C586/477

PERSON BPERSON A

Figure 4. Model of a simple communicative transaction in which person A attempts to communicate an imageto 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 designactivities. Computer simulation provides a way to analyze the data, develop a better understanding ofthe interactions, and make more informed decisions about interventions.

5 Summary

As we mentioned in the beginning, our aim was to make a sketch of future research bybuilding on past empirical work in the context of modern tools. In so doing we have describeda scenario whereby the improvements and availability of better tools to observe the workingsof design teams will lead to an increase in the accuracy and reliability of our models of designand hence our predictions of design performance. Working from first principles, such ascience of design teams will not only enable us to develop new strategies for managing designteams it will also make it possible to develop better environments to support the process. Inthis future, it appears to us that the quality of the outcome will be judged by both process andproduct variables - that is both the quality of the final product and the design team's subjectiveexperience 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 canDesign Methodology Leam from Them? How can Design methodology SupportThem?," in Designers - The Key to Successful Product Development, Frankenberger,E., Badke-Schaub, P., Birkhofer, H., (eds), Springer-Verlag, 1998.

[2] Eisentraut, R., Gunther, J., "Individual Styles of Problem Solving and their Relation toRepresentations in the Design Process," Design Studies 18, pp 369-383, 1997.

[3] 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.

[4] Frankenberger, E., Badke-Schaub, P., Birkhofer, H., "Factors Influencing Design Work:Empirical Investigations of Teamwork in Engineering Design Practice," in proceedingsof the International conference on Engineering Design, Tampere, Finland, August 19-21, 1997.

[5] Goker, M.H., The Effects of Experience during Design Problem Solving," DesignStudies 18, pp 405-426, 1997.

[6] Tang, J., Leifer, L.J., An Observational Methodology for Studying Group DesignActivity, Research in Engineering Design, v2, pp. 209-219, 1991.

[7] Leifer, L.J., Design Team Performance: Metrics and the Impact of Technology, inEvaluating Organizational Training, Brown, S.M., and Seider, C., (eds), KluwerAcademic Publishers, Netherlands, 1998.

[8] Carrizosa, K., and Sheppard, S., "The Importance of Learning Styles in Group DesignWork." Proceedings, Annual Frontiers in Education Conference. ASEE/IEEE, KansasCity, T2B 12-17, 2000.

[9] Felder, R., and L. Silverman "Learning and Teaching Styles in Engineering Education."Engineering Education, 674-681, April 1988.

[10] Brewer, J.B., Zhao, Z., Desmond, J.E., Glover, G.H., Gabrieli, J.D.E., "MakingMemories: Brain Activity that Predicts How Well Visual Experience Will BeRemembered," Science 281, 5380, pp 1185, 1998.

[11] Mabogunje, A., Leifer, L.J., Levitt, R.E., and Baudin, C., "ME210-VDT: A ManagerialFramework for Improving Design Process Performance", Frontiers in EducationConference, Atlanta, Georgia, 1995.

[12] Galbraith, J.R., Organization Design: An Information Processing View, Interfaces,4,28-36,1974

First authors name: Ade MabogunjeInstitution/University: Stanford UniversityDepartment: Center for Design Research, Department of Mechanical EngineeringAddress: 560 Panama Street, Stanford, California 94305-2232Country: USAPhone: 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 DESIGNICED 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 onthe same day. Many of these different types of interaction can be supported effectively withcomputer tools - but a tool must meet the needs of the situation it is used in. Howeverresearch on collaborative designing and on design groupware often focuses exclusively on oneinteraction paradigm. This paper explores the variety of interaction in design by developing aset of dimensions for classifying design scenarios. It discusses a number of importantinteraction scenarios we have observed in our studies of design practice, and theirimplications 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 isthe generation of a description of a new product, through a repeated cycle of reformulating theproblem, synthesising a potential solution, evaluating it, and reformulating the problem again.However, design in its broader cultural sense includes all activities involved in the generationof a complex product. Many of these activities do not contribute directly to generating theproduct description, but instead to establishing the requirements it must meet or testing itsproperties. 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 characteristicsof their design processes. While there are many attempts made to describe engineering designin general in taxonomic form [for instance 2], detailed taxonomies address only particularissues. For instance Ullman [3] classifies decision problems in design; and Kaplan et al. [4]are concerned with the information requirements of tasks requiring interaction betweendesigners. In contrast to Kaplan et al. [4], we are looking at communication activities withinlarge design processes, where the mode of collaboration is not necessarily predetermined bythe task rather than by the organisational set-up. Medland [5] classifies communicationactivities into four types: delegation, reporting, awareness, and problem handling (forresolving conflicts between design elements or constraints).

3 Research on Design Communication

How designers communicate, and how designers could communicate, has been studied from avariety 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 cooperativedesign are developed for specific scenarios, when consideration of a wider range of uses couldreveal 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 longdistances or when involved in large projects. Information management systems that supportcommunication through record-keeping are one important strand of development, especiallyimportant in applying methodologies such as SSADM to software development. Otherdevelopments include systems for enabling participants in face-to-face meetings to sharesoftware and computer representations of information; and support for transmitting a varietyof material including video messages through time and space to colleagues workingseparately, to replicate for message passing the resources available in meetings [6].

There has been extensive research on computer support for collaborative designing by remotedesigners using shared workspaces simultaneously. Systems are in commercial use thatsupport video-conferencing, and working collaboratively on shared CAD models across theAtlantic. Successful research systems have provided a face-view video channel as well asvoice, and allowed remote users to share sketches [for instance 7], and also desktop views andnear-screen hand gestures. Research on shared workspace systems has both driven and beendriven 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 havegiven a group a design brief and analysed the resulting design activities [see 11 for twentydetailed analyses of the same episode of collaborative design by various different researchers].Design conversations almost always employ sketches, drawings, prototypes or other visualreferents (but these can sometimes be imagined [12]). Communication in joint designing ismulti-modal: speech, drawing and gestures are used in combination, with each channel used toexplicate and disambiguate what is expressed in the others [8, 9, 10]. This multi-modalcommunication involves the use of argumentation strategies and rhetoric [10, 13, 14, 15], andsubtle 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 designdiscourse. 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 orgroups, or between people and tools, rules, representations etc). It can describe the state (thatsomething is now in), or how and why something got to be the way it is (making sense), orhow something might or should develop (framing the future).

There has been extensive research on how using computer technology influences how peopleinteract in meetings. One important finding is that people will exploit ways to communicatethat don't exist in conventional face-to-face interactions. For instance by drawing or gesturingin the same place at the same time in a virtual workspace [7]. Another is that using groupsupport systems influences what happens in meetings, but how they change what happensdepends on both the technology and the purpose of the meeting; for instance decision-makingis different from idea generation [see 16].

Minneman [10], Bucciarelli [13] and Henderson [14], among others, have studied large-scaleengineering 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 viewdesigns as arising through a process of negotiation between participants, where information isactivity communicated and actively made sense of, rather than seeing it as passively flowingthrough an organisation. However this view downplays the role of designers working on theirown 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 andconveying information between people with different knowledge and responsibilities.Designers' learned representation-specific interpretation skills determine how and how muchthey 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 25knitwear companies in Britain, Germany and Italy, which was originally intended as arequirements analysis for an intelligent design support system. This found that thecommunication between knitwear designers and knitting machine technicians was a majorbottleneck, and identified a variety of factors contributing to communication breakdown [17].The most important were the difficulty of expressing designs clearly and unambiguously inthe available representations, and failure to recognise communication problems. Thesefindings have informed our studies of engineering design. In 1999 we interviewed 23experienced designers and design managers in a study of the customisation process inhelicopter design [18]. In 2000 we conducted a series of interviews in an automotive companystudying 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 muchsimpler product, it exhibits many of the characteristics of engineering design [17]. In knitweardesign we could observe all aspects of the design process and see people communicating indifferent situations. It was only possible to talk to a small fraction of the participants in theengineering processes, who were all specialists in their fields. None communicated withcolleagues in as many different situations as did the knitwear designers. In all theorganisations we studied designers did some joint problem solving with other designers. Forexample all the knitwear designers in a company jointly work out a colour scheme for eachseason. But they develop conceptual designs for garments independently, and hand them overto technicians in the form of inaccurate, incomplete and inconsistent specifications; they onlynegotiate over the design when the technicians perceive that they cannot interpret thespecifications accurately [17]. In the engineering companies we have studied, designs arehanded over to colleagues with different technical expertise. The handovers are discussed informal meetings, but often only by the bosses of the people doing the designing; if peopleknew each other, conflicts were sometimes resolved through local negotiation, butcommunication across organisational fields was always problematic [see 19].

What aspects of design the researcher studies is not independent of how a design processworks. What gets done individually and what is done in meetings depends on the particularproblem, but also on the structure and culture of the organisation. In large organisations andcomplex products, the complexity of the process inevitably leads to more handovers andinformation transmission between people who don't know each other. We have studied designcultures in which passing on specifications and other asynchronous communication isimportant. Had we looked solely at communication or at processes where the majorparticipants design together in meetings, our study would have used methods more similar tothe 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 ofvariation we list below are not orthogonal: common situations have related values along anumber of the dimensions. These different situations can create different types ofcommunication breakdown; they influence how designers behave and what they need in theway of computer support for their collaborative activities.

Form of Communicationo 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 Tasko Objective of task: Generation of ideas or alternative solutions vs convergent problem

solving vs decision making from alternatives vs acquisition or imparting of pre-existinginformation.

o Division of decision-making: Joint problem solving - negotiated handover - sequentialproblem solving.

o Hierarchy of decisions: Different participants' tasks are of equal importance - sometasks 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 Expertiseo Equality of expertise: Participants have equal levels of expertise - Some participants are

more knowledgeable than others. (One important interaction type is apprentice consultsmore experienced colleague.)

o Balance of Expertise: Participants have shared expertise (and use the same concepts andcan interpret each other's terms and representations) - participants have complementaryexpertise.

o Mental representations: Participants conceptualise topic in similar terms - differentterms.

o Familiarity: Participants know each other - participants cannot make assumptions aboutothers' knowledge.

o Context: Participants share contextual information - participants have different (or no)knowledge of the context.

Tool Expertiseo Competence with groupware: Experienced frequent user (skilled and comfortable with

using the medium) - novice or infrequent participant.

Organisationo 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 (forinstance in dealings with suppliers, or with people without security clearance).

Representation of informationo 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. Thesescenarios reflect typical work situations, which require their own computer support. One wayto 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, thenpasses on the design to another specialist in a different aspect of the design, through awritten or oral specification. The expectation is that the next person will do what isrequired within the specification rather than advancing the design by changing thespecification. The participants are often co-located but communication is asynchronous.Later tasks are often seen as subordinate, so that two-way negotiations are excluded. Forexample, knitwear designers give their technicians specifications, without muchdiscussion unless problems occur [17]. Such over-the-wall sequential design processes arestill quite common in engineering, especially when designs are handed over to suppliers orcontractors.

• Joint Designing. A group of people work on one problem together. Typically they workat the same time in the same room. Individuals might work on parts of the problems, butthey have easy access to each other and discuss issues as they occur. Joint designing istypically done by groups of people with similar expertise, who are solving a problem thatconcerns all. The team members usually share a lot of background knowledge andawareness of context, and often get to know each other well. They can talk to each otherspontaneously and get rapid feedback on their communication acts [see 8, 9, 10, 15]. Forexample knitwear designers work out colour schemes as a group, because they all use thesame colour scheme. In engineering designers often work jointly during conceptual designwhen even a complex problem is addressed by a small group.

• Interface Negotiation. In concurrent design various people from different fields ofexpertise 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 andnegotiate to achieve mutually consistent solutions to their individual problems. In realitymost processes give priority to some tasks and decisions, and stagger the beginning of thetasks. It is well recognised that concurrent design processes work best with colocateddedicated project teams. Communication occurs informally, through one-to-oneconversations as well as in meetings.

Episodes of interaction can have a variety of purposes, even within a meeting with a differentprimary purpose. The types of discussion listed below can be about most of Minneman's nineclasses of subject matter (see section 3.2).

ICED 01 - C586/518 477

• Request for information. Designers frequently find they need more information, andusually their main source is their colleagues. Pure information request is more likely tooccur in design handover or concurrent situations than in joint designing sessions.

• Negotiation for clarity and negotiation of constraints. The participants in a discussionmust make sure that they understand each other's positions - that is, achieve compatibleinterpretations of the situation. This often requires understanding the constraints the othersmust meet, to understand what the constraints on their own activities should be. Sonegotiation for clarity often leads to a negotiation over constraints. This is particularlyimportant when designs are handed over (not necessarily in a linear process) from onespecialist to another who is doing an equally important task independently.

• Idea generation. In many design process that are essentially sequential, idea generation isundertaken as a joint activity in a meeting, because designers need each other's inputbefore committing time and resources to any particular solution. Designers often reuseideas from past designs or other sources; how much they refer to visual props depends onhow much they need to explain ideas with reference to their sources.

• Conflict resolution. Meetings are often set up to resolve conflicts between elements of adesign. This is typically done through real-time discussion. Conflict resolution situationsvary according to whether there is an authority capable of arbitrating or imposing adecision on conflicting parties.

• Decision making. Much design comprises an exploration of possibilities followed by adecision on which avenue to follow. Decisions need to be made about what trade-offs tomake, and often in conflict resolution, as well as about concepts. If individuals makedecisions on their own, they have to justify them (see below). In meetings decision can bemade jointly or by individuals higher up in the hierarchy.

• Justification. Designers must often justify their solutions or decisions, either orally inmeetings or in reports. The recipient cannot be assumed to have the same knowledge asthe person who has to justify the solution. Justifications may be made to equals, bosses oroutsiders; and the explanations must be pitched to the recipients' understanding. Specificjustifications are often necessary in handover activities.

Each individual engages in most of these communication situations as part of their normalwork, possibly with the same people. Designers use different channels on different occasionsto convey different kinds of design information. For example a designer might engage in jointproblem 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 thenworks on his own using a CAD system. When he has a question has sends an email messageor picks up the telephone. Later he has to return to the boss to justify the design that he hascome up with in another face to face meeting.

6 Implications for Engineering GroupwareNo single approach to supporting communication is sufficient to handle the richness andvariety of possible communication acts. Hence we should be suspicious of any assumptionsthat supporting formal meetings, or record management and transmission, or real-timeinteraction, is going to meet all the information transmission needs of a distributedorganisation. 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 arevital for distributed communication. Such systems should support sketching and gesturingas well as the use of formal documents and CAD models.

• Much communication centres on contextual information, especially about past designs andcompetitor products, and relies on all participants being familiar with this context. Supportfor rapid retrieval and display of archive information could make shared workspacesystems much more effective. Here support for communication overlaps with long-terminformation management.

• Quick, casual, low-effort interactions are at least as important as organised meetings andformal information management - restricting them is potentially catastrophic. Hence it isessential for meeting support systems to support easy and rapid initiation of briefunscheduled interactions, especially if integrating informal interaction with informationmanagement activities is a desired objective.

• Graphic representations and models not only communicate information across divisions ofexpertise and responsibility, but also play an important role in structuring design processes[14]. Access to and control of representations through information management systemswill 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 forcomputer support for cooperative designing that goes beyond efficient document retrieval orvideo conferencing technology and shared workspaces. Important issues include translationbetween alternative notations and graphic representations, enabling the less-informedmembers 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 LotusEngineering Ltd for their support of this project, and to the engineers who participated in it.

References

[1] Frost, R., "A Suggested Taxonomy for Engineering Design Problems", Journal ofEngineering Design. Vol. 5 No. 4, pp. 399-410, 1994.

[2] Ullman, D., "A Taxonomy for Mechanical Design", Research in Engineering Design.Vol. 3, pp. 179-189, 1992.

[3] Ullman, D., "A Taxonomy for Classifying Engineering Design Decision Problems andSupport Systems, Artificial Intelligence in Engineering Design. Analysis andManufacturing. Vol. 9, pp. 427-438, 1995.

[4] Kaplan, S.M., Tolone, W.J., Bogia, D.P. and Bignoli, C., "Flexible, Active Support forCollaborative Work with ConversationBuilder", Proceedings of Computer SupportedCooperative Work '92. ACM Press, Toronto, Canada, 1992, pp. 378-385.

[5] Medland, A.J., "Forms of Communications Observed During the Study of DesignActivities in Industry", Journal of Engineering Design. Vol. 5, pp. 243-253, 1992.

ICED 01 - C586/518 479

[6] Minneman, S.L. and Harrison, S.R., "The DrawStream Station: a tool for distributed andasynchronous 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 ofthe 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 SharedWorkspaces 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 ofGroup Engineering Design Practice", PhD Thesis, Department of MechanicalEngineering, 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", DesignStudies. 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 inDesign Teams: Mediating Design Progress through Social Interaction", in [11], pp. 319-341.

[16] Huang, W. and Wei, K.K., "Task as a moderator for the effects of group supportsystems 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 andComputing Solutions", Computer Supported Cooperative Work. 2001.

[18] Eckert, C.M., Zanker, W. and Clarkson, P.J., "Aspects of a better understanding ofchanges", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001.

[19] Eckert, C.M., Clarkson, PJ. and Stacey, M.K., "Information Flow in EngineeringCompanies: Problems and their Causes", Proceedings of ICED'Ol. PEP, Glasgow, UK,2001.

Dr Claudia Eckert Dr Martin StaceyEngineering Design Centre Department of ComputerDepartment of Engineering and Information SciencesUniversity of Cambridge De Montfort UniversityTrumpington Street Kents HillCambridge, CB2 1PZ, UK Milton Keynes, MK7 6HP, UKPhone:+44 (0)1223 332 662 Phone: +44 1908 834936Fax:+44 (0)1223 332 662 Fax: +44 1908 834948Email: cme26@eng.cam.ac.uk Email: mstacey@dmu.ac.uk

© IMechE 2001

480 ICED 01 -C586/518

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

A STATISTICAL STUDY OF HOW DIFFERING LEVELS OF DIVERSITYAFFECT THE PERFORMANCE OF DESIGN TEAMS

A G Carrillo

Keywords: Diversity, empirical study, design teams, design projects

1 Introduction

In recent years, diversity has become a popular area of interest. Today's business practicesrequire multidisciplinary work groups in a constantly changing environment. The work forcehas also experienced a growth of ethnic diversity in its composition and that ethnic presence isexpected to grow in the coming years. It is believed that the diversity of these groups willhave positive affects on group creativity and performance [2]. Unfortunately, the effects ongroup process and performance are hard to measure and quantify. However, team diversity isconsidered 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 fromanother [9]. Diversity includes demographic diversity, psychological diversity andorganizational diversity [3]. Significant research in the last 40 years has explored how thesedifferences affect the process and performance of work teams and how it affects those whomanage these work teams. The majority of these studies are based on three basic theories.The theories are social categorization, similarity/attraction and informational diversity anddecision making [9]. The results of this research have had mixed outcomes. Williams andO'Reilly have helped to summarize a large number of the findings in the area of demographydifferences within teams and its effects on team process and performance.

In the paper's findings, group heterogeneity appears to have negative effects on group processwhile having mixed results on group performance. The effects on process includecommunication difficulties, task conflicts and group dissatisfaction. There has been no cleartrend on its effects on group performance. Unfortunately, most of the work that supportsdiversity 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 howthat 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 theperformance of the team over time. Therefore, it is important to try to understand howdiversity may influence the progress of the groups as well as the end effects on performance.

2 Purpose

The purpose of this study was to contribute to the research done in the study of diversity andits 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 engineeringprojects can last for such a varying length of time, how the teams progressed was alsostudied. It was important to try to understand the effects of time and if any trends could beuncovered that would not have be seen with a single measurement.

3 Method

Since the backgrounds of work team members are becoming more diverse, it is important tounderstand how varying diversity variables may in fact change the outcome of a team'sperformance. In an effort to understand these influences, a study was conducted to monitor ateam's diversity and track the group's performance over time. For the academic years of1994-95, 1995-96 and 1996-97, design teams in a Stanford University's mechanicalengineering graduate design course were observed. The class studied is a three quarters longproject based course with industry sponsorship. This format allowed for multipleperformance checks with equitable time milestones and real life projects. Due to the durationof these projects, the team composition was team selected, allowing students to choose whomthey 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 theirperformance. In an attempt to quantify a team's diversity, 6 different criteria were identifiedand the requirements to meet each criterion were established. The students were asked to takea brief sampling of the MBTI (Meyers-Briggs Type Indicator) questionnaire in an attempt toidentify the student's "Preference Group [8]." The remainders of the group's diversitycharacteristics were identified using information provided by students at the time of projectselection and from end of quarter documents written by the design teams. The teams' gradeswere recorded and kept throughout the year. The grades were used as the measure for teamperformance. An analysis was then performed to determine if the teams' performance wasaffected 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 wasestablished. The class had roughly 45 students per year, with teams averaging 3-4 membersper team. Teams started off with 2, 3, 4 or even 5 members at the beginning of the fallquarter. Due to outside influences, teams sometimes lost members during the year and sothese numbers changed. Sometimes people were added to teams and some groups combinedwith other groups. In order to ensure sufficient team dynamic influences and resources, ateam 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 forchange but requiring sufficient team unity. There were on average 12 teams that met thiscriterion 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 pointvalue/score. Six different diversity variables were identified. Each team was given a score of0 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 themaximum was 6. The variables and the criteria are as follows.

GenderDue to the continually growing impact of women in engineering, it is important to understandhow gender may affect the performance of work teams. This class had a limited number ofwomen that participated in the class, so a team was considered to demonstrate genderdiversity if at least one member of the team was a woman. However, at least 1 male must alsobe on the team in order for a team to receive this diversity point. In this study, it was rare fora team to have more than one woman.

Ethnic BackgroundThe ethnic background criterion is a common demographic diversity factor. The studentswere categorized using the same ethnic categories that are used by the university's admissionapplication. The main focus in this variable is that students have different backgrounds.Therefore, students from other countries were considered to be different from other ethnicbackgrounds. For a team to meet this criterion, every member had to be from a differentracial category or be from another country.

Personality PreferenceIn an attempt to address the psychology diversity influence, the personality preferencequestionnaire (brief sampling of the MBTI questionnaire) results were used to categorize thestudents into different preference groups. With Doug Wilde's direction and use of hispersonality preference scheme, the students were categorized into 4 distinct groups. Theywere 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 theNorth and South styles are portrayed as having mediating qualities. In order for a team toreceive the personality preference point, the team had to have an East and a West personalitytype on the team and a North and/or South group member.

Distant MembershipStanford University has created a program, Stanford Instructional Television Network (SITN)(http://scpd.stanford.edu). that allows technical professionals to participate in Stanford classeswhile remaining offsite. This class has included several off campus/remote students from thisprogram. Students from other universities have also been encouraged to participate in theclass as fully functional teams, or team members. Distance can cause unique workingdifficulties for work groups [1]. To receive this diversity point, one member of the team musthave been an SITN student or from another university for the duration of the project.

Work ExperienceIn order to address the differences in tenure/experience, work experience was included as anarea of diversity. For the team to receive the work experience diversity point, at least half ofthe team must have had prior work experience. For a team member to claim prior workexperience, the person must have worked full time for at least 1 full year. A person working 4summers for the same company was not considered to have met the requirement. Althoughthe experience is very valuable, it was not considered equal to a full year of work experience.

School/EducationEach team member must have attended a different college or university. If any two membersattended 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 teammembers 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 forthis study to ensure that the grades received were indicative of a "team's" performance andthat all students had a similar grade motivation. Students may participate in this course in acredit/no credit basis. For a team to be included in the study, all team members had to receivea grade in the course. This was to ensure that all members would be equally affected by theoutcome of the project and the grade received by the team. In the first quarter, there are twoparts to the course. The industry projects are introduced in the second half of the first quarterand only these grades were included in the study, so the fall quarter grades are indicative of 5weeks 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 = A4.00 = B3.00 = C2.00 = D

4.70 = A-3.70 = B-2.70 = C-1.70 = D-

The teams' final grades are weighted averages of grades on the physical hardware constructedby 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 anddetermine which criteria they met. The teams received a 0 or 1 for each criterion. The teamwas then given a diversity score by summing up the individual scores for each criterion. Eachteam's grades for the autumn quarter, winter quarter and spring quarter were calculated. Thewinter quarter's grade was not a major point for this study since the instructor used the winterquarter's grade as a progress report to the team. In fact, the instructor retroactively changedthe winter grade to the same grade received by the team at the end of the project.

4 Results

Due to the small number of teams per year and the length of the projects, it is difficult to get alarge sample size. However, some promising trends were identified.

The teams were broken up into 3 categories: high, medium and low diversity. Groups withhigh diversity had diversity scores of 4-6 (14 teams). Low diversity groups had diversityscores of 0-2 (11 teams). The medium diversity group consisted of teams with a diversityscore 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 theteams. Table 2 shows the descriptive statistics for the groups' grades at the end of the fallquarter. Based on the mean scores, the high and low diversity groups were roughly equivalentin 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 shownin 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 0-6 categories and new box plots were created. Figure 2 demonstrates an obvious trend. As thediversity 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 newanalysis 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 highdiversity groups showed the highest mean score, followed by the low diversity group, with themiddle diversity group once again performing lower than the other two groups. Anotherinteresting result is that the standard deviation of the high diversity groups was half thestandard deviation of the other two categories by spring quarter. The middle and lowdiversity groups both showed an increase in standard deviation by the spring quarter while thehigh diversity groups actually decreased. The results can be better visualized in box plotsshown in Figure 3.

Table 3. Spring Grades, descriptive statistics

GroupHigh

MediumLow

n14511

Mean4.414.064.22

SD0.200.450.41

Figure 3. Box Plot of the diversity groups vs. spring gradesThe 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 tosee if there was a discernible pattern. For the spring results, there was no obvious pattern asseen in the fall.

In order to present the progress of the teams in a more understandable form, a graph wascreated that plots the mean grades of the diversity categories and maps the grades overautumn, winter and spring quarter (Figure 4).

Figure 4. The progress of the groups from fall quarter to spring quarter.

ICED 01 - C586/587486

As the graph shows, there was a definite improvement by the high diversity groups over thelow diversity groups. Although the two categories started off at a similar performance levelin the fall quarter, by spring quarter the high diversity groups outperformed the low diversitygroups. Another interesting observation is how the middle and high diversity groupsimproved roughly the same amount. Unfortunately, the low diversity groups started off somuch lower than the other two categories that they never caught up.

5 Discussion and conclusions

The first conclusion is that the degree of diversity may strongly influence a team'sperformance. For both the fall and spring quarters, the teams with middle diversity scoresperformed poorly with respect to high and low diversity groups. This may have strongimplications on how diversity should be implemented. If there isn't a strong push towardshigh diversity at team formation, it may actually decrease the performance of the team. AsLau and Murnighan introduced, faultlines may be responsible for the differences inperformance. Both low and high diverse groups may have a smaller number of faultlineswithin the group, reducing the existence of subgroups that lead to group conflicts [4]. Thismay 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 thatcategory. The high diversity groups not only outperformed the other two groups, but theydemonstrated a smaller variation within the group. It is difficult to know exactly howdiversity 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 afterthe fall quarter, it would have shown that there was no performance difference between thehigh and low diversity groups. However, after 2 and a half quarters, there was a noticeabledifference between all three groups. This particular outcome may have much biggerimplications. For shorter timed projects, team diversity may not be beneficial. In fact, if highdiversity is not implemented, it may actually hinder teams.

In summary, diversity influences the performance of a team. However, it may not always bepositive or noticeable. It is important that high diversity be strongly encouraged and fullyimplemented and supported. Time may also be a factor in how effective that influence maybe. Short term projects may benefit more homogeneous groups. Long term projects maybenefit more from team diversity.

Using these six variables to study work teams would be problematic in industry. Thesediversity factors are salient in a classroom setting, but difficult to identify in an organization.Additionally, the work environment is constantly changing, unlike the controlled environmentof the classroom. Student team members did not work together throughout the day, limitingtheir interaction with one another. Finally, it is extremely difficult to measure teamperformance outside the classroom.

This paper does not address motivation and group skills. These are important factors thathave definite effects on team performance. These variables are difficult to measure andevaluate, but their influences should be considered in future work.

ICED 01 - C586/587 487

6 Acknowledgements

I would like to thank the students for their help in this study. Professor Larry Leifer's supportof this study made it possible. I also thank Professor Doug Wilde for his help in determiningthe personality preferences for the students and in understanding his methodology.

References

[1] Armstrong, D. J, and Cole, P. "Managing Distances and Differences in GeographicallyDistributed Work Groups". In S. E. Jackson and M. N. Ruderman (Eds.), "Diversity inWork Teams: Research Paradigms for a Changing Workplace" Washington, DC:American Psychological Association, 1995 pp. 187-215.

[2] Eigel, K. M., Kuhnert, K. W., "Personality Diversity and its Relationship to ManagerialTeam Productivity". In M. N Ruderman, M. W. Hughes-James & S. E. Jackson (Eds.),"Selected Research on Work Team Diversity". Greensboro, NC: Center for CreativeLeadership 1996 pp. 75-98.

[3] Jackson, S. E. and Ruderman, M.N., "Diversity in Work Teams: Research Paradigmsfor a Changing Workplace". Washington, DC: American Psychological Association,1995.

[4] Lau, D.C. and Murnighan, J.K., "Demographic Diversity and Faultlines: TheCompositional Dynamics of Organizational Groups", Academy of ManagementReview. 23, 1998, pp. 325-340.

[5] Morrison, A. M., Ruderman, M. N. & Hughes-James, M., "Making Diversity Happen:Controversies and Solutions", Greensboro, NC: Center for Creative Leadership, 1993.

[6] O'Reilly, C. A., Williams, K. Y., & Barsade, S. G, "The Impact of RelationalDemography on Teamwork: When Majorities Are in the Minority", Research PaperSeries, Graduate School of Business, Stanford University, 1999.

[7] Ramsey, F.L. and Schafer, D.W., "The Statistical Sleuth: A course in Methods of DataAnalysis". Duxbury Press, Belmont, 1997.

[8] Wilde, D. J. "Using student preferences to guide design team composition", Proc.DETC '97. Sacramento, 1997.

[9] Williams, K.Y. and O'Reilly, C.A. "Demography and Diversity in Organizations: AReview of 40 years of Research", Research in Organizational Behavior. 20, 1998, pp.77-140.

Mr Andrew G. CarrilloMechanical Engineering Department, Center for Design Research, Stanford University, Bldg560 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

REQUIREMENTS ENGINEERING - LAYING THE FOUNDATIONS FORSUCCESSFUL 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 originatefrom the Systems Engineering domain, and describe their adoption within mechanicalengineering design projects. The motivation for using these techniques is to provide improvedrecognition of customer and end user needs at the outset of a project and then to manage andcontrol the use of requirements information throughout the project lifecycle. The techniquesoffer benefits particularly to projects with high levels of complexity and concurrency and canassist in supply chain management.

The paper outlines the Requirements Engineering process, from the front-end requirementdevelopment activities through to the management and change control of requirements. A keybenefit of these techniques is to establish traceability from the original customer need andsystem specification through the project lifecycle to the completed deliverables andacceptance criteria. This provides a method for rigorously assessing the impact of change to aproject's requirements. The techniques have been successfully implemented in the designprocess for projects in the aerospace, defence and general equipment sectors.

2 The Importance of Requirements

The processes by which customer requirements are converted into a tangible outcome - theproduct - may not always be well defined, understood or managed. Development andagreement of requirements that properly reflect a customer's need is a skilled process thatmay 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 andcontrol of change and the introduction of unnecessary or over-specified requirements. Failureto 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 projectunder-performance related to requirements deficiencies are difficult to obtain. This is partlydue, perhaps, to an historical under-recognition of the importance of this aspect of theengineering process or perhaps unwillingness by many organisations to reveal potentiallysensitive commercial information. However, the following examples provide evidence of howpoor 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 capturedand managed requirements in software projects lead to poor performance. The report contendsthat, during the early nineties in the US, a staggering 84% of software projects failed toachieve 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 inputin developing requirements, incomplete requirements and changing requirements.

Hooks [2] suggests that there is a correlation between the effort (or lack thereof) expended indeveloping a good project definition, including an adequately documented requirements set,and the likelihood of the project to suffer cost overrun. Moreover, the increased costs aredirectly attributable to the large number of requirement changes that occur late in the projectlifecycle. Analysis of the history of a number of NASA programmes supports this assertionand is illustrated in Figure 1 which shows the relationship between poor requirementdefinition 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 programmerisks and costs by developing a detailed a requirement specification as early as possible in theproject or product life-cycle. Obviously, the ability to produce a refined requirement set isalso dependent on the nature of the project and is bound to issues such as technical risk andother external factors. These problems are exacerbated in design projects involving highlevels of complexity. However the best possible definition of requirements at the earliest stageand their subsequent refinement is a potent risk reduction process.

3 Requirements Engineering

3.1 Systems Heritage

Systems Engineering is a discipline that has emerged from the need to manage thedevelopment and integration of complex systems. In the 1960s, the design of increasinglysophisticated technological systems was plagued by difficulties in achieving cost, scheduleand performance targets. This was particularly true of software projects, defence equipmentand spacecraft design [3]. Systems Engineering provides a structure for managing andimplementing complex technology programmes throughout their lifecycles [4]. It can bedescribed as a structured approach to product development that recognises the importance ofrequirements, 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 ofSystem Engineering is a skilled discipline and requires a committed organisational investmentto achieve.

A key process in system design is verification (i.e. confirmation of the user and systemrequirements and the detailed design by test). Verification (sometimes called validation)demonstrates that the system "does the right thing" as envisaged by the stakeholderrequirements. Recognising that this must take into account the different levels of systemdesign 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 theESA/NASA Cassini mission to Saturn [6]. The spacecraft was launched in October 1997 andis due to arrive in the Saturnian system in 2004. An important science element is the Huygensprobe, which is designed to separate from the Cassini orbiter and then descend through theatmosphere and land on the surface of the moon Titan. Unfortunately, more than two yearsafter launch, it was discovered that the communications link between the probe and theCassini orbiter had insufficient bandwidth to return all of the mission data. This was due to aneffect due to Doppler shift between the two spacecraft. The reasons for this error stem, togreat extent, from a failure to assess the impact of a design change on subsystem requirementsand to link these requirements to an appropriate test.

3.2 Definitions

The systems approach recognises the need to generate good quality requirements and the needto manage this information throughout the project lifecycle. This has given rise toRequirements Engineering which aims to develop a rational methodology for undertakingthese processes. Note that there is confusion over the use of this term as some authors refer tothe overarching requirement process as Requirements Management and RequirementsEngineering has a different and more specific connotation.

Wiegers [7] proposes a logical definition, which is adapted from IEEE conventions. This isthat Requirements Engineering encompasses the entire domain of activities related to systemrequirements and it is divided into Requirements Development (the activities to createrequirements) and Requirements Management (the activities to manage and controlrequirements). This is a useful distinction as it reflects the two broad ranges of activities thatare 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 thedifficulties in producing good requirements are related to getting this communications processright. This is bound to often very subjective issues related to interpretation, semantics, opinionand individual viewpoint. Resolving this requires the development of requirements data that isobjective, well structured, concise and relevant to the level of detail of the system componentbeing considered. Several key quality attributes of good requirements can be identified. Theseinclude:

Lack of ambiguity - requirements must be understood in the same way by all projectparticipants. 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 objectivetest otherwise it is impossible to demonstrate acceptance of the system. This implies thatrequirements must be reduced to single ("atomic"), testable statements of fact.

Attainability - requirements must be attainable not only within the constraints of the lawsof 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 pre-existing design solutions shouldn't be taken into account (either as constraints or as templatesfor further requirements extraction) but they must not be built into the requirements set. As anaside to this, it is actually quite important to refer to candidate solutions during therequirement development process, as it is only possible to cost designs, not requirements. It isalso possible to gather quality metrics (e.g. level of decomposition, linkage to test etc) duringthe requirements development activity to ascertain progress towards achieving a robust andhigh quality requirements definition.

3.4 Requirements Development

Producing quality requirements is a skilled process yet it is often the case that personnelinvolved in writing documentation such as a system specifications do not have any specialskills or training to undertake such an activity. An effective Requirements Developmentprocess requires the extraction of requirements information from source documentation anddomain 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 processis shown in Figure 4 and consists of the following phases:

Capture - Sometimes called "elicitation", the collection of requirements information fromthe stakeholders (an important sub-set of which are the DKEs) and other relevant sourcedata. 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 intoobjective requirements statements. This involves reduction to atomic statements,assigning attributes, classification, sorting and determining priorities. This processrequires further interaction with stakeholders and may use trade-off and technical studiesto assist in refinement.

Structuring - The final step is to structure and validate and the requirements. This can besupported by modelling techniques, for example Functional Modelling, to ascertainrelationships and dependencies. Performance constraints can be added and quality metricsassessed.

Figure 4. Requirements Development Process

3.5 Requirements Management

Requirements Management is the complementary process to Development. As requirementinformation is developed, it becomes necessary to manage the resultant data to ensure that itsintegrity is maintained. The main Requirements Management processes are:

Configuration Management - The process by which the current version status of therequirements data is identified and controlled. Usually each requirement is assigned aunique identifier (sometimes called the Project Unique Identifier or PUID). When therequirements data achieves an agreed level of maturity it is frozen or "baselined".

Change Control - Requirements provide fundamental information by which a project willbe 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 maintaina change history of the project.

Traceability - A key requirement management activity whereby linkages are madebetween requirements at different levels (i.e. the high level need, user and system) to theemergent design requirements, standards and tests. This provides the capability to assessthe impact of change.

These activities can be implemented in different ways. For relatively simple projects, it ispossible to use paper or word processor based systems and spreadsheet traceability matrices.However for many projects the evolving requirements data becomes too complex for theseapproaches 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 Engineeringprocess. In fact Achrafi [8] identifies at least 35 different tools. They can be broadly classifiedinto tools that support Requirements Development, Requirements Management or both.Development tools tend to provide process modelling capability (e.g. CRADLE, Rose andGMARC) whereas Management tools concentrate on maintenance of requirements data andare usually based on a database system (e.g. RTM, DOORS, Caliber, RequisitePro). It shouldbe remembered that establishing a good requirements process is fundamental and shouldprecede any decision regarding tool adoption.

4 Requirements in Mechanical System Design

4.1 Overview

The systems heritage of Requirements Engineering has been outlined above. Whilst thetechniques 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 thewider design community particularly through the adoption of Concurrent Engineering andmodern Project Management techniques. A major user (and developer) of RequirementsEngineering techniques is the Defence Procurement Agency via the Smart ProcurementInitiative [9]. All new defence projects must have a properly managed requirements process.Another organisation adopting the techniques is Airbus which is adopting RequirementsEngineering on its new aircraft projects including the A380 and A400M. The techniques aregaining recognition in other sectors including telecoms (e.g. mobile phone design) andconsumer products.

There are implementation issues that need to be considered for adoption within mechanicaldesign 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 softwaresystems.

494 ICED 01 - C586/177

4.2 Project Examples

The following examples are from the author's recent experience [10] and are provided toillustrate how requirements related techniques are being adopted.

Aircraft Research Programme

A European Commission funded fifth framework research programme to develop newconstruction techniques and technologies for future aircraft. The programme involves arelatively large number of partners and work packages from different organisations andEuropean countries. One of the partners has used requirements management techniques tocontrol the high number of requirements within their workpackage. This has improved projectcontrol and provided traceability between the project deliverable requirements, interfaces toother partners and verification tests.

Safety Requirements Development

A project involving the development of a nuclear site safety case at an existing defencefacility [11]. The organisation responsible for developing the safety case introduced arequirements engineering process into their safety case development team. This was done viaa seminar/workshop training programme and followed up by consultancy support. Theyelected to use a commercial requirements management tool to control the large number ofsafety requirements developed during the project. This approach established an audit trailthrough the safety case development activity, produced safety requirements that were testableand linked to regulatory acceptance, produced a systematic way of decomposing and evolvingsafety 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 launchsystem that proposed the use of novel technologies. This project used a formal approachincluding Requirements Development activities to define User Requirements and SystemRequirements documentation linked to a proposed future development programme. Thisapproach was designed to be compliant with the MoD Smart Procurement Initiative.

5 Conclusions

Requirements Engineering techniques offer significant advantages in terms of improvingproject performance and customer satisfaction. In fact, for the success of complex technologydevelopment activities, it is essential that an effective process to establish and managerequirements is established. Moreover, the use of requirements traceability offers thepossibility of improved change control and impact analysis. This provides the design projectmanager with the ability to control cost and reduces the project lead-time. The techniques alsoallow improved communication within concurrent teams and design projects within complexsupply chains. The techniques have been adapted from their software and systems heritageand are now being successfully used within general mechanical design projects.

ICED 01 - C586/177 495

References

[1] Standish Group, The, "CHAOS Study", The Standish Group International Inc, January1995.

[2] Hooks, I. F., "Managing Requirements", Issues in NASA Program and ProjectManagement, 1991.

[3] MacDonald, J. S., "Systems Engineering: Art and Science in an International Context",INCOSE Symposium, 1998.

[4] Stevens, R et al, "Systems Engineering - Coping with Complexity", Prentice Hall,1998.

[5] INCOSE and the AIAA Systems Engineering Technical Committee, "SystemsEngineering - A Way of Thinking", International Council on Systems Engineering andthe American Institute of Aeronautics and Astronautics, 1997.

[6] Link, D. C. R. et al, "Huygens Communications Link Enquiry Board Report",ESA/NASA, December 2000.

[7] Wiegers, K. E., "Software Requirements", Microsoft Press, 1999.

[8] Achrafi, R., "Requirements Engineering Tools", The Atlantic Systems Guild, 2000.

[9] Anon., "The Acquisition Handbook - A guide to Smart Procurement", Edition 3,Ministry of Defence, June 2000.

[10] Thomson, G. A., "Requirements Engineering at INBIS", Requirements Focus, INBISTechnology Ltd and Integrated Chipware UK Ltd, 2000.

[11] Cooper, D., "Safety Requirements Management Using a Database Technique", NNCLtd, 2000.

G. ThomsonINBIS Technology Limited1 The BroomsEmersons GreenBristol BS16 7FDUnited KingdomTelephone: +44 (0)117 987 4000Fax: +44 (0)117 987 4040Email: gthomson(5),inbis.com

© INBIS Technology Limited 2001

496 ICED 01 - C586/177

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

THE ORGANIZATION AND MANAGEMENT OF ENGINEERINGTENDERS

G Barr, J H Sims Williams, S C Burgess, and P J Clarkson

Keywords: Competitiveness, Cost-estimation, Design reviews, Product planning, Riskanalysis and management

1 Introduction

This paper outlines the current tendering practices of companies operating within theengineering industry and identifies potential areas where current methods can be improved. Atendering methodology is proposed which can potentially identify and evaluate the technicalrisks that engineering companies possessing stable product architectures are exposed to. Asdemonstrated by a case study, adopting the methodology will enable companies to re-useknowledge established during historical projects and employ that knowledge when evaluatingrisks inherent in tendering opportunities.

The origins of many project risks can be traced back to defective decisions made during thetendering phase. Troublesome project issues can potentially be mitigated with improvementsto the tendering process of engineering companies. There are many problematic issues thatarise within the tendering phase, such issues are the scarcity of resources (either human ormechanical hardware), costing shortfalls, project over-runs, non-performances by in-house orsub-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 andimplement 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 isexposed during the preliminary stages of a project [3]. The two main questions thatengineering 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 thatare assigned to a project the higher the project cost. However, assigning more resources to aproject does not guarantee a project will be completed on time. The aim of evaluating theamount of uncertainty present in a project is to provide a method that aims to estimate andthen deliver a project to budget and on time.

ICED 01 -C586/336 497

2 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 waselicited from company representatives with extensive experience of their company's internaltendering practices through semi-structured interviews. Table 1' details the industrial sectorand operational roles of the companies interviewed. By pursuing this evaluation process, thetype of companies that would benefit most from employing a risk-based model incorporatingthe re-use of historical technical data for analysing tender uncertainty can be identified. It isintended that the method proposed can be adapted to suit the practices of many engineeringsectors.

Table 1. Studied Engineering Companies

®®®®©®®®

CompanyElect-Mech-1Elect-Mech-2Elect-Mech-3EngConsum

ConProConDes-1ConDes-2ConDes-2

Industrial SectorMarine Power Systems

Power Systems & MaterialsMechanical Bulk HandlingEngineering Consumables

ConstructionConstructionConstructionConstruction

Operational RoleElectro-mechanical Designers & ContractorsElectro-mechanical Designers & ContractorsElectro-mechanical Designers & ContractorsMechanical / Electronic Design Consultants

Civil Project ManagersCivil & Structural Design ConsultantsCivil & Structural Design ConsultantsCivil & Structural Design Consultants

The studies were needed to understand not only the tendering practices of the companies butalso to appreciate the market sector in which the companies work. By studying the operationalrole the company performs, the tendering operations and rationale of the company can bebetter understood. Modelling of the tendering mechanisms were made with respect to thecompany's:

Operational Environment - Depicting the constraints of the engineering market in whichthe company operates.

Tendering Practices - Depicting the operations of the company during the tender phaseand subsequent project phase.

The companies were assessed against ten subjective factors for each of the two models, on ascale2 of 1 to 5 with 1 = 'Very Low' and 5 = 'Very High'. The results of the evaluationprocess 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 employedby the engineering companies balanced against their operational constraints. Similaritiesbetween engineering sectors and roles can also be identified through the use of the graphicalrepresentation.

1 The names of the companies involved have been disguised due to the commercial sensitivity of the subjectmatter.2 The evaluation scale is further detailed with exact definitions attributed to 1-5 for each of the 20 factorshowever due to publishing constraints the exact definitions cannot be shown

1CED 01- C586/336498

Figure 1. Operational Environment(Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 3. Tendering Practices(Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 2. Tender Development(ConDes-1, ConDes-2, ConDes-3 & ConPro)

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 tenderingpractices of the companies based upon the nature and type of business environment in whichthey operate. We will focus on the issues related to the companies' technical bias andsubsequent understanding of technical risk. All companies are shown to possess acomparatively unstructured base of historical technical data. It has also been observed that thereuse of this data is not particularly high during the tender phase. Similarly, the methodsemployed for evaluating the uncertainty associated with potential projects can be seen to berelatively unsophisticated. There is therefore scope for historical technical information to beused if a method can be suggested which is appropriate and delivers beneficial results. Thecompanies that are required to undertake a high degree of technical detailing during theirtender operations would be most likely to benefit as technical information can be collatedduring 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 productarchitectures. Solutions that such companies offer to clients typically contain relatively lowamounts 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; illustratedgraphically in Figure 5. The 'Solution Experience' scale indicates how familiar the companyis with solutions they typically generate. For example, a design consultancy will typically takethe 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 workingundertaken by these design consultancies and their limited experience in generating theproduct solutions requested of them, they do not possess a significant amount of historicaldata which could be utilised in future designs. Companies that undertake little originalworking in their projects tend to include small amounts of technical detail in their tenderdocumentation. The practices displayed by organisations noted in Figure 5 as © and CD aretherefore unsuitable as the research is primarily aimed at reducing the technical risk exposureof engineering companies during the tender stage.

Figure 5. Classification of Engineering Roles

3 Industrial Case Study

The method of evaluating and documenting the technical risk present in the tenderingpractices of engineering companies is currently being tested with a large electro-mechanicalcompany (previously noted as 'Elect-Mech-3') involved in the design and commissioning oflarge-scale bulk handling systems. As an approximation, the company typically tenders forabout 10 projects per annum for its bulk handling system around the world. It will typicallyexpect to win the contract to design and commission one or two of these projects. All systemsof this nature consist of large sub-systems which must be designed and assembled to interactwith each other. The sub-systems incorporated into the design of new tenders are mainly re-used from previous projects. If a project contains an excessive number of elements which thecompany considers to be outside it's previous solution experience then the potential projectwill not be bid for. When tendering, the technical detail specified in the tendering submissionswill be extensive. However, it has been noted that owing to tendering time and resourceconstraints there exists limited scope to fully assess the risks present within project bids.

4 A Risk-Based Tendering Methodology

Modelling cost and technical risk for engineering projects is complex and relies not only onexplicit data but also on experience and judgement. Engineering companies must first decidewhether to bid, and if so, then determine a suitable tender price. To proceed with a tender, anengineering company must have confidence that the uncertainties arising from the technicalaspects of a project can be fulfilled. It is common practice within engineering companies toidentify 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 tohighlight the 'acceptability' of a particular event. This method however can prove inadequatewhen modelling complex engineering projects. Firstly, project risks are separated from projecttasks and objects making the correlation between risk and project models (e.g. work / product/ organisational breakdown structures) difficult. Secondly, the similarities between projectrisks from one project to another can be hard to identify, thus reusing historical data can betroublesome. Crossland proposes a mechanism for the stochastic modelling of key designparameters during the conceptual stages of engineering design, particularly the modelling ofproject cost [3]. Historical technical data is used as the method inputs, however ensuring theaccuracy of historical data is problematic. The method proposed here suggests that estimatesused within the very earliest stages of design, in this case the tendering phase, should indeedbe based upon historical data. The data should not however be used directly for input into anestimation tool, but as a recommendation to experienced designers as to the input valueswhich should be used. In addition, the uncertainty associated with the estimate of cost foreach task or object used in the estimation process should be based upon realistic evidence. Amethod is therefore proposed which identifies the tasks and objects (i.e. components, systemassemblies, etc) that possess the greatest uncertainty. It is the aim of the methodology tofacilitate the decision making process and ensure decisions are based on sound technicaljudgement.

To accurately model technical information in a re-usable format, a system must be used whichprovides documentation of technical information in a form that compliments existingtechniques 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 engineeringproject 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 isproposed that the project modelling technique used by Niwa is modified and the concept ofwork package 'deliverables' introduced. Deliverables are a class of object which are producedwhen tasks are undertaken on objects to produce a product. Deliverables are not solelyproducts that are deliverable to clients, they can also be internal deliverables and as such usedagain 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 thephysical creation or design of project tasks. A method has been developed which is effectivein evaluating and ranking the complexity of each task and work package within a potentialproject. The method is centred on the work of Pahl and Beitz where work in engineeringprojects, 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 ofsolution configurations are used to create the initial project model. This model is thenpopulated using information relating to common project tasks and interfaces from historicalprojects. The tasks from the model structure are studied and evaluated according to theiroriginal content and the strength of their interfaces with other project tasks. Risk profiles foreach of the tasks within the project can therefore be produced in order to provide suitablepreliminary information for the accurate stochastic modelling of project cost. The projecttasks are ranked according to their effect on and sensitivity to other project tasks providing thetechnical team with an understanding of the risk of the proposed project.

The difficulty in generating a solution for each individual task, described as the 'SolutionComplexity', is evaluated during the tender by the technical team. The project tasks areassessed according to the originality of the task and classified according to the rating scale asfollows:

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 StructureMatrix (or DSM) [6]. The reason for using DSM's is the ability of the method to mapcomplex relationships inherent in engineering projects. By using the method, the relationshipbetween different project tasks can be seen to be defined as independent, dependent,interdependent parallel or interdependent coupled. The matrix is used to capture the taskinterfaces 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 interfacebetween the tasks must be evaluated on two levels. These two criteria are the level ofdependency that exists between tasks and the originality of the interaction.

For example, when considering the case of interface originality assume that undertaking adesign task, Task A, affects another design task, Task B, and both Tasks A and B have beenperformed many times before and essentially involve repeat working. The tasks are thereforelinked (A-B). However, both tasks have never been undertaken together during the sameproject. Thus, there exists a potentially a high degree of risk associated with the interfacebetween the tasks. The uncertainty concerning this interface must therefore be assessed inorder that its affect on the project can be evaluated. The originality of the task interface istherefore 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 ofreliance between the affected task and influencing task. The dependency which exists betweenthe 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 givenregarding the complexity of a task's predecessors and interface characteristics, the sensitivityof the task to its predecessors can be qualified. The task's sensitivity to previous solutionderivations proving unsuccessful can be identified using Equation 1. This score is used tohighlight how sensitive the particular task is compared to other tasks in the model. A list isestablished 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, thetask's influence on other tasks in the project can be qualified using Equation 2 and a rankingof the influence of project tasks established. This list will highlight the tasks with the potentialto generate risk within the project.

Equation 1:

Equation 2:

Where:T, = Sensitivity Rating of TaskTf = Influence Rating of TaskT0 = Originality Evaluation of TaskT'a= Originality Evaluation of Task Influencing the Task under considerationTd = Task Dependency Evaluation10 = Interface Originality EvaluationT'd= Task Dependency Evaluation of Task Influenced by Task under considerationI'0 = Interface Originality Evaluation of Task Influenced by Task under considerationm - Number of Tasks Influencing Task under considerationn = Number of Tasks being Influenced by Task under consideration

The levels of risk present within work packages can also be derived from studying the risk ofeach of the tasks within a work package. Comparisons can therefore be made with other workpackages within the current project and also with the levels of risk noted in similar workpackages from historical projects. The primary benefit of using the evaluation methods arerealised when attempting to quantify the estimated project cost using stochastic methods.

The methods of working and technical detailing employed by the studied company duringtendering have been found to be consistent with the project modelling configurationsproposed. The study of applying the methodology on a historical tender for a rail-based bulkhandling design has been undertaken and their design process mapped onto the work packagestructure. 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 theorganisation's limited time and resources.

5 Conclusions

This research paper identified the key areas where engineering companies can improvetendering practices. It was observed that engineering companies which design systems withstable product architectures can be aided by employing a risk evaluation method as a basis foraddressing the costing of their projects. By identifying the technical interfaces present withinengineering projects when tendering, the risk exposure of a company can be reduced at anearly stage. It has been noted that the primary means to reduce tendering uncertainty howeverrequires organisations to store tendering information in a re-usable format. The developedmethodology provides a valuable evaluation means for engineers to report their perception ofthe risk levels present in the tendering opportunity back to those making the commercialtendering judgements. It is anticipated that the research will enhance the risk managementprocedures employed by UK engineering companies and improve their relativecompetitiveness. Additionally, by improving the efficiency of the tendering process, the risklevels to which companies are exposed is reduced, thus aiding long term organisationalcompetitiveness.

References

[1] Phythian, G.J. and King, M., "Developing an expert support system for tender enquiryevaluation: A case study", European Journal of Operational Research. Vol. 56, 15-29,1991.

[2] Fayek, A., "Competitive Bidding Strategy Model and Software System for BidPreparation". Journal of Construction Engineering and Management. Vol. 124, No. 1, 1-10,1998.

[3] Crossland, R., "Risk in the Development of Design", PhD Thesis. University of Bristol,1997.

[4] Niwa, K., "Knowledge-Based Risk Management in Engineering: A Case Study inHuman-Computer Co-operative Systems", John Wiley & Sons :New York. ISBN 0-471-62893-X, 1989.

[5] Pahl, G. and Beitz, W., "Engineering Design: A Systematic Approach", The DesignCouncil :London. ISBN 0-85072-239-X, 1988.

[6] Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D., "A Model-based Methodfor Organizing Tasks in Product Development", Research in Engineering Design. Vol.6, No. l, pp. 1-13, 1994.

Gordon BarrDesign Information Group, University of Bristol, 83 Woodland Road, Clifton, Bristol BS81US, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

MODIFICATION OF A METHODOLOGICAL DESIGN TOOL FOR THEDEVELOPING COUNTRY SCENARIO - A CASE STUDY IN PRODUCT

DEFINITION

K M Donaldson and S D Sheppard

Keywords: Product definition, developing countries, sustainability, economic viability of newtechnologies, SMEs

1 Introduction

Product design for developing country markets sees additional and different constraints thanthe parallel process in an industrialized economy. This paper examines the donor-drivenmodel of technology development by evaluating a DfX (Design for "X") product definitionmethodological tool, the Product Definition Assessment Checklist as implemented by an East-African non-governmental organization (NGO). The modifications necessary to make theProduct Definition Assessment Checklist applicable are discussed along with lessons that canbe taken away for donors and product designers in both industrializing and developingcountries.

2 Background

2.1 The Product Definition Phase

Product Definition, in this paper, will be defined as the first phase of the product developmentprocess based on the works of Ullman [4] and Ishii and Kmenta [3]. Wilson defines thisphase as "the product development effort between the start of the project and the reviewmeeting 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 basedon user needs. The product definition phase, however, can be academically reduced to sub-phases: need-finding, bench-marking, and priority setting; each with appropriatemethodological tools that leads designers to the product definition statement. Wilson arguesthat a complete product definition should outline the product risks, the process developmentplan, the product channel plan, and the support plan of the company [6,7]. The productdevelopment organization must also recognize risks due to and constraints in the currentmarket and in its own institutional structure. An effective product definition statement shouldthen set forth the project priorities by identifying the goal(s) based on internal and externalconstraints, comprehensively defining the user need, and delineating the value to be deliveredin 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 marketby 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 tolocal manufacturers to be produced.

In the first two cases a full execution of the design process is impossible or unreasonable dueto the dearth of capital and inadequate entrepreneurial and technical skills, resulting in alimited product variety that inadequately meets customers' needs. Locally-made products incountries like Kenya face stiff competition from and displacement by imported products fromIndia and China (case 3) that subsidize their domestic manufacturing sectors to ensurecompetitive advantage in foreign markets. These cheaper imports are understandably lesssuitable at fulfilling needs, but nonetheless find a ready market in a society where comfortranks far lower in terms of customer priorities.

The abbreviation of the design process due to lack of resources most often occurs at the frontend: the product definition and the conceptual design phases are skipped; imports arereproduced, typically without modification to address local consumer needs. The reason iscomprehensible — there are no resources to risk on an "unproven" or "original" product. Incontrast, designers and engineers in industrialized economies, however, recognize theimportance of the product definition stage where the voice of the customer, needs, andspecifications are captured. Inappropriate decisions resulting from a poorly defined productsignificantly 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 pathof product development because resources exist to permit the full design process necessary toproduce a product that meets the local users' needs. The donor/NGO model of productdevelopment resembles the product development firm in an industrialized economy. Becausesmall- to medium-sized manufacturers (SMMs) often lack the capital and skills to determinecustomer needs, northern1 aid or donor organizations provide resources to specific southernNGOs for market research and technology development. This parallels the heavy initialcapital investment in market research that an industrialized firm makes at the start of theproduct development process. In past donors have also engaged in technology developmentthemselves, but with highly-publicized dismal results, and the growth of locally-situatedsouthern NGOs, the development efforts have been shifted from the donor to the NGO.

This "corporate" product development model represents a fundamental shift in foreign aidthinking: for a product to sustainably improve the lives of the consumers, it must be market-driven. 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 emergingeconomies.

506 ICED 01 -C586/410

distributors, and retailers. If the product is economically viable (i.e., affordable and offeringvalue to the user), its production and market are sustained although the donor and NGO haveexited the project.

Although NGOs (with donor assistance) and donors have the resources to implement and arein the position to influence local manufacturers by proving the benefit of a market-drivenproduct development process, this is infrequently effectively accomplished. NGOs typicallylack 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 someneed-finding scenarios, it may be determined that no action is the best solution at the currenttime 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 manufacturingenterprises can be broadly categorized as DfX (Design for "X") tools. DfX tools2 such asthose falling in to Design for Manufacturability (DfM), were developed (implicitly) for firmsoperating in industrialized economies, where success is increased profits by providing bettervalue to the customer through increased economic efficiencies in production and design.

Given the constraints of engineers and manufacturers in developing countries, why would itbe desirable or useful to employ methodological tools? Considering that DfX tools are notwithout drawbacks, this is a particularly pertinent question. DfX tools are attractive tosouthern design situations for two reasons. First, DfX tools particularly assist designers wholack formal design experience, and are removed from the consumer (not just geographically,but also culturally, economically, and educationally). Second, the nature of the NGO anddonor 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 examinemethodological tools for usefulness to the southern scenario as affordable products therepoorly address consumer needs. Wilson mapped the processes that successful andunsuccessful project teams used to create and manage their product definitions. The ProductDefinition 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 beconstrained, 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 tools3 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.

3 Hypotheses

This paper puts forward two hypotheses:

Methodological design tools are applicable (with modifications) and potentially useful tothe donor-driven product development process in developing economies.

The modifications necessary to make a tool applicable will highlight considerations fordesign teams developing products working in both industrialized and developingscenarios.

4 Application of PDAC-1 to a Developing Country Scenario

The Product Definition Assessment Checklist (PDAC-1) was evaluated for a developingcountry scenario by applying it in the product definition stage in the design of a product toassist rural farmers in central and Southwest Kenya access groundwater. The developmentorganization is an East African NGO, headquartered in Nairobi, Kenya, with the purpose ofpromoting sustainable employment and economic growth by researching, developing, andpromoting technologies appropriate for small-scale manufacturing enterprises in East Africa.Funding for the project is provided by a European bilateral aid organization. While this NGOis a forerunner in its field, this project is representative of the donor/NGO model whereproduct research and development is donor-supported with the technology then passed off tothe private sector for manufacture, distribution, and sale.

The NGO design team4 was composed of four engineers: 3 expatriates and 1 Kenyan. All ofthe engineers hold advanced degrees in mechanical engineering with a range of experience (3-15 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 extendedmeaning required), non-applicability (factor may be ignored), and completeness (additionalitems 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 primaryauthor and other members in a group setting. The exercise was structured in the context of

4 The NGO design team is not representative of most product development teams in the donor/NGO model. Atypical team may have one engineer with limited to minor technical experience in a developing or industrializedcountry. Other team members may be "handy" individuals with vocational skills and/or social scientists.

508 ICED 01 -C586/410

the stated needs of the rural farmers. The team had previously completed the preliminarystages of the product definition phase. Each PDAC-1 item's level of usefulness wasdetermined by informal group consensus intermixed with general discussion. The exerciselasted approximately 2-1/2 hours with roughly equal participation by all team members. Thenotes for each checklist item were then synthesized to create the modified PDAC-2.

5 PDAC-1 to PDAC-2

Although the discussion of PDAC-1 was framed within the context of a specific project, thedesign team's recommendations for modifications resulted primarily from their experiencesworking on past product development projects. Team members' responses differed based ontheir varying past professional experiences: whether they had worked primarily in adeveloping country, an industrialized country, or both. Engineers with the less overallexperience tended to notice discrete differences (e.g. "the bolts are in English and everythingelse 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 marketresearch 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 mappedto three constraint groups: institutional, design team, and/or local. Institutional constraints arethose related to the design team's support structure and funding source(s); however, externalto the team, but philosophically influencing their operations. Institutional constraints in anindustrialized scenario may be production schedules set by management to be consistent withcorporate 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 andinstitution, which include the customer, and the industrial, economic and culturalenvironment(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 bythe synthesis of the NGO design team's discussion, then if necessary, the modified PDAC-2checklist item [2]. For this paper, three checklist items (boldface in Figure 1) were selectedfrom each of the groupings: project priorities, core competencies, and localization.

2. Project PrioritiesPDAC-1: Does the team have an agreed upon hierarchy of measurable priorities based on the requiredpositioning?

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. Theproduct feature set, retail cost, and time to market are prioritized with the determination ofwhich should be constrained, optimized (given the constraint), and accepted.

In the industrialized scenario, the design team's project priorities are typically determined bythe corporate strategy for developing and marketing the product. However, in the developingscenario, priorities dictated by the donor-approved project plan may not match those that bestserve the end user. Two matrices are therefore necessary to recognize the possibility ofdiffering priorities. In the southern customer scenario, cost is almost always the constrainingfactor, followed by features that are optimized, and accepted time to market (within reason, ofcourse). Donors funding technology development will constrain time to market because ofthe project length specified in the project proposal. Cost and features are then optimized withcost often losing out to features that are set and met with user-based specifications. Figure 3shows the inherent mismatch.

Figure 2. Priority matrix Figure 3. Design team priority matrices

8. Core CompetenciesPDAC-1: Are all the core competencies, required for successful deployment of your project, identified andaccessible?

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 orcountries may be inaccessible. Steel sections are a good example. Design team membersknow that the available (locally-made) mild steel sections may vary as much as 5% in anydimension. Internal and external diameters varied unpredictably. Angles assumed to be 90°were noticeably not. Local manufacturers could arguably produce sections to highertolerance, but this would result in a prohibitively expensive product. The NGO then shiftedtheir focus to the composition of their design team, recruiting members with the experienceand skill to be able to design a robust product with expectations of supplier variance.

11. LocalizationPDAC-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 ofdeveloping countries. The existence and development of technology, among other things,promotes a "melting pot" culture of assimilation, but countries with poor infrastructures andlow technology usage maintain isolated pockets with "mosaic" cultures. The population ofKenya is composed of over sixty tribes, each with distinct languages and cultures. Traditionalgender roles, for example, may vary over a small region resulting in vastly different userneeds. Whereas number 2: "Understanding the User and Customer Needs" stresses theimportance of understanding user needs, this question reminds designers that it is likely thatthere 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 differentareas. First, (1) following the characterization of the donor-driven product developmentmodel; there is clearly an inherent conflict of goals as it presently exists. Secondly, (2)assumptions made during product development processes in industrialized scenarios do notnecessarily hold true in developing scenarios, and additional considerations are necessary.

(1) In mapping project priorities, donor resource allocation and timeframe are potentially indirect conflict with the product customer. Most donor organizations are allocated money by agovernment or governing body on a yearly basis. Projects then have set timeframes andbudgets 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 thedesign team has a high level of control over the eventual sustainability, and economicviability of a product. In a developing scenario, this is often not the case; the actions of thedesign team are only one of several factors influencing the product's success. External factorssuch as supplier reliability, skewed market forces, and government corruption will alsoinfluence the market success of a product.

6 Conclusion

Methodological design tools and techniques such as the PDAC-1 can be applicable withmodifications. 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 scenariohighlighted considerations, constraints, and limitations for design teams developing productsworking 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

ICED 01 -C586/410 511

1

2

3

4

5

6

7

8

PDAC-1Strategic Alignment: Does the team understand thestrategic objectives, the boundary conditions within whichthey need to operate, and the target market for theproduct?Project Priorities: Does the team have an agreed uponhierarchy of measurable priorities based on the requiredpositioning?Resources: Does the project have the staffing andfunding needed to make the project success?Management Leadership: Does the managementhierarchy collectively support the project and provideunified guidance for making decisions?Dependencies: For all functional areas, are both internaland external dependencies established and working well?Competitive Analysis: Has the team identified theproduct's top three competitors and projected what theywill be offering at the time of your product's release?Product Positioning: Does this project have a clear andcompelling benefit-based positioning based on user andcustomer needs and competitive advantages for eachmarket segment?Core Competencies: Are all the core competencies,required for successful deployment of your project,identified and accessible

PDAC-2Philosophical and Action Alignment: Does Theteam 's strategy address and align the donor andcustomer objectives, their boundary conditions, and thetarget population of the product?(No change in wording.)

(No change in wording.)

(No change in wording.)

(No change in wording.)

"Competitive" Analysis: Has the team distinguishedbetween and identified foreign competitors, indigenousproducers, and traditional practices?Product Positioning: Does this project have a clear,compelling, and immediate benefit-based positioningbased on user and customer needs and competitiveadvantages for each market segment?(No change in wording.)

ApplicabilityHigh-Medium

Medium

Low

High

Medium

High-Medium

Medium

High

9 Understanding User and Customer Needs: Has theteam verified the target market segment, its attractivenessin terms of size and growth rates, and identified thefundamental needs of the market, e.g. productivity, costeffectiveness, ease of use...?

10 Risk Management: Based on the business objectivesand project priorities, does the team understand the levelof risk it is taking?

11 Localization: Are the variations in user needs andcompliances understood by geography?

12 Compliances: Has the team identified all relevantcompliance standards?

13 Business Model/Financial Analysis: Is the project'scradle to grave financial and project plan complete andaccurate?

14 Market Channels: Will the appropriate market channelsof distribution be established prior to the market release?

Understanding User and Customer Needs: How hasthe project team identified the target populations?Are the fundamental needs and their respective driversof the markets understood?

Internal Risk Management: Based on the strategicobjectives and project priorities, does the teamunderstand the level of risk it is taking?External Risk Management: What are the potential(non-obvious) risks of introducing a new product tothis market?Localization: Arc the variations in user needs andcompliances understood by geography and culture?(No change in wording.)

Exit Strategy: Is the project's exit strategy and planrealistic, complete and viable?

Market Channels for Sustainability: Will theappropriate manufacturing, distribution, maintenance,and marketing channels be established prior to thecompletion of the product?

High-Medium

High-Medium

High

Low

High

High-Medium

7 Acknowledgements

The authors would like to thank ApproTEC in Nairobi, Kenya. This work was supported bythe 1999 New Century Scholars Program and the United States Engineering ResearchProgram 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'sExperience", Proceedings from the 6th International Conference on EngineeringDesign, Harrogate, UK

[2] Donaldson, K., 1999, "Product Definition Assessment for Developing Economies",unpublished full version of this paper.

[3] Ishii, K. and S. Kmenta, 1999, "Value Engineering — Value Identification andFunctional Analysis" in ME217A Course Reader, Design for Manufacturability:Product Definition, Stanford Bookstore.

[4] Ullman, D., 1992, The Mechanical Design Process. McGraw-Hill, Inc., NY, pp. 89-109

[5] Wilson, Edith, 1997, "Addendum: Product Definition Assessment Checklist" inME217A Course Reader, DfM: Product Definition, Stanford Bookstore, pp3.1A.l-2

[6] Wilson, Edith, 1993, "Product Definition: Factors for Successful Design," DesignManagement Journal, Fall, pp.62-68

[7] Wilson, Edith, 1990, "Product Definition Factors for Successful Design," M.E. Thesis,Stanford University, Stanford, CA

Krista M. DonaldsonCenter 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

AN APPROACH FOR STRUCTURING DESIGN SPECIFICATIONS FORCOMPLEX SYSTEMS BY OPTIMIZATION

C Grante, M Williander, P Krus, and J-O Palmberg

Keywords: Product planing, complexity management, complex design task, cost-estimation, product design specification

1 Introduction

Today's products are becoming increasingly complex with more and more features andfunctions. This complexity makes it difficult to determine which features to include in thedesign specification and which to exclude. Late implementation of features during the designprocess 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, inaddition to this, it has features such as safety and entertainment systems. By introducingelectronics and computers to control mechanical products (mechatronics), many additionalfeatures, such as active safety systems emerge. The products, and thereby their design,becomes more complex in comparison with traditional mechanical systems. These featurescan often use the same implementers in form of actuators and sensors which makes theselection 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 alarge disorganised complex problem they are able to break it down into sub-parts. In designmethodologies, eg, Pahl and Beitz [1], and Suh [2], the design process starts with therequirements (product design specifications). With the increasing complexity of products, thecomplexity of design specifications also increases, often making it too complex for the humanbrain to deal with. See Backlund [3].

Consequently, there is a lack of methodology in design processes for structuring designspecifications that can consider different features using the same implementers for complexsystems. This paper fills the existing gap by helping the designer to structure designspecifications for complex products by finding "one" optimal feature set: the one thatprovides maximum customer value in the given cost constraints (product cost anddevelopment cost). Features selection is influenced by customer value, complexity, andadditional cost.

This method is for specifying these features and functions set and not for describing otherrequirements, eg, environmental or legislative requirements for products that Schachinger andJohannesson [4] have described.

ICED 01 - C586/428 513

2 Method

The four-step approach to research: Criteria, Description I, Prescription, and DescriptionII, Blessing, Chakrabrit and Wallace [5], is used in this paper. The problem is described inCriteria, in the introduction of this paper. Measuring an improvement is described inDescription I, our solution to the problem is in Prescription, and evaluation of methods inDescription 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 companyusing it. Improved conditions are: increased profitability or decreased loss, increased marketshare, etc. Measures for these parameters are doomed to fail since the environment (all otherparameters) does not remain constant. Instead the simplest and most effective measure is tocompare selections previously done with the tools selection system and compare differencesin cost and customer value with history and this selection method. We do not achieve anyultimate validation, but we can measure if the current method can select an improvedcombination of complex systems or not.

To see if the method affects parameters that not are directly linked to profit, the number ofdesign changes, time to market, and customer desire of features, were also investigated byinterviews with several people who used the method in the Chassis department at Volvo CarCorporation (VCC). A simple scale containing negative effect, no effect, and positive effectwas used.

2.2 Definitions

All products provide the customer with one primary function and in most cases severaladditional features. Technical functions are needed, ie, be electronically controlled toimplement features/functions such as brakes, radar sensor, and airbags in an active car safetysystem. One technical function can be used by several customer functions and features. SeeFigure 1.

Figure 1. Each ellipse represents a customer feature and each dot a technical function. If a technical functionis 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) toprovide the customer with and how to implement them are made. The aim is to get as high acustomer 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) andstill keep within the limits stated.

concept value = E(value of customer features) - (cost of technical function implementing thecustomer functions) (I)

Mathematical model

Where the value of concept customer functions = EM (Bk,i*Vj)

i = integer representing a specific customer featurek = integer representing a specific conceptM = the total number of customer features possible to implement in the productBk,i = one if the customer feature i is a part of the solution k and zero if it is notVi = 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 functionAi,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 notRj = the cost of the technical function jx = the value of a technical functionN = the total number of technical functionsU = 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 andthereby the cost. This means that if a technical function is used more than once in a solution itstill does not cost more to implement.

Different limitation factors are considered by using a utility factor a. Using a, the customerfeatures scale varies in relation to the technical cost scale. Using this approach different costbudgets can be modelled. This gives the following function:

O = 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 iscoupling that makes this method unique. Choosing which customer features to implementdepends on customer value, added product cost and if different customer features can berealised using the same technical functions and thus sharing the overall cost. In the Ai,j matrixa 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 alltechnical functions using it must also be implemented.

Customer Function

We have used two different approaches, par comparison and customer price, to generate thevalue of customer functions Vj.

Par comparison is a subjective comparison of the customer functions in a relative scale. It wasfound that the evaluation matrix, Figure 2, was the best tool for this comparison. Evaluationtools using data such as the Pugh matrix [7], and the Kesselring matrix [8], lead toinconsistencies between the numerical scale created and our perception. The evaluationmatrix does not have this problem since each customer feature is compared with all otherfeatures. It is also easy to use since it requires less input then second approach. Thedisadvantage is that it is less accurate and that many comparisons have to be made, (n2-n)/2where 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 meansthat 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 relativeimportance of the features is created.

The second approach is to compare a customer desire for a feature based on the amount thecustomers are prepared to pay. In this case, the numerical scale is the actual price. The majoradvantage with this approach is the absolute scale using zero, which is not used in theevaluation matrix. Using this approach the number of "decisions" only aspects increases in alinear manner with n and also provides the possibility to predict product earnings at an earlystage. The disadvantage is the difficulty in making estimations when dealing with functionsthat are new and have never been on the market. It is significantly easier to say if a feature isdesired more or less than another one is is, than to estimate how much a customer is willing topay for it.

Technical functions

The creation of a numerical scale for the cost of the technical function uses two similarapproaches to the ones used for customer features. The approach that was favoured is theestimation of the cost of each technical function. In the estimation the development cost of thetechnical function, part cost, and product volume is considered. The other approach iscomparison evaluation. It is the same technique as for the evaluation of the customer featureswith different evaluation criteria in the form of the complexity of the technical functions. Thecomplexity was chosen as it was considered to be the cost driver. This second approach isused 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 = the number of calculations for the value of concepts, ie, number of computations of(II)

n = the number of possible customer featuresk - the number of customer features chosen

For small problems it is possible to calculate all combinations of customer functions but whenthe problem increases in size the number of computations increases rapidly, thus making itimpossible for current computers to calculate within a reasonable time-frame. In order tosolve these problems optimisation is used.

In order to use effective optimisation techniques the problem is reformulated and is seen ascontinuous rather than a discrete optimisation problem. Fuzzy logic approach is used wheretechnical 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: F(X1, x2... XN)

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 theCOMPLEX-RF [10] algorithm based on the COMPLEX optimisation algorithm by M. J. Box1965, 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.

j is an index that indicates a parameter set in the complex and i an index that indicates avariable, rij is a random number in the interval [0.1]. If the implicit constraints are notfulfilled, 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 ateach point. The point having the lowest value is replaced by a point reflected in the centroidof the remaining points by a factor: a.

Box (1965) recommends a= 1.3. If a point is repeated as the lowest value on consecutivetrials, 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 theCOMPLEX from collapsing prematurely. The second is: the introduction of a "forgettingfactor" that gradually removes the influence of old parameter sets in the complex.

3 Example

This paper contains an example in order to understand the method more easily and it alsocontains 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 featuresand their technical functions are:

Anti-lock Braking System (ABS), which prevents the wheels from locking duringbraking. ABS uses the technical functions Controlled Brake and Wheel Speed.

Traction Control System (TCS), which interacts with the engine and brakes to prevent thewheels 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 acritical situation. The BA uses Controlled Brake and Brake Pedal Position.

Electronic Stability Control System (ESP) [11], which prevents the vehicle from skiddingby interfering with the brakes. The TCS uses Controlled Brake, Driveline TorqueEstimation, and Yaw Rate Sensor.

The coupling matrix for the example, value and cost is shown in Figure 3. Note that this is anexample 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 hasthe highest profit margin (2000-1000-500=500). If the budget is increased to 2500, ABS andTCS 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 mostprofitable with (2000+2000+2000-1000-1000-500-250=3250). The above is visualised inFigure 4. Of course all features can be implemented with a high enough budget and then thismethod 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 thatprovide the highest profitability for limited development budgets. For a real project this isimpossible because of all the combinations possible, then this method is useful. A projectconcerning 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 combinationsof features that could be chosen.

Figure 4. The optimal set of customer features using different budgets. The black marking indicates the useof 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 asFigure 4 but is for the more complex problem.

4 Result

The results of the example at VCC is shown in Figure 6 where active safety features for a carmodel 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 samecriteria as this new method. The comparison above shows an average increase of 100% incustomer value with sustained cost using the method presented. An interesting result is thatthe 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 ofdesign changes. A reduced number of design changes were made in the project. There was nomeasurable effect on time to market and it had a positive effect on customer desire of featuresthat were implemented in the product.

Other results that could be seen: the designers found it positive to focus on the technicalfunctions instead of the customer features/functions, which they do at present.

5 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 methodhad an effect on other parameters that not are directly linked to profit. It was found to have apositive effect on a number of design changes and customer desire of features, but changes intime to market could be seen.

By using this structure when making product design specifications for complex systems it ispossible to choose an improved set of features and functions to be implemented in productdesign specifications. This will lead to a reduction in late changes, products of greater valuefor 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 Buyer-Supplier Relations, Department of Mechanical Engineering, Linkoping University

[4]. Schachinger P. and Johannesson H. (1999), A Method for Computer Based Specificationof Products, Department of Machine- and Vehicle Design, Chalmers University, Goteborg

[5]. Blessing , Chakrabarit, and Wallace (1998), Designers - the Key to SuccessfulDevelopment, pages 56-70 , Springer-Verlag, London

[6]. Wordsworth (1996), Software engineering with B, ISBN: 0-201-40356-0, AddisonWesley, 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 othermethods, 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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

AN ENGINEERING APPROACH FOR MATCHING TECHNOLOGY TOPRODUCT 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

1 Introduction

Most formalised product development processes are oriented towards an initial focus on thecustomer of the product. These processes are often categorised as "market-pull." Thiscustomer-orientation is generally justified as starting development from the customer sideprovides a basis throughout the process for evaluation of design alternatives and assessmentof product performance. Common wisdom among marketers and product developers is thatthe market-pull approach yields more "successful" designs than alternatives.

This singular view of product development processes neglects the strategies and needs oforganisations that create and/or own technologies that they wish to capitalise on by makingthem an integral part of a product. Product development processes that are oriented towardsan 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 astructured 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 canpresent enormous benefits to an organisation. Besides helping ensure successful developmentof a technology, it also facilitates the creation of lucrative new markets and spreads researchcosts over a broader product base.

While there has been much work done on topics that are related to development of newtechnologies and the associated need for innovation, there has been relatively little discussionon 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 ofchallenges 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 exploredis how to find a focus for the viable product options that could embody the technology. Thiswill be accomplished by first reviewing past research in relevant areas. Then the flow ofinformation through the two types of product development processes discussed above will bedecomposed. Based on this information flow, a generic technology application selectionprocess is formulated. Finally, a method for evaluating the appropriateness of a given productapplication for a technology is presented.

ICED 01 -C586/643 521

2 Background and Literature

There are four major fields of study the authors have found that impact and provide abackground for definition of a technology-push product development process. This sectionbriefly addresses design processes in general, research directions in innovation, technologytransfer 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 areinitiated with customer/market data. Take for example the widely recognised processpresented 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 thepotential effectiveness of developing a product in this way, often companies have atechnology they wish to embody in a product(s), without foreknowledge of the customers. Astructured, 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 commerciallyviable. Technology-push product development can be considered a subset of this broad fieldof innovation. While much has been written about different methods for innovating, little hasbeen written on this particular category of innovation. Other forms begin with a sensed needor target customer and look for a technological solution. This form begins with a specifictechnology 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 fortechnology development versus product development are so dissimilar, the two are usuallyorganisationally separated from each other. To make the transition from technologydevelopment to product development, many have engaged in technology transfer, a methodfor taking the knowledge generated in the former stage and embedding it in a developmentteam that can take it to market. The problem with this, however, lies in the fact that thedevelopment is usually targeted to one product, prematurely narrowing the application optionsand stimulating biased evaluation of the technology feasibility. Despite the applicability oftechnology transfer concepts, technology transfer does not preclude the need for a formalisedapplication 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 adistinct process is needed to manage the integration of technology from research intodevelopment. lansiti even recommends the establishment of a separate organisation to holdresponsibility for technology integration. This article supplements lansiti's strategic,organisational insights with a practical, executable engineering process.

522 ICED 01 -C586/643

3 Information

The product development process deals with a myriad of information. The "process" itself issimply a way of creating and arranging this information so it is available to facilitate decisionsat appropriate times [5]. The technology-push process can best be understood through ananalysis of the input information and how it is used throughout. This section decomposes thegeneral information types, explains how information flows through the process, and contraststhis with market-pull development.

3.1 Information categories

An analysis of the development process shows that information involved in the process can begrouped into four basic categories associated with the following:1. Customer - the intended purchaser or user of the product and other stakeholders2. Needs - the specific objectives a customer(s) seeks to fulfil with a product and desired

attributes of the product3. Product - technology embodiment, intended to satisfy customer needs4. Technology - the application of scientific knowledge

Based on these designations, product development could be defined as "the realisation of aproduct through embodying technology in a manner meant to satisfy customer needs."Technology-push product development is "the realisation of a product through embodying aspecific technology in a manner meant to satisfy customer needs." Market-pull is "therealisation of a product through embodying technology in a manner meant to satisfy needs ofa specific customer set." The fundamental difference between market-pull and technology-push is not the type of information dealt with, but rather the informational starting point andthus how it is processed.

3.2 Information flow

Essential to understanding how this information is processed is the order in which it isencountered and utilised. While information from each of the categories shows up throughoutthe process, most of the major steps can be classified by the category of information primarilydealt 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 theyestablish guidelines (specifications) and architectural concepts for the product (step 2).Technologies are identified to fulfil the concepts generated (step 3). Upon selection of theoptimum architecture (technology integration), developers design the product and productionprocesses (step 4), evaluate the product against customer needs (step 5), and deliver it to thecustomer (step 6). Figure 1 gives a graphical representation of the first three steps of thisprocess, with the steps being numbered. For the sake of this article, we will focus only onthese 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 ofthe technology-push process. The order is significant primarily as it relates to the ease ofprogression. The end objective is to have sufficient knowledge about each information type tobe 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 informationnecessary 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 needsthat it satisfies (step 1). They then are able to choose a product embodiment of the technologyto meet the needs (step 2). Next they identify customers who possess the needs and thuswould 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 hastransitioned 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 variationin difficulty level lies in the way information is evolved. The steps in market-pull are discreteand 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 waysto 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 productapplications given a single technology is more difficult.

Another way of saying this is that each of the "queries" in a market-pull process is moreclearly bounded than in technology-push. Needs are bounded by the customer base andtechnologies are bounded by the product needs. For technology-push, on the other hand,product applications are bounded only by generic characteristics of the technology andpotential 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 ofneeds, 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 thegreatest opportunity for those who can successfully execute it. Rather than limiting, it opensup the field of potential customers, allowing an organisation to leverage its current resourcesand 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 theinitial one it may have been intended for. It motivates people to explore technologicalopportunities and exploit all possible applications. The challenge lies in finding ways toquickly identify and evaluate application opportunities with an open-ended project.

4 A Generalised Technology Application Selection Process

The information presented so far lends itself to the creation of a process for technology-pushproduct development. Our focus will be on matching technologies to product applications.This will be accomplished by presenting a technology application selection process that takesplace before full-scale development. Following are the general phases that each project shouldpass 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 thefunctionality and properties into needs the technology could satisfy. While this may start withgeneric descriptions of the technology, a development team should seek to evolve these intoas specific categories as possible to ease the difficulties of being open-ended. Knowledgeabout 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 (technologyapplication concepts). This should be an open-ended phase with focus more on quantity thanquality. This should be a creative stage, where structure is undesirable, as it inhibits thecreative process. The creativity of this stage makes it inherently difficult to systematise. Theneeds 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 traditionaldevelopment process focuses on narrowing down concepts to make only one final product, themultiple concepts generated by this process should be evaluated and pursued separately. Thisis why objectivity is particularly important, but difficult in technology-push productdevelopment. This "application evaluation" phase is a milestone determinant of productdevelopment success. If only suitable applications are allowed to pass, the projects are likelyto prove successful. If too many applications are denied, the organisation has foregoneattractive opportunities.

In evaluating the feasibility of a project, it is particularly important to ensure that it cantransition from technology-push into market-pull. To do so, suitable customers must beidentified and the concept must be evaluated based on their tastes. This phase is discussed inmore detail below.

5 Application Evaluation

As mentioned above, the application evaluation stage has a particularly strong influence onthe eventual outcome of a project. This section assesses different approaches for evaluating agiven application.

5.1 Scoring

A common way to simplify complex decisions based on various factors is by weighting andscoring. 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 scoreeach of the concepts for the different factors. These scores can then be compiled to give anoverall rating for the product [3].

Scoring is particularly relevant to technology-push project evaluation because of the widevariety of considerations that come into play when assessing project viability. These issuesinclude 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 manycriteria, technology-push projects should not necessarily be evaluated relative to otherconcepts, but rather for their independent viability. The purpose of application evaluation isnot to select from multiple alternatives, but to assess the viability of each individualalternative. If ten concepts seem likely to prove profitable in the long-term, why should theybe 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 mostcommon 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 aninvestment is more profitable over time than other possibilities. To compensate for theinability 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 projectindividually. 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 theexpected financial performance. The method's comprehensiveness is also its greatestweakness. The calculated value of a project is wholly dependent on the underlyingassumptions; 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 areasonable estimate for the viability, we delve into the factors that seem to governperformance. Specifically, we want to look at the functionality of a given technology in acertain product application.

5.3 The Function Gate

Certainly, function would be a heavily weighted factor if we were to use a scoring matrix toselect a potential application. An assessment of functionality would also determine many ofthe 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 forthe pie. If a technology does not have the desired functionality for a certain application, it willnot 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 takeninto consideration, greatly simplifying the decision-making process. Secondly, it clearlydelineates the benchmark product, making competition and customers much more explicit andthe subsequent assessment more accurate. Thus it accomplishes the purpose of applicationevaluation as explained in the process section of this paper—it moves the team from productknowledge to customer knowledge. Finally, it builds on the information already developed inthe technology-push process, which was founded on an understanding of the technology andhow its functionality could satisfy customer needs.

Recognising the function gate as the preferred method for initially evaluating a technologyapplication, functional decomposition can be used to evaluate functional performance [7].This can be done by first identifying the product "flows". Flows include energy, materials, orsignals that go into and come out of the system. From these system-level flows, a functionchain should be developed to represent the different transformations that take place within thesystem to accomplish the overall transfer function [8]. The precise functions accomplished bythe 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 product—such as cost orweight. Each part within the system contributes to the overall constraint characteristic. Bycharacterising both the flows and system constraints, we gain a clear understanding of how agiven technology functionally compares to the incumbent technology in a specific application.

Functional decomposition establishes a clear delineation of the benchmark a technology ismeant to replace. The difficulty of potential development is reflected in the level ofcomplexity of the benchmark. If the technology simply replaces an existing component, andmeets 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 anentire product or is a new product altogether, the development will be more difficult thaneither of the two prior scenarios.

6 Conclusion

Various processes have been developed to systematise product development. Most of thesefocus on market-pull development because customer demand is necessary for successfulcommercialisation. Technology-push development begins with a technology rather than thecustomer, but the same categories of information are dealt with as in market-pulldevelopment. While the open-ended nature of technology-push development makes it moredifficult to successfully complete, its unrestricted nature also opens many opportunities forleveraging technology development to access new customers and new products.

Based on the flow of information through the development process, a generic process fortechnology-push development was presented. One of the crucial steps in this process isapplication evaluation. Methods for effectively evaluating the viability of technologyapplications were assessed, with the functional gate being the most fitting.

References

[1] LaZerte, J. D., Market-Pull/Technology-Push, Research Technology Management,Mar/Apr 1989, Vol. 32:2, Washington D. C.

[2] Schulz, Armin P., Clausing, Don P., Negele, Herbert, and Fricke, Ernst, Shifting theView in Systems Development - Technology Development at the Fuzzy Front End as aKey to Success, Proceedings, 1999 ASME Design Engineering Technical Conferences,Las Vegas, NV.

[3] Ulrich, Karl T. and Eppinger, Steven D., 2000, Product Design and Development,Second Edition, McGraw-Hill Publishers.

[4] lansiti, M., 1998, Technology Integration: Making Critical Choices in a DynamicWorld, Harvard Business School Press

[5] Mistree, F., W. F. Smith, B. A. Bras, J. K. Allen and D. Muster (1990). Decision-BasedDesign: A Contemporary Paradigm for Ship Design. Transactions, Society of NavalArchitects and Marine Engineers 98: 565-597

[6] Udell, Gerald, Evaluating Potential New Products, Private Press, 1998.

[7] Koopman, P. J., A Taxonomy of Decomposition Strategies Based on Structures,Behaviors, and Goals, Proceedings, 1995 ASME Design Engineering TechnicalConferences.

[8] Kurfman, Mark A., Stone, Robert B., Van Wie, Mike, Wood, Kristin L., and Otto,Kevin N., 2000, Theoretical Underpinnings of Functional Modeling: PreliminaryExperimental Studies, Proceedings, 2000 ASME Design Engineering TechnicalConferences, Baltimore, MD.

Spencer P. MaglebyBrigham 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 DESIGNICED 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 ofsuch 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 aslead, makes the offer, negotiates with the customer and when it comes to the deal, takes all therisks. Sometimes certain development expenditure is necessary in order to be able to producethe product. There is of course a risk, mainly of technical nature, to exceed the agreedpayment.Innovation projects are different. In innovation projects a company spends money beforebeing sure how to sell the product at all or how to cover sufficiently the expenses. Incollaborative new product development (CNPD) the costs and the gains, the risks and thereward need to be shared. CNPD therefore demands a high level of trust and familiarity withthe partner and his skills.

Existing Virtual Enterprises offer a highly interesting platform for collaborative new productdevelopment since there is a close personal relation and the partner's skills, capacities andcompetencies 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 theycould not realise alone, since really innovative projects require a lot of development work oreven basic research.Bigger projects can be realised, when the partners can agree on the financing structure. Theremay still be a need for an external financing.

2 Financing innovations

From a general financial point of view innovation projects must be financed with proprietarycapital [1]. Credits are given only against sufficient liabilities. The required capital can comefrom inside the company (self-financing) or from outside in form of a participation capital. Inthis 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 businessangels, 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 vetofor important decisions, monthly reporting etc.).

Exit-regulation:Already at the beginning of the project the exit of the investor is planned. Usually aventure 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 innovativecompanies in an early stage [4]. In order to receive venture capital the enterprise must have adetailed business plan, sometimes even a prototype and seriously interested lead users. It isgetting increasingly uncommon that venture capital is given in an earlier stage.

People who invest earlier (seed stage) are called "Business Angels". They always haveexperience in the specific branch, experience (e.g. from a former own entrepreneurship) andmoney to invest. Business angels sometimes do not need a written business plan and are ableto take their decision on a fast and informal basis [5]. They often have also a high personalinterest beside the financial gain. 75% of the business angels invest between 15'000 and150'000 Euro [6]. The business angel market starts to get better organised in continentalEurope. 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 conceptup to the prototype. In the start-up stage usually the enterprise needs capital for the marketlaunch.

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 MioEuro). So-called "special purpose vehicles" are created [7]. All partners found a companytogether. It is not efficient founding companies for each project until it is not sure that theproject will be realised. The classical characteristics of project financing are Cash FlowRelated Lending and Risk Sharing [8]. These elements are also found in the financing ofinnovation projects. Figure 2 compares the financing sources both the financial and theinnovation 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 angelsfocus on new enterprises. In later stages there is a minimal investment. Below this the costsare higher than the possible revenues. There is a financial gap for small and medium sizedprojects (< 500'000 Euro) and for early stage financing of low-tech projects. 18% of theEuropean manufacturers mentioned in a survey concerning innovation carried out byEUROSTAT that the lack of suitable financing sources lead to significant longer projectduration [10].The main issue is the 'chance/risk relation'. If this relation is unfavourable, there are notmany possibilities of getting capital. Within low-tech fields the chances are often judged to beinsufficient anyway. Early stage financing (pre-seed and seed money) is widely used for thefast growing industrial sectors biotechnology and health care. Even companies of the high-tech and IT/Internet sector find it difficult to receive seed money. For the low-tech sector it isout of reach.

ICED 01 - C586/315 531

The finance institutes need to carry out some structural changes to be able to offer smallerventure investments. One way is of course the standardisation of the investment appraisalprocess, 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 inthe project. These partners must bring in added value in form of branch experience, technicaland/or market knowledge.

In the following paragraph the idea of a financing network is presented. The industrialpartners, different service providers, basically finance the investment [11]. The financialservice 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 moresupport on the financing or insurance side is required. Insurance companies often have strongrisk management skills. A venture capitalist can be included for the financing of theexpansion 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-operate-transfer) projects [12], [13]. The network has the following characteristics:

Participation of all partners (initiator, primary partner, technical, marketing and financialservice 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 projectperformance

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 innovationprocess

In the idea filter (Gate 1 of the innovation process) the most interesting projects are chosenaccording to different criteria (e.g. success chances, strategical focus, feasibility, marketattractiveness, competitive advantage). After a project has been chosen, the preliminaryinvestigation begins. Different tasks have to be carried out by the partners in the network (seefigure 5).

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 businesscase. In this stage a detailed investigation takes place and the project is defined in detail. In

ICED 01 - C586/315 533

Initiator

Rough CapitalBudgeting

Estimation of theexpected earnings

Formulation of theproject objectivesand strategiesIntuitive RiskanalysisOperative projectmanagementPreparation of thepresentation

Financing SPMarketing-SP/Technical SP

Rough marketanalysis

Rough competitionanalysis

Characterisation ofthe market segments

Evaluation of thetechnical feasibilityCheck the state oftechnical knowledgePreparation of thepresentation

Primary partner

Determination ofproject-specificsynergiesDetermination ofcomplementary corecompetencies

Preparation of thepresentation

this stage a considerable amount of capital may be needed. The sharing of possible losses orgains 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 thereward and risk sharing agreement may be adapted. It is important, that at any time of theinnovation process the sharing agreement is clear. If a project needs to be stopped, the sharingof the accumulated costs are clear. Otherwise there will be discussions who has to coverwhich costs.

Figure 6: Checklist of the tasks in the "detailed investigation" stage of an innovation process

Initiator

Building detailedbusiness case

Specification of theproject structure

Detailed capitalbudgeting

Creation of a riskfactor list

Operative projectmanagement

Preparation of thepresentation

Financing SP

Coaching the makingof:- planned income

statementplanned balancesheetcash flowstatement

- determination ofcapital need

Determination ofuseful contactsDetermination ofsuitable financingconceptsDetermination ofpotential investors(business angel,venture capital)

Marketing-SP/Technical SPDetailed marketanalysis (size,growth, trends)Detailed analysis ofcompetitors (marketplayers, marketshare)Determination ofappropriatemarketing strategiesPreparation of thepresentation

Primary partner

Offering the corecompetencies

Determination ofpotential customers

Determination ofuseful contacts

Preparation of thepresentation

Similar to the different financing rounds in a venture capital project, the value of the workalready done has to be calculated (=pre money-value). For the estimation if the pre money-value not only the cumulated expenses but also the value of the elaborated know-how isconsidered. In a financing round the investor brings in a certain amount of capital. The sum ofthis capital and the pre money-value is named post money-value. The participation iscalculated based on the ratio of the postmoney-value.

Different sharing philosophies are possible. Each company carries its own risk (no risktransfer), the risks are beard solidary, and some risks are shared according to a defined sharingrate. The total amount of the risks may be considered for the reward sharing. Another optionis an incentive agreement where only parts of the risks are considered. At least one can saythat the risk and the reward sharing are interdependent and have to be set together. Thesharing 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 atechnical and cultural point of view. There is sufficient trust and experience between thepartners. Trust can easily build up when a new project is started. Virtual enterprises combinethe strength of a stable network by offering member companies a stable environment, theclose and trustworthy co-operative culture of an internal network, and the flexibility andcompetitiveness of a dynamic network [14]. Existing virtual enterprises, which focus onproduction at the moment, could move forward and make a higher added value by offeringown 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 existingvirtual enterprise or offer a platform for other enterprise networks.

5 Conclusion

There are not only advantages of such a virtual enterprise including different service providerswho participate in the gain and losses of innovative projects. The following difficultiesremain:

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 anarrangement

ICED 01 - C586/315 535

Nevertheless such a financing concept allows to realise innovation projects, which are too bigfor 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 financialinstitute could even promote an investment fund, which invests in existing SME and theirmost innovative projects. At the moment there are efforts in integrating a bank in an existingvirtual enterprise (consisting of only production companies) as a kind of a "house bank".

References

[1] Boemle M.; ,,Unternehmensfinanzierung," 12. Auflage, Zurich, 1998

[2] Brealey R. A. and Myers S. C.; ,,Principles of Corporate Finance," 5th ed.,McGraw Hill, New York, 2000

[3] European Private Equity & Venture Capital Association (EVCA); ,,Yearbook2000," Vanden Broele Graphic Group, Bruges, 2000

[4] European Council of Applied Sciences and Engineering; ,,Engineering andVenture Capital in Europe," Euro Case Venture Capital Steering Group, Paris,1998

[5] Lipman, Frederick D.; ,,Financing Your Business with Venture Capital," PrimaPublishing, USA 1998.

[6] LIFT; ,,Financing Innovation - A guide. Linking Innovation, Finance andTechnology," Luxembourg, 2000.

[7] Tytko D.; ,,Grundlagen der Projektfinanzierung," Schaffer-Poeschel, Stuttgart,1999

[8] Finnerty J. D.; ,,Project Financing," Asset-Based Financial Engineering, JohnWiley & Sons, New York, 1996

[9] Cooper, R. G.; Product Leadership. Cambridge, Perseus books, 2000

[10] Community Innovation Survey, "EUROSTAT: Theme 9 / Innovation," EuropeanCommission'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, Risikoverteilung undStreitbeilegung," Betriebs-Berater, pp. 2-12, 1998.

[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 networkorganizations," Entrepreneurship & Regional Development, vol. 11, pp. 203-229,1998.

Patrick Link and Spyros SpiroudisFederal Institute of Technology Zurich (ETH Zurich)Department of Industrial Engineering and ManagementZurichbergstrasse 18, 8028 Zurich, SwitzerlandPhone: ++41 1 632 05 47, Fax: ++41 1 632 10 45E-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 DESIGNICED 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.

1 Introduction

The overriding aim of much of the engineering design research is to improve the performanceof the design process, and consequently the product development process. Much has beenwritten within the product development literature on the performance of the productdevelopment process [1]. This work has been largely focused on the analysis of performanceat the project or program level. The ability to relate the different research and draw genericlessons from the results has been stifled by the lack of consistency on the meaning ofperformance both at a generic level [2] and more specifically in design/development [3]. Forexample, although product and process performance have been distinguished within existingwork 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 particularemphasis on design/product development, highlighting the main weaknesses in work to date.A fundamental and generic model of performance, related to knowledge based activities indesign, is then presented. The model describes performance in terms of its key elements,efficiency and effectiveness, and provides a basis for modelling performance across differentprocess levels, i.e. project, program, etc.

2 Research in design performance

The research reviewed here forms part of the overall research in the area of performance oforganisations. Some of the work is generic in terms of being applicable across all businessprocesses 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 mayvary widely and include empirical studies aimed at determining relationships betweenperformance in different processes, the design and implementation of approaches formeasuring 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 werepublished. He refers to the growth in membership of accountancy institutes, and number ofconferences on performance, as indicators of the increased interest in this area. However, incomparison to areas such as manufacturing, measuring the performance in product design isrelatively 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 listof over 90. Many authors have recognised the particular difficulties in measuring theperformance in design/development activities [4-6]. These difficulties arise from the lesstangible nature of outputs from design activities, i.e. knowledge, the often long duration andwide range of influences from design to market launch, the difficulty in defining/measuringdesign 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 anindication of the move toward measuring less tangible aspects of performance, e.g. thoserelated to knowledge intensive activities in design. Johnson and Kaplan [7] suggest thattraditional accounting methods are unsuited to organisations where the product life cycle isshort and research and development assume increased importance.

Within the scope of this paper two areas of existing research in performance are brieflyreviewed, i.e. the definition/modelling of performance and the relationship between designand design activity performance.

2.2 Defining and Modelling Performance

The literature on performance is characterised by a lack of, and inconsistency in, definition ofterms. Numerous works have been published which directly address the area of performancebut do not explicitly define performance itself. Neely [8] in his review of performanceliterature suggests that "Performance measurement is a topic which is often discussed butrarely defined". Meyer [9] suggests that there is "massive disagreement as to whatperformance is" and that the proliferation of performance measures has led to the "paradox ofperformance", i.e. that "organisational control is maintained by not knowing exactly whatperformance is". That is, the lack of a comprehensive understanding of performance can oftenlead to ignorant acceptance of particular approaches, metrics, etc., proposed by seniormanagement in an organisation.

The authors defining performance in terms of its key dimensions (metrics) primarily describethose dimensions within the areas of Time, Cost and Quality. The dimensions of time andcost can be relatively easily understood and applied within performance measurement but theconcept of quality is somewhat similar to performance itself in terms of its variedinterpretation, 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. Forexample, 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 addunnecessary cost/overhead in a stable environment. Flexibility will influence theperformance, i.e. efficiency and/or effectiveness of an activity/process, but does not constitutea dimension of performance itself.

In summary, the research in performance has been hindered by a lack of clarity on itsmeaning. In particular:

The key elements of performance have not been consistently defined or agreed.

Those defining performance as efficiency and effectiveness have not distinguished themclearly and/or related them within a formalism of performance.

Many of the measures used in the research relate to influences on performance and notperformance itself.

2.3 Design and design activity performance

Design activity modelling has received significant attention over the years aiming at thedevelopment of both descriptive and prescriptive models. This has resulted in thedevelopment of models offering different viewpoints of the design process such as theprescription of the activities/stages in design and their logical sequence, others focused on thecognitive nature of design and those relating design within an overall model of productdevelopment. These models are aimed at increasing our understanding of design(descriptive), and/or providing a framework (procedures, guidelines, etc.) in which to carryout 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) andthe activities involved in producing that design. That is, both design (DG) and design activitygoals (DAG) exist within design development and performance in relation to these goals mustbe distinguished yet related to overall performance. Design goals relate to aspects of thedesign (artefact) such as its dimensions, its form, etc. while design activity goals relate to theactivities in design development and consider aspects such as the time taken and cost ofresources.

There is a reasonable consensus within existing models on the types of activities involved indesign, their sequence, etc., and the evaluation of the output in relation to the design goals is akey component of the models discussed. However, the analysis of performance in relation tothe activities carried out in design is restricted to literature addressing the management ofdesign at the project level, e.g. [10]. It is proposed here that management activities are carriedout at every level in design and therefore there is a requirement to analyse performance inrelation to such activities at all levels.

3 A design performance model - E2

Although there is widespread use of efficiency and effectiveness to describe performancethere 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 ofperformance 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 thephenomenon of design performance and allow efficiency and effectiveness to be distinguishedand related. Efficiency is related to input, output and resources, while effectiveness isdetermined by the relationship between output and goal(s). These elements are presentedwithin 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 aknowledge processing activity (Ak) (Figure 2), the difference between the output (O) and theinput (I) defines the knowledge gain from the activity (K+). The cost* of the activity may bedetermined by measuring the amount of resource knowledge used (Ru). Therefore, theefficiency of this activity may be depicted as in Figure 2 and formulated as a ratio:

Where:n(Ak) : Efficiency (n) of an Activity (Ak)I : Input (Knowledge)O : Output (Knowledge)K : Knowledge GainRU : Resource (Knowledge) Used

Figure 2. Efficiency (TI)

This formalism assumes that a quantitative comparison of the input and output knowledge canbe 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 andthat 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 ofthe input, output or resource knowledge. For example the cost of using a designer within anactivity may be measured to reflect the amount of financial resource used in utilising thisknowledge 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 andapplication of metrics to determine efficiency allow particular views of efficiency to becreated, 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. Thedegree to which the result (output) meets the goal may be described as the activityeffectiveness. Therefore, activity effectiveness, as depicted in Figure 3, can be expressed as:

Where:n(Ak) : Effectiveness (n) of Activity (At)rc : Relationship (Comparative)O : Output (Knowledge)G : Goal (Knowledge)

This formalism assumes that the output knowledge (O) and goal knowledge (G) may bedescribed in a manner which allows a direct comparison between them, and a relationship tobe determined which indicates how closely they match.

Figure 3. Effectiveness (n)

In design, multiple goals are likely to exist with different priorities. Therefore the activityeffectiveness with respect to a single goal will often represent only a partial view ofeffectiveness measured using a particular metric. That is, effectiveness may be described inrelation 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 thedesign proposal some value of overall effectiveness must be established. There are a varietyof techniques that may be adopted to support optimisation although the nature of the designactivity 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 thesimpler approaches to this type of problem. For example if we consider the priority (orweight) of the life in service goal (G1) to be W1 with respect to that of the dimensionalaccuracy 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. Theefficiency is inherent in the behaviour of a particular activity/resource combination. It may bemeasured without any knowledge of the activity goals, although the goals may influence thebehaviour of resources used in the activity and consequently the level of efficiency that resultsfrom their use.

Effectiveness, in contrast, cannot be measured without specific knowledge of the activitygoals. As is the case in measuring efficiency, the measurement of effectiveness involves theanalysis of the activity output (O). However, effectiveness is obtained through analysing aspecific 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. Thisrelationship exists when the specific element of the output knowledge, which is evaluated toestablish effectiveness, also describes an element of the resource used. For example, anactivity 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 costknowledge (Oc). However, determining the cost based efficiency of the activity also involvesthe analysis of cost incurred (Ru-c) in carrying out the activity as part of the overall resourcesused (Ru). In this particular instance the element of output knowledge used to establisheffectiveness is the same as that used to establish efficiency. Therefore, an increase in the costbased efficiency of the activity will also result in an increase in the cost based effectiveness ofthe activity, given an activity goal of minimising cost. In cases such as this one the efficiencyof the activity can provide insight into why a particular level of effectiveness has beenobtained.

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. Suchcases exist where the specific element of the output knowledge that is evaluated to establisheffectiveness has no relationship to the resource knowledge used in an activity. For examplewhere the goal of a design activity may be to maximise the dimensional accuracy of theartefact, G(S) = Max(s), the element of the output knowledge (O) which must be evaluated isthe knowledge of the dimensional accuracy (O(s)). It is clear that this knowledge provides noindication of the resource knowledge (R) used in the activity. Therefore an increase indimensional accuracy will give increased effectiveness with respect to this goal but there is nodirect relationship with efficiency in this case.

4 Evaluation

The research presented in this paper has been evaluated as part of an overall PhD project andis detailed in [12]. A number of approaches have been taken in evaluating the work:

The development of a worked example using information from previously reportedprotocol studies to illustrate the application of the E2 formalism within a practicalscenario.

A large number of metrics existing within the literature have been reviewed and analysedin relation to the formalism to determine if the key principles were violated.

Experts in design, performance measurement and management, and risk management fromindustry and academia have critically appraised the E2 formalism.

The evaluation results illustrated that the E2 model could be used to describe performanceusing protocol data and measures of efficiency and effectiveness were defined using theformalism. The metrics reviewed from the literature could be distinguished within the area ofefficiency or effectiveness and further insight into these metrics was gained, e.g. those metricsmeasuring influences on performance were distinguished from those measuring performanceitself. The critical appraisal provided support for the comprehensiveness of the formalism andthe key principles were seen to reflect and clarify industrial practice.

5 Discussion and Conclusion

The treatment of design performance within existing research lacks clarity on the nature ofperformance itself as a basic foundation for work in this area. The E2 model clearlydistinguishes and relates the key elements of performance, efficiency (n) and effectiveness(n). Further, influences on performance may be clearly distinguished, e.g. flexibility may beviewed as the ability of a designer to adapt to changing goals. This influences theperformance of the activity but is not in itself a measure of performance. The boundary of thismodel may be defined at the level of a specific activity or at other levels within designdevelopment such as project or program with the key principles remaining valid. The modelhas 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 activitiesinvolved 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, PresentFindings, and Future Directions. Academy of Management Review, 1995. 20(2): p.343-378.

[2] Neely, A., The performance measurement revolution: why now and what next?International Journal of Operations and Production Management, 1999. 19(2): p. 205-228.

[3] 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.

[4] Brookes, N.J. and C.J. Backhouse, Measuring the performance of product introduction.Journal of Engineering Manufacture, 1998. 212(1): p. 1-11.

[5] Chang, Z.Y. and K.C. Yong, Dimensions and indices for performance evaluation of aproduct development project. International Journal of Technology Management, 1991.6(1/2): p. 155-167.

[6] McGrath, M.E., The R&D Effectiveness Index: Metric for Product DevelopmentPerformance. Journal of Product Innovation Management. 1994. 11: p. 201-212.

[7] Johnson, H.T. and R.S. Kaplan, Relevance Lost - the Rise and Fall of ManagementAccounting. 1987, Boston, MA: Harvard Business School Press.

[8] Neely, A., M. Gregory, and K. Platts, Performance measurement system design: Aliterature review and research agenda. International Journal of Production andOperations Management, 1995.15(4): p. 80-116.

[9] Meyer, M.W. and V. Gupta, The Performance Paradox. Research in OrganisationalBehaviour, 1994. 16: p. 309-369.

[10] Cusumano, M.A. and K. Nobeoka, Strategy, Structure, and Performance in ProductDevelopment: Observations from the Auto Industry, in Managing Product Development,T. Nishiguchi, Editor. 1996, Oxford University Press, Inc. p. 75-120.

[11] Balachandran, M., Knowledge Based Optimum Design, ed. C.A. Brebbia and J.J.Connor. 1993: Computational Mechanics Publications.

[12] O'Donnell, F.J., A Methodology for Performance Modelling and Analysis in DesignDevelopment, in Design Manufacture and Engineering Management. 2000, Universityof Strathclyde: Glasgow.

[13] O'Donnell, F.J. and A.H.B. Duffy. Design Activity Modelling: A PerformanceViewpoint, in International Conference on Engineering Design (ICED 01). 2001.Glasgow.

Frank J O' DonnellE-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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

A METRICS METHODOLOGY DEVELOPED IN CO-OPERATION WITHINDUSTRY

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 routinelyused in physical product generation industries. Process information is often viewed aspaperwork burden, without inherent value-added. However, research papers on productdevelopment have proposed that the product development process (PDP) used by a companyhas direct impact on the resulting quality of the finished product [1]. In order to realizeimprovements to the process, the company must be able to compare their original PDP withthe proposed changes. Therefore, a method to measure the PDP is needed. Measuring theprocess is not a trivial task [2], since the tools required to measure the process in variousindustries need to be customizable, scalable, and usable in real-time, during execution of thePDP.

The goal of the research presented in this paper is to develop a general, cross-industrymethodology for developing process performance metrics for the purpose of assessing acompany's PDP. The aim of metrics is to monitor measurements that directly affect the PDPin terms of process cost, process time, and information quality. With metrics, engineeringmanagement is able to make better decisions to keep the PDP on track.

The target audience for the methodology described includes any product generation companyconcerned with improving its mechanical design process. Efforts were taken to make themethodology 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 threeindustry partners over a period of nine to twelve months:

Company X is a small, for-profit, off-road equipment manufacturer with in-housemechanical design and manufacturing capabilities, producing approximately 20 units permonth.

Company Y is a global, for-profit electronic product generation firm with contract productdevelopment and manufacturing, with production volume of 100,000 units per month.

Company Z is a product generation organization within a non-profit government researchbody, with in-house design and manufacturing, which produces one-off researchinstrument systems on an annual schedule.

A paper further detailing the application of this methodology at the partner companies isavailable [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 processis a quantified attribute of a process entity that characterizes the attribute. A measure has noinherent 'good' or 'poor' value. A metric for a process is a performance indicator relating ameasure to a target value; a metric evaluates the process entity in that it indicates deviation ofthe process entity from its target value. An example of a measure is 'time to generatedrawing', 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 subprocessattributes 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 aspracticed in the most recently completed program. Existing product development processdocuments, if available, were collected at the companies. Where no documentation existed,product development practices were first written down and organized. Finally, interviewswith practicing engineers were conducted to capture a complete picture of the PDP aspracticed. The PDP date was then formatted into a flow diagram arrangement, showingprocess steps with inputs and outputs [4]. The flow diagram provides a graphicalrepresentation of the relationships among the steps of the design process. While predominantsteps 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 ofthe design process.

2.2 Step two: construct the process measurement matrix (PMM)

The process measurement matrix (PMM) [5] is a PDP management tool, which relatesprocess management to specific steps of the product development process. The PMM alsoprovides relative weightings of how resources are utilized during a PDP. The PMMresembles a quality function deployment (QFD) House of Quality in structure [6]. Itorganizes process numerical measurements instead of the QFD product numericalengineering requirements. Constructing the PMM begins with modeling the resources andrequirements as inputs, and the deliverables as outputs. These inputs and outputs serve as theframework for the PMM. A simplified PMM is shown in Figure 1, with matrix entrieslabeled 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 thePMM is constructed. Example: 'mechanical design creation process'.

Field B: Names of internal subprocesses of the target process. The names of all thesubprocesses 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 mostconstrained 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: 6weeks'.

Field E: Requirements, resources, and deliverables names. The names of all the inputsand outputs for the target process are listed in rows. Example: 'draftsman: 20 man-weeks'.

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: 'assemblydrawing creation: 4 weeks'.

Field H: Indication of degree of dependency among internal subprocesses of the targetprocess. Example: 'dependency between assembly drawing creation and productionoperator training: high'.

ICED 01 -C586/468 547

Field I: Indication of degree of dependency among requirements, resources, anddeliverables of the target process. Example: dependency between draftsman man-hoursand production operator man-hours: medium'.

A key decision required prior to PMM construction is selection of the level or granularity forthe PMM. The highest level PMM is constructed for the whole PDP, with the entire productgeneration enterprise as resource, product financial objectives as requirements, and sale of thefinished product as the deliverable. Numerous internal subprocesses are required toaccomplish 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 inturn consists of smaller internal subprocesses with finer granularity inputs and outputs.

The PMM, created in Step Two allows visualization of relations among subprocesses andtheir inputs and outputs. By filling in entries along a row, the matrix format clearly revealsthe significance of an input (a requirement, a resource, or a deliverable) to each of the internalsubprocesses. Likewise, by filling in entries down a column, the matrix format highlightsessential inputs to a subprocess. Since the entries are numerical measures, the PMM drivesthe conversion of qualitative attributes into numerical quantities, allowing visibility of controlat the engineering level.

Another contribution of the PMM is that it makes visible non-obvious relationships amongPDP portions, especially chronologically separated subprocess steps. Interviews withengineers during Step One revealed dependencies between subprocesses and between PDPinputs that are entered in Field H and Field I. Recognition of these dependencies assists thenext 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, criticalcomponents of the process now need to be highlighted. Various methods can be used toidentify critical process portions. The interviews with engineers revealed areas of processconstraints at each of the companies. The Theory of Constraints (TOC) [7] was used toaugment the PDP flow diagram to identify constraints in the system. Targeting theconstraining 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. Thesubprocesses in Field B of the PMM are ranked from most critical to least critical using ageneral ranking process (such as [8]). Alternatively, this ranking is accomplished throughprioritization methods unique to each company's business (see [10] for an example). Thenumerical rank for each subprocess is entered in Field C of the PMM, and gives readyvisibility to constrained portions of the PDP.

The subprocess that most constrains the target process is the best candidate for assessmentusing metrics. This highest-ranking subprocess is called the critical subprocess, and is usedfor metrics creation in the next step of the methodology. The PMM facilitates visualizationand 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 movemeasured values closer to benchmark values. PDP metrics measure attributes specific todesign process steps and compare them to benchmark information about the steps. A metricis the numerical relationship of the measure of the consumption of resources and thecompletion of deliverables versus the benchmark usage developed from the PMM. In thismethodology, 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 ingenerating 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 attributeswere specified in the row entries of the PMM. Note that during actual execution of theoverall PDP, these target values may need to be adjusted before execution of the targetprocess portion begins. Given these target values, the PDP team members responsible for thisPMM 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, ametric for the critical subprocess is constructed.

Task 3: Find the relationships among measures for monitoring through metrics. Developformulae that capture the deviation or delta between target value and actual value for thenumerical attributes of requirements, resources, and deliverables. The target value, is obtainedfrom the PMM, while the actual value will be captured when the subprocess is actuallyexecuted during the PDP.

Task 4: Create a metric by combining these delta values in formulae that show how thesubprocess is actually consuming inputs and delivering outputs, compared to target values forinputs and outputs. Once this methodology is applied repeatedly at the same company,requirements, resources, and deliverables from previous programs become known, andallocations that resulted in successful program execution serve as benchmarks for futureprogram 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 forwhich a metric is desirable. A significant critical subprocess with multiple deliverablesrequires additional metrics for complete monitoring.

Task 6: Repeat Tasks 1 through 5 for the second most critical subprocess, as identified bythe PMM for the target process. Repeat for subprocesses further down in importance until athorough but manageable list of metrics is generated.

With these six tasks under Step Four of the methodology, the company is guided to constructthe most critical metrics that indicate success of the PDP. By developing these metrics beforestarting a product generation project, engineering management becomes focused onmeasuring subprocesses attributes that have the most influence on successful outcome.

The Tasks 1 through 6 described above outline the most thorough and rigorous application ofthis process metrics methodology. An advantage of this methodology is its scalability,depending on the organizational and operational characteristics of the enterprise. As noted inthe 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 threecompanies 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 andconducted the four step metrics methodology. Details of implementation of the methodologyat companies X, Y, and Z, and descriptions of the actual metrics developed can be found inreferences [9], [10], and [11] respectively.

In addition to process metrics generation, the case studies show a cross-industry benefit fromapplication of this metrics methodology: the rigor required in documenting the PDP inpreparation 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 eachPDP stage were created. In Company Y, dependencies among subprocesses were discoveredthrough process defect tracking, which is a new method of analyzing the process flowdiagram. In Company Z, minimum PDP requirements were documented for creatingmeaningful process metrics at companies that employ an informal process. In all threeinstances, the industry partners gained tangible process tools and techniques usable byengineers and managers, independent of PMM and metrics construction. Highlights ofprocess 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 timeand funds spent in executing the critical subprocesses had the greatest impact onsuccessful fulfillment of top-level requirements. Due to the fairly small company size,management and the researcher agreed that long-term payoff from application of thismetrics methodology will result from focusing only on these critical subprocesses.

Company Y: The results from PDP analysis revealed weak engineering input during earlyprogram phases. This lack of engineering input resulted in most process defects beinggenerated in these early phases. Frequently, in past product generation programs, thesedefects would manifest symptoms much later in the PDP in the form of schedule slipsfrom unplanned tooling modifications, product material cost increases, increased fieldservice costs, and reduced customer utility derived from the released product. The processflow diagram and PMM derived metrics generated through application of themethodology presented in this paper forced engineering based scrutiny of tasks anddeliverables within these early program phases. The Company gained the insight requiredto 'pay early' by allowing engineers to take the time and resources to improve the qualityof early PDP deliverables. This initial consumption of resources reduces the risk ofhaving to 'pay later' in schedule delays, cost increases, and product quality reduction.The metrics quantified and helped company management visualize the tradeoffs requiredfor overall process improvement

Company Z: The metrics for time and cost revealed how the resources were being affectedby time constraints. The metrics for deliverables showed the degree of completion alongeach step of the design process. By comparing the resource usage against the completionof each project step, decisions were made to ensure project progress. By comparing theresources 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 resourcebalancing.

4 Conclusion

The metrics methodology created by the authors and generated the following benefits at theindustry partners:

Rigorous documentation of the product development process.

Creation and utilization of the Process Measurement Matrix to organize and prioritizetarget process requirements, resources, and deliverables.

Identification of constraints in the PDP that lead to deficiencies during execution. Theconstrained portions are critical subprocesses.

Creation of measures and metrics for the most critical subprocesses.

Verification of usefulness of the metrics methodology through application to currentproduct generation programs.

The methodology developed here was shown to work in three companies with diversity inindustry, size, and PDP maturity. The methodology is scalable to adjust to specific needs ofindividual 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 Schoolof Management, 1996.

[2] Smith, D., The Measurement Nightmare. The St. Lucie Press, 2000.

[3] Lindley, M.W., Muranami, M., & Ullman, D. G., "A Metrics Methodology Developedin Cooperation with Industry: Method and Case Study", submitted to Research inEngineering Design. 2001.

[4] Ullman, D.G., The Mechanical Design Process. 2nd ed., McGraw-Hill, 1997.

[5] Wright, A. L., "A Theory of Product Design Process Management", Ph.D. dissertation,Department of Mechanical Engineering, Oregon State University, 1999.

[6] Clausing, D., Total Quality Development: A Step-By-Step Guide to World-ClassConcurrent Engineering. ASME Press, 1994.

[7] Dettmer, H. W., Breaking the Constraints to World-Class Performance. ASQ QualityPress, 1998.

[8] Saaty, T. L., Decision Making for Leaders. Wadsworth, Inc., 1982.

ICED 01 - C586/468 551

[9] Schlegel, S., "A Product Development Methodology Based on Concurrent EngineeringTheory for Use in Small Manufacturing Companies", thesis, Department of MechanicalEngineering. Oregon State University, 2000.

[10] Muranami, M., "A Metrics Methodology developed for High Volume ProductGeneration Organizations", project, Department of Mechanical Engineering, OregonState University, 2001.

[11] Lindley, M.W., "A Metrics Methodology developed for Non-Profit ResearchOrganizations", project, Department of Mechanical Engineering, Oregon StateUniversity, 2001.

Prof. David G. UllmanDepartment 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 DESIGNICED 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. Evalu-ating Engineering Processes

1 Introduction

Processes form the kernel of engineering (i.e. marketing, development, design, and productionplanning [1]). Process models can be used to improve engineering processes. A holistic engi-neering 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 theirapplication, appropriate manual and/or computer-aided tools are required. Although most in-vestments are made into these methods and tools including their handling, the resulting bene-fits occur mostly on the procedure and process level. In this paper a knowledge-based engi-neering process model (KBEPM) will be described.

2 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 donot limit the set of activities. A subprocess is a subset of a process and is also a set of activi-ties or other subprocesses.

A process element describes an activity respectively of one or several working steps. It isstarted 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 applica-tion 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 betweenthe process elements.

A procedure is a certain sequence of activities (working steps) respectively processes whichleads to the fulfilment of one or several aims of a process by the application of methodsand/or tools.

ICED 01 - C586/663 553

A method is an organised collection of rules, which allows a methodical fulfilment of one orseveral 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. : Relat ions between process, subprocess, and process element

3 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 toknow well, to monitor, and to control all processes and activities. Process models can be ap-plied for formalisation, structuring, and description of any processes and objects treated inthese 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 (alltogether with the appropriate knowledge) in form of a computer-based navigation tool. Thistool assures that a user doesn't "forget" any of the necessary activities in the development of aproduct.

The KBEPM is based on process elements. Process elements offer the possibility to defineprocesses in a formalised way. They can adapt very flexibly to different requirements. Due totheir coherent description they can also be represented graphically. One of the advantages ofusing process elements for the description of the design process in the KBEPM is the possi-bility 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 topass through the phases of product development using a lot of different activities. For thedefinition of the general process elements of the KBEPM various models and procedures fromthe following authors were analysed and compared:

The work of Pahl and Beitz [3] was used because their design process procedures are wellknown and because these procedures are taught in the majority of universities in Germany-offering 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 thedesign 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 technicalsystems, e.g. machines and installations.

Dietrych and Rugenstein [7] take into consideration early in the process the aspect of pro-duction preparation.

Eversheim [8] describes the activities of production preparation in much detail but withouta link to the previous design process.

Blessing [9] defines matrices that describe activities with an assignment to product com-ponents. 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 allactivities from the first idea or the identification of needs (either of a customer or of the mar-ket) until the release to manufacturing. To get these general process elements, the content ofevery 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 newtechnology like rapid prototyping in the early phases of the design process.

Process elements were cleared, if in another process element the same activity was already-treated or the same information was created.

Extensive process elements were divided up if too many different working steps were in-cluded in one activity.

Similar working steps were combined to one process element, if they created either equaloutput information and/or documents of the appropriate activities.

To support the design process by the intensified use of methods and tools, more than 100 pos-sible or necessary methods and tools applied in the design process were registered and for-malised. Subsequently, a method base was set up in which every process element is associatedto its potential/ possible methods, tools, and applications [1], By this way the KBEPM pro-vides the user only those methods and tools which are the most appropriate to support the ac-tivity of a specific process element. The method base also is open for adding and modifyinggeneral 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 proc-ess elements and the special use of methods and tools the process model can be adapted easilyto a lot of different requirements of company specific product development processes.

The KBEPM is being implemented using standard software tools. This makes it possible toimprove existing engineering processes, to navigate users along the product developmentprocess, 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), tomonitor processes and their improvement, and to capture the design intent.

4 Predicting and Measuring Costs and Benefits

Additionally, an evaluating tool based on [10] was included for predicting and measuringcosts and benefits of process improvements. In a first step, this evaluating tool is intended tomeasure benefits of processes and tools (e.g. CAD, EDM), in a second step benefits of meth-ods will be included.

In business theory there are no suitable benefit evaluation procedures. Another problem is themissing process orientation as well as an inadmissible mix of quantifiable and qualitativebenefits (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 ofthe (optimised) processes can be measured rather easily using process throughput time, proc-ess 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 neces-sary. There are two ways: the classical approach of costs, quality and time, and a Controllingapproach.

The drive to record benefits of tools is the classical requirements like less costs, quality im-provement and reduced throughput time. However, these requirements have different mean-ings in context with processes, procedures, methods, and tools in product development, aswell in co-operation with the customers. There are overlappings because e.g. time reductioncan be transferred to cost reduction. Several interpretations are possible because e.g. qualitycan be product quality, service quality, or staff quality (to be achieved by qualification). Alsoit has to be regarded that companies are structured in projects for the implementations of tem-porary plans. Hence, six benefit categories were defined in [10]: staff environment, tool appli-cation, product quality, service quality, process performance, and project performance. Exem-plary benefits were related equally to the single benefit categories.

In the single benefit categories for benefit evaluation, the benefits that can be quantified com-pletely by monetary means and benefits (where the quantification is possible but with diffi-culties). These benefits are classified in so-called benefit classes based on the VDI guideline2216 [12]. The benefit class "synergy effects" extended the benefit classes, which coverscompany internal and external synergies. These five benefit classes can be arranged as a port-folio. This portfolio is called the Benefit Asset Pricing Model (BAPM) portfolio. It is shownin [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 thebenefit evaluation. The result of these similarities is shown in figure 2.

Figure 2. : S imi lar i t ies of benefit classes and capital market investments

An additional way to get the benefit categories was based on the resulting difficulties that ap-peared not only during benefit recording and evaluation but also mostly in classical Control-ling [10]. Therefore, new controlling methods had to be found. One of these was the BalancedScorecard [14], which was created originally for manufacturing. The Balanced Scorecard isable to give a financial value to product development, processes in the company, staff knowhow, 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 theunique new controlling instrument that focusses on customers, staff, and processes. All otherinstruments 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 bene-fit categories (figure 3) which can be derived by the interpretation of the original four Bal-anced 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 categoriescosts, quality and time as well as the classical Balanced Scorecard approach, are shown infigure 3. The benefits in the different benefit categories of both approaches can be related tobenefit classes.

In KBEPM the tools which were applied during processes and activities and further informa-tion of costs and throughput time are available. In order to apply the BAPM in context withKBEPM the following procedure is recommended (figure 4):

The information of applied methods and tools, the used time and costs altogether aretransferred into the BAPM module. In BAPM benefits are classified in benefit categoriesand in benefit classes. To get the individual yield of each benefit class, each benefit ineach class has to be evaluated. The application of the portfolio theory of Markowitz re-sults 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 ofthe whole benefit portfolio.

The output of the benefit evaluation is placed in an Internet Browser window (detailsshown 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

5 Conclusion

Based both on the research work on engineering process improvement by using general proc-ess elements in a holistic engineering process model and on the evaluation of these improve-ments, this contribution should motivate the discussion with other groups dealing with similarapproaches. The next step is the application of these research results in industry to get moreexperiences.

References

[1] Vajna. S., Freisleben. D., Scheibler, M, "Knowledge Based Engineering ProcessModel". Proc. ICED '97. Tampere. 1997, pp. 181-184

[2] VDl-Guideline 2219, "Datenverarbeitung in der Konstruktion, Einfuhrung undWirtschaftlichkeit von EDM/PDM-Systemen", VDI-Gesellschaft Entwicklung Kon-struktion Vertrieb, Dusseldorf l999

[3] Pahl, G.; Beitz, W.: Konstruktionslehre: Methoden und Anwendung, Springer-Verlag,Berlin Heidelberg New York London Paris Tokyo Hong Kong Barcelona Budapest1997

ICED 01 - C586/663 559

[4] VDI: VDl-Richt l inie 2221 Methodik zum Entwickeln und Konstruieren technischerSysteme und Produkte. VDI-Gesellschaft Entwicklung Konstruktion Vertrieb,Dusseldorf 1993

[5] Hansen, F.: Konstruktionswissenschaft: Grundlagen und Methoden, VEB Verlag derTechnik, Berlin 1974

[6] Hubka. V.: Allgemeines Vorgehensmodell des Konstruierens, Fachpresse Goldach.Zurich 1980

[7] Dietrych. J.; Rugenstein, J.: Einfuhrung in die Konstruktionswissenschaft, TechnischeHochschulc Otto von Gucricke Magdeburg, Politechnika Slaska im. W. PstrowskiegoGliwice 1982

[8] Eversheim, W.: Organisation in der Produktionstechnik, VDI-Verlag, Dusseldorf 1989

[9] Blessing. L. T. M.: A Process-Based Approach to Computer-Supported EngineeringDesign, Black Bear Press Ltd, Cambridge 1994

[10] Schabacker, M.: "Benefit Asset Pricing Model - Ein Modell zur Nutzenbewertungneuer Technologien in der Produktentwicklung'", am 22.02.2001 verteidigte Dissertationan 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, Eu-ropaischer Verlag der Wissenschaften. Frankfurt am Main, 1995

[12] VDI-Guideline 2216. "Datenverarbeitung in der Konstruktion: Einfuhrungsstrategienund Wirtschaftlichkeit von CAD-Systemen", VDI-Gesellschaft Entwicklung Konstruk-tion 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. VajnaOtto-von-Guericke-University of Magdeburg, Computer Applications in Mechanical Engi-neering, 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. SchabackerEPI-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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

PROCESS PERFORMANCE MEASUREMENT SUPPORT - A CRITICALANALYSIS

M K D Haffey and A H B Duffy

Keywords: Design Management, Performance Management, Performance Metrics.

1 Introduction

Design development processes, within engineering disciplines, lack the necessarymechanisms to identify the specific areas where improved design development performancemay be obtained. In addition, they lack the means to consider and align the goals andrespective performance levels of related development activities within the consideration of anorganisation's overall goals and its required performance dimensions and levels. Currentresearch in organisational performance behaviour, formalised through performanceframeworks and methodologies, has attempted to identify and focus upon those critical factorswhich impinge upon a wealth creation system while attempting to, simultaneously, remainrepresentative of organisational functions, processes, people, decisions and goals. Effectiveprocess improvements remain conditional upon: the ability to identify potential areas forimprovement and to define the goals and subsequent measures which will support therealisation of such goals; the ability to measure the potential performance gains which mayresult from an improvement initiative; and, the ability to understand existing processdynamics and the subsequent impact of some change to a system/process. The objective ofthis paper is to discuss some of the management techniques, which are purported to supportvarious process performance issues and perspectives, and identify the major factors thatremain unsupported in identifying, measuring and understanding design process performance.

2 Process Performance

Engineering design development processes involve designers developing product designs thatpossess the potential to meet the requirements of both prospective customers, and the specificstandards delineated through internal and external influences. In addition, designers must beguided and controlled by the needs and strategic intentions of an organisation placed in a localcontext through the directives and focus of middle management. Design developmentprocesses are responsible for producing an output or product design that has the potential tobe delivered to the customer in the form of a product, through subsequent development stagesby considering various internal and external perspectives and requirements. For example, thedesign development process, considering both the design activity and its management, mustrealise the potential to deliver a product to the market place: at an efficient cost when placedin the context of market price; at an optimum point of market entry to satisfy customersdelivery requirements and ahead of market competition; at a level of quality that the customeris at least expectant of while superior to market competitors in the aspects that a market willbase 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 designdevelopment managers must acquire, modify and/or generate the information that enablesthem to manage design processes/activities and design products that: firstly, align with, andsatisfy, the required dimensions of organisational performance and that are congruent with thegoals and objectives of the associated product development process functions such asmanufacturing; and secondly, that will perform in the market place from such dimensions asreturn on investment. Design development activities are therefore forced to consider not onlytheir own output or deliverable, from within the alignment of both internal organisationalperspectives - from strategic level objectives (macro) to general design development goals(micro) - and the objectives and standards associated with the external organisationalenvironment, but must, in addition, produce a design deliverable that will remain congruentwith the objectives and goals of subsequent, and indeed previous, development activities.

The statement that an organisation's core competencies are the building blocks of competitiveadvantage [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 andweaknesses of lower level functions and processes [3]. Thus, the formulation of a strategynecessitates the need to understand the many relationships and interactions that may existinternally and externally to an organisation's environment i.e. identifying where majorstrengths and weaknesses, and opportunities/threats, are likely to arise.

From the discussion certain factors need to be addressed in order to support an organisation indetermining the areas that it or its processes should be utilising or improving upon (bottomup) and in measuring the levels of performance required to develop and deploy organisationalstrategies (top down). The following points explicate the fundamental components that wouldsupport organisations in formulating strategies, based on performance levels obtained at adesign development process level, and in guiding development activities by placing processspecific goals in the context of realising high-level organisational strategies. Thus, the aspectspresented refer to the means of getting high-level concerns and objectives down to a processlevel, 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 productrequirements in terms of functional and behavioural considerations but lack support in placingthese specific requirements or goals in context with organisational strategies and goals. Froman improvement point of view the development and definition of goals infers that gaps or sub-optimal results have been identified. Thus, measurements relating to a process's level ofperformance are required to support in identifying what must be protected or improved uponto satisfy organisational objectives and customer expectations and requirements. High-levelstrategic goals or objectives need to be decomposed into process specific objectives,providing the ability to relate and align process specific performance measures with the needsand strategic direction or focus of the organisation, and in turn providing the ability to linkcompany objectives to daily activities and decision making activities [4]. The followingpoints outline why the setting of realistic and informed strategic objectives is required tosucceed in satisfying those objectives, and to an organisation's overall level of performance.

Alignment: Consideration must be given to how high-level organisational objectives willbe viewed at the process level and how they will effect (i.e. contribute or constrain) uponthe specific goals and objectives of development functions and visa versa [5].

Congruency. Objectives bring a focus to activities and processes and the sub-optimisationof activities, processes and products may occur as a result of project teams optimisingsolutions 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 goalsfor one design development activity should be placed in a wider organisational context toassess its contribution or constraint on other functions achieving their goals.

Constraints and Contributors to Success: The provision of objectives and thedetermination of how they may be realised aids in highlighting and distinguishingbetween obstacles that may restrain, or opportunities that may promote, the level ofperformance obtainable from within the focus of an objective [7] and provide the means tocontrol the number of measures being required. It therefore remains pertinent to thesuccess of outlining and satisfying goals that distinctions are made between constraintsand 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 oftheir satisfaction but such ambitious 'stretched' objectives force personnel to think andanalyse the sequence and structure of the process and the way work is carried out. Thesetting 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 toimprove upon (developing a 'to be' understanding). Consideration should be given,therefore, to ensure that goals outlined are ambitious but that remain within the realms offeasible in terms of process, technology and personnel capabilities.

Composition of Metrics: In order to support the realisation of organisational goals, at variouslevels and considering the alignment, congruency, constraints and contributors of success, theidentification and determination of the measures (metrics) that will help in checking theprogress being made toward such goals and in determining whether such goals support higherorganisational goals must be supported to determine how close you are to a target and howquickly you are moving toward a target [5]. The aim of controlling and defining the measuresused at a process level, and maintaining the existence of a cascading effect is to promote acommon 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 bebeneficial to the function but not to the overall process performance level [8]. Currentresearch within the area advocates the need to balance the mix of measures between high-level organisational dimensions while the identification, and application of appropriatemetrics within such balanced dimensions remains to be conducted erratically and intuitively.

Overall and Sub-level Index: Providing management and process level personnel with aninter-related and flexible method to specialise and generalise measures throughout anorganisation, while maintaining the congruency and alignment of measures, provides theability to obtain an overall sense of improvement or detriment at various organisational levelsand the means to specialise their focus to identify (sub) optimal performance. The ability togeneralise 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 theperformance of distinct departments, functions etc.; and, allows management to generaliseand specialise their focus or concerns providing the means to control the range of measures inreflecting and supporting organisational strategic viewpoints.

Relational structures: The preceding points have all discussed the need to enable therelations between goals, metrics, organisational functions to be identified, quantified andstructured. There is thus a need to: firstly, understand how the satisfaction of one goal willimpinge 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 performancemeasurements to reflect the structure of an organisation and the hierarchy of goals within. Inaddition, any person involved in an organisation has a perspective on the organisationalsystem and therefore their goals may be different, or refer to distinct but affected or affectinggoals. Thus, an organisational wide performance measurement system should relate betweenmeasures/metrics, goals/objectives and perspectives/viewpoints. While the identification ofthe relationships between related entities enables more informative decisions to be made, theneed to identify their effects, i.e. positive or negative, relative to the perspectives, and thedensity of interactions are also important in determining the stability of a process and howchanges made to improve performance will be received by other organisational functions [9].

The existence today of a plethora of various performance measurement systems has indeedpushed our understanding of the constituent factors of organisational performance and givenpractitioners a multitude of issues and dimensions of performance to consider. However, at afundamental level of performance, in determining organisational down to process levels ofperformance, we need to understand how do such performance measurement approaches,frameworks, formalisms and methodologies perform.

3 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 strategicdirections taken by organisations but in addition provides the means to identify theimprovement requirements and the drive behind improvement initiatives [10]. Based on therequirements raised in the preceding section a sample of performance measurement systemshave been reviewed (as summarised in Table 1) to determine the depth of support that isprovided 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

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

BalancedScorecard

BEM(EFQM)

CambridgeModel

IntegratedP.M.

PerformancePyramid

Intuitive

Intuitive

Intuitive

Intuitive

Intuitive

-

Intuitive

Intuitive Intuitive

High level

Intuitive

Intuitive

Intuitive

Intuitive

Intuitive

-

-

Related High level

R e q u i r e m e n t s & E v a l u a t i o n C r i t e r i a

purported to provide both a balanced representation of, and the perspectives upon which toanalyse, an organisation. Within each perspective a list of objectives, and in turn metrics, aredefined and clustered allowing an organisation to develop its own specific "BalancedScorecard". The framework advocates a balance between financial and non-financialmeasures and it is purported that the analysis of the measures used wi l l detail the strategybeing deployed within an organisation. However, these measures and objectives are derivedintuitively, and at user's discretion, and at such specific and complex levels of considerationconcern as to the most appropriate mix or balance of measures being used to support strategicobjectives must be expressed. Thus, it lacks the necessary means to determine the right thingsare considered with the rationale associated with the measures used, such as time based, orrecognising when a measure becomes obsolete and is no longer required. Based on therequirements outlined previously in Section 2 the Balanced Scorecard provides no support indefining either organisation or process level goals and are therefore restrained in: maintainingthe alignment and congruency of measures; identifying constraints to or contributors ofsuccess; and, providing the basis upon which to learn, identify and utilise competencies. Thelack of support to identify applicable metrics in the context of organisational strategiesprovides no means of deriving process level sub indices from within its four perspectives.

The Business Excellence Model (BEM), developed by the European Foundation for QualityManagement (EFQM) provides practitioners with a framework that considers that theprocesses used to deliver people satisfaction, customer satisfaction and impact on society areattributable through leadership, controlling and defining organisational policies and strategies,managing people and allocating resources in order to produce excellence in its businessresults. 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 isreported to provide the generic criteria that are deemed to assess an organisation's progresstoward excellence. Again, the model provides a generic framework from which to intuitivelyderive the most appropriate goals and measures but lacks the depth to consider the alignmentand congruency of goals and metrics and the potential to gain insights and learn from theconstraints and contributors of success. The high level generic structure may provide overallindexes within results and enablers but relies on the intuitive extraction of measures to reflectoperations at a process level and therefore provides no support in identifying what enablersare 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 providethe 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 ofhigh level, strategy orientated, performance measures where organisational objectives andtheir associated or related measures are agreed upon, based on specific product strategies, andembedded into high level organisational decision making activities. Phase two aids incascading high-level objectives and measures down to the process level based upon the keyperformance indicators and drivers. The model supports users in navigating through theprocess of developing and relating goals and measures but again relies on the intuitiveextraction of goals and measures and the recognition of how they relate across and through anorganisational structure. The model does acknowledge the need to support in identifying theinteractions between measures, within isolated organisational levels, but relies upon arelational 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 andthe utility of performance measures as shown in Figure 4. The framework refers to integratedas strategic-driven performance management through the congruency of actions acrossfunctional boundaries while in the context of strategic objectives. Their work argues the needfor identifying process level goals and measures as derived from organisational strategieswhile they support the need to structure the goals and measures to align and be congruentwithin an organisational structure. However, the framework proposed falls short of supportingthe 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 thuslearn from the strengths and weaknesses of process capabilities yet the approach lacks theability to explicate such information.

The Performance Pyramid provides a means of deriving operational measures fromorganisational strategies. The approach outlines four levels within an organisation from thecorporate vision, business units and business operating systems down to departments andidentifies key, generic, dimensions within each level as outlined in Figure 5. The keyobjectives 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 beaggregated back up through an organisation to support the recognition of effort being focusedon working toward the satisfaction of objectives. While the approach identifies the keydimensions (high level and related low level), which should be addressed and measured at aprocess level, it provides little support on how to identify and integrate the relevant goals andmeasures. The approach does begin to address the need for the alignment of dimensiongoals/measures but lacks any depth in understanding their structure, interactions and causeand effect relationships and therefore restrains the potential opportunities to learn.

In summary, system approaches and discussions on performance measurement have allconcentrated 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 whilerelegating 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 concentrationor reduction in the degree of effort along the dimensions factored in strategic foci is notgenerated and in some cases equal weightings and considerations within relevant dimensionsis prescribed. The utility of performance measurement approaches have been focused upon, ata general level, one of determining the dimensions of performance that will support the focusof effort in realising strategic objectives and in determining organisational health. However,none support, explicitly or based on factual feedback, the mapping of organisational goalswhich is needed to analyse and control processes in the context of organisational and processlevel objectives and thus lack the opportunities to stimulate learning, improve communicationand affect behaviour. O'Donnell and Duffy provide a means to enable the alignment andcongruency of objectives and measures in addition to providing the basis upon which toexplore the relationships between the components of process performance [12, 13]. Throughthe ability to cascade process level performance measures throughout the corporation theexisting reliance upon identifying the measures that support the satisfaction of performancegoals through intuitive means may be overcome.

4 Conclusion

The ability of organisations to objectively set strategic goals, identifying the path along whichsuch 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 threatsand opportunities are likely to arise. The complex nature of a design process requiresconsideration of the performance required from subsequent process activities in addition to itsown and therefore requires prescriptive information on the levels of performance bothrequired and attainable. This indeed contributes to the complexity of the design process andemphasises the need to provide prescriptive decision-making information. In order to providesuch prescriptive information the need to support understanding and learning what hashappened, by understanding goal and metric structures and their interactions, and predictingwhat is about to happen must be recognised. However, based on an evaluation of existingperformance measurement approaches a substantial lack of support exists that bringsorganisational objectives down to a process level and that aids the identification of measuresto 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 ofcausality is severely restricted.

The authors are currently developing a methodology which will enable organisations to modeland understand process performance behaviour. The research will focus upon overcoming theinherent weaknesses identified in existing approaches by providing a methodology to identify,structure and manipulate the key performance dimensions through machine learningtechniques and performance modelling.

References

[1] Griffin, A. and Page, A. L., "PDMA Success Measurement Project: RecommendedMeasures for Product Development Success and Failure", Journal of Product InnovationManagement, Volume 13(6), 1996, 478-496.

[2] Shay, J.P. and Rothaermel, F.T., "Dynamic Competitive Strategy: Towards a Multi-perspective Conceptual Framework", Long Range Planning, Volume 32 (6), 1999.

[3] Prichard, R.D., "Measuring and Improving Organizational Productivity: a PracticalGuide, Praeger Publishers, New York, 1990.

[4] Loch, C., Stein, L. and Terwiesch, C., "Measuring Development Performance in theElectronics Industry", Journal of Product Innovation Management, Volume 13, 1996.

[5] Kerssens-van Drongelen, I.C. and Cook, A., "Design principles for the development ofmeasurement systems for research and development processes", R&D Management,Volume 27(4), 1997, 345-357.

[6] Englund, R.L. and Graham, R.J., "From Experience: Linking Projects to Strategy", J.Prod Innov Management, Volume 16, 1999, 52-64.

[7] King, B., "Hoshin Planning - The Developmental Approach" Goal/QPC, 1989.

[8] Hall, R.W., Johnson, H.T. and Turneym, P.B.B., "Measuring Up:Charting Pathways toManufacturing Excellence", Business One Irwin, Illinois, USA, 1991.

[9] 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.

[10] Suwignjo, P., Bititci, U.S., Carrie, A.S. and Turner, T.J., " Performance MeasurementSystem: Auditing and Prioritisation of Performance Measures", First Intl Conf onPerformance Measurement, University of Cambridge, 14-17 July 1998.

[11] Haffey, M.K.D., "Process Performance Measurement: Mapping the Requirements to theSupport", 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 DesignDevelopment", 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 DESIGNICED 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 multi-component systems and minimising risk from early in the conceptual phase, whereuncertainty is high. The process involves probabilistic reasoning in propagating bothqualitative and quantitative effects of changes, or uncertainty in component or sub-systemspecifications, through system models, and determining the integrity of the design frommultiple viewpoints. The methodology is very versatile and the software that has beendeveloped not only handles Design for System Integrity (DSI), but has also beendemonstrated for a number of other tasks, such as evaluating system reliability, investmentappraisal for engineering and other projects, and risk assessment in project management. Thesoftware has particular value in assisting the design manager to evaluate the robustness ofdesign alternatives at the conceptual stage when there is a high level of uncertainty. The useof 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 theengineering system and the creation of a number of sub-systems and components, betweenwhich there are defined interfaces and transfers of material, energy and information. As thedesign is refined, sub-system concepts, embodiments and details are altered to a more finalstate. At each level, the designer needs to understand how the relationships between sub-systems 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 productdevelopment in New Zealand [2] indicates that few engineering designers in industry followsystematic 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 productdevelopment team members working on different sub-systems. This results in recurringcycles 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 betweencustomer-focused design, manufacturing and marketing functions in the design process, andto illustrate the recursive process of exploring sub-system and component interrelationships.These relationships, which will be numerous in a multi-component system, are examinedfrom 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 softwareto operate as an aid to design managers in determining the integrity of a design from multipleviewpoints, 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 wholesystem, from the different viewpoints, and, importantly, at the early conceptual design stagewhen there is a high level of uncertainty.

Antonsson et al [for example, reference 7] have presented notable work on methods forincorporating imprecision in engineering design decision-making. Antonsson's Method ofImprecision allows for uncertainty at early design stages using fuzzy calculus but does notappear to propagate qualitative effects through the design model. Pons [1] has compared thefeatures 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 maybe uncertain [8]

measure and quantify lifetime performance of designs.

Knowledge-based software packages to assist the designer in exploring conceptualalternatives or in the analysis and optimisation of a given design are now common, forexample in software models of complete motor vehicles. However, such methods havegenerally only been successful in specific domains, as they require relatively completeproblem definition [9], which is often unavailable in early design where uncertainty is high. Inthis problem domain, artificial intelligence methods have generally only been successful inwell-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, andtheir strategy has been to use artificial intelligence to assist the human designer rather than tosolve design problems on its own.

An example of a more successful implementation has been the "Schemebuilder" model ofBracewell et al [12], which helps the designer assess a design scheme from a functionalviewpoint, principally by functional simulation. Rather than automating design using theexpert system approach, this system provides decision support and allows the human designerto apply judgement and quickly evaluate alternative design solutions.

570 ICED 01 - C586/024

3 Design for System Integrity Methodology

The DSI methodology and software belongs to the family of knowledge-based systems thathelp the designer assess a design scheme from a functional viewpoint. The DSI methodologypropagates (at concept, embodiment or detail design stage) both quantitative and qualitativeknowledge about design parameters through a tree structure not dissimilar to a fault tree ordecision tree. The process is outlined in the flow diagram of Figure 1.

Figure 1. Flow chart illustrating core process ofthe 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 moredetail. 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 designeridentifies key devices in the model. In the case of the dishwasher the DSI process system isdefined typically with physical devices, eg "wash pump", "sprayer", etc. Each of these isattributed properties that relate to one or more of the viewpoints from which system integrityis to be evaluated, such as "wash pump cost", "wash pump pressure". The designer thenestablishes the relationships between the devices. These relationships are different for each ofthe 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 ismodelled as 100% less the soil demerit points. The overall effectiveness of soil removal isrepresented by a substantial and complex DSI tree structure that has been fully described byPons [1]. Space here only allows for brief examples of quantitative and qualitative DSIprocesses.

Quantitative links give rise to numerical relationships, and are defined in terms of basicmathematical operators (addition, subtraction, multiplication, and division), or more complexmathematical functions (eg reliability functions such as the Weibull distribution) or even bylogical functions (maximum, minimum). The elemental process in the DSI methodologyinvolves taking two discretised input probability distributions, applying a quantitativeoperator (such as +, -, x, /, maximum, minimum) or qualitative map (using decision theory) todetermine an output distribution.

In the wash performance model one of the elemental quantitative combinations in the sub-system computation for soil particle demerits evaluates the water retained in the machine atthe end of the wash cycle as the sum of the water retained in the sump and the water retainedas a film on the wash cavity. The fragment of the DSI tree containing this operation is shownin Figure 2. The inputs in this case are represented respectively by normal and Weibullprobability distributions. The addition of the two discretised probability distributions,represented as histograms, is illustrated in Figure 3. The process can be computationallydemanding. In this example, if the two probability distributions were each approximated by100 discrete values, there will be 10,000 calculations to form the combined distribution, andthere may be many such combinations in the overall DSI analysis tree just for the wash

Figure 2. Fragment of DSI computationfor soil particle demerits within washperformance DSI tree

Figure 3. Sum of sump (normal) and cavity (Weibull) retainedwater probability distributions to give an output as the bold line.The horizontal axis is volume in litres and the vertical scaleprobability density.

performance. In the retained water computation each of the 10,000 additions has anassociated joint probability being the product of the probabilities of the component watervolumes. 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 retainedwater volume as an outcome.

Qualitative parameters are defined in textual terms. These could be pseudo-scalar values suchas a temperature scale ("hot, warm, cool, cold"), or more abstract terms such as the type ofsoil present on dishware (e.g."sauce, mashed potato, breakfast cereal") and soil thermaltreatment ("fresh, dried, reheated, baked, burned"), where no scale of precedence exists. Amapping process similar to that used in decision tables describes textual relationships andenables qualitative information to be propagated through the DSI tree. The expert defines thismap at initial configuration of the system.

For example, if wash performance (''bad, marginal, acceptable, good, excellent") of thedishwasher is dependent on soil thermal treatment and soil type, in a way which cannot bequantified, then the expert sets up a decision table which gives the resulting washperformance 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 givesthe probability of each of the outputs. A fragment of a wash performance map relationship isshown in Figure 4, in which the map takes soil thermal treatment and soil type, and combinesthem to produce the output. A soil thermal treatment model is shown in Figure 5. It rangesfrom fresh to burned soil and, in the example shown, all the soil is taken as dried, whichtherefore has a probability of 1. A soil type profile is shown in Figure 6, where theproportions have been determined from the relative masses of the soils.

Figure 4. Representation of a mapRelationship in the Design IntegritySoftware

Figure 5. The profile for soil thermal treatment.

Figure 6: Soil type shown as a histogram based on mass ofvarious 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 soiltype 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% assticky 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 whereany 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 bepropagated through the system to determine the resulting wash performance and otheroutputs. A more realistic assertion at early design stages might be to give a probabilitydistribution e.g. 30% hot, 50% warm, 20% cool, 0% cold, to encompass the uncertainty thatexists at this stage. That is, the designer is leaning towards using a hot-warm set point on thethermostat, 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 asprobability 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 endresult 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 thetree and the DSI software then computes an outcome probability distribution for theviewpoint concerned, e.g. overall wash performance, product cost or product reliability.Effects from various viewpoints may also be studied concurrently. For example, in evaluatingwash performance of the dishwasher, selection of a different circulation pump to reduce costmay alter water pressure and trigger responses from component properties relating to sealperformance, system energy consumption, and water flow rates.

The DSI software engine applies probabilistic computation in a combinatorial fashion andallows both numerical and textual relationships in the same model. This is a departure fromestablished techniques, where the effect of variability in multiple parameters affecting anoverall outcome, and the associated numerical relationships, have commonly been handledusing Monte Carlo methods [13]. The DSI numerical method avoids Monte Carlo simulationaltogether, although it has similar functionality and computational power. It also provides thefunctionality of decision theory. The ability of the DSI methodology to propagate the effectsof 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 systemtools where the software seeks to make a decision using artificial intelligence method, the DSImethod does not make decisions itself. The method is an analytical assessment tool thatsupports the human decision-making and design management process.

The DSI software was developed in the Delphi programming language and containsapproximately 40,000 lines of code. It is a comprehensive package that can handle bothquantitative and qualitative system integrity computation from multiple viewpoints.

4 Conclusions

Designers can have difficulty grasping the multiple relationships between systems, sub-systems and components. The Design for System Integrity (DSI) methodology has beendeveloped as a software tool to assist in faster evaluation of system integrity from multipleviewpoints. It therefore offers a rapid means of comparing design alternatives. Themethodology fuses quantitative and qualitative assessment, and incorporates probabilisticreasoning. The ability to propagate both qualitative and quantitative information, and processvariability, 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 conventionaldeterministic methods.

References

[1] Pons, D., "A methodology for system integrity in design", PhD thesis, University ofCanterbury, 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.

[3] Pugh, S., "Total Design. Integrated Methods for Successful Product Engineering".Addison Wesley, 1991.

[4] Pahl, G. and Beitz W., "Engineering Design". London: The Design Council, andBerlin/Heidelberg, Springer-Verlag, 1984.

[5] Whybrew K., Raine J.K. and Dallas T.P., "The Application of Design Phase Diagramsin the Management of Design of Telecommunications Products", Proc. 12th InternationalConference on Engineering Design. Munich 24-26 August 1999, 3, pp1519-1524.

[6] Raine, J.K., Pons, D., and Whybrew, K., "The design process and a methodology forsystem integrity", Short Communications in Manufacture and Design. Proc. IMechEPartB. 2001 (to appear)

[7] Antonsson, E.K. & Otto, K.N., "Imprecision in Engineering Design", Journal ofMechanical Design. Transactions of the ASME. 117B, 1995, pp25-32.

[8] Finger, S. and Dixon, J., "A review of research in mechanical engineering design". Part2: Representations, analysis and design for the life cycle, Research in EngineeringDesign. 1.1989. pp121-137.

[9] Candy, L., Edmonds, E. and Patrick, D., "Interactive knowledge support to conceptualdesign", 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.

[10] Tang M., "Development of an integrated AI system for conceptual design support", inSharpe. J (ed), "Artificial intelligence system support for conceptual design", Proc. 1995Lancaster International Workshop on Engineering Design. Springer, 1996, pp153-169.

[11] Bartsch-Sporl, B. and Bakhtari, S., "A support system for building design - experiencesand convictions from the FABEL project", in Sharpe J (ed), "Artificial intelligencesystem support for conceptual design", Proceedings of the 1995 Lancaster InternationalWorkshop 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 YanX.T., "Integrated platform for AI support of complex design (Part 2): Supporting theembodiment process", in Sharpe J. (ed), "Artificial intelligence system support forconceptual design", Proceedings of the 1995 Lancaster International Workshop onEngineering Design. Springer, 1996, ppl 89-207.

[13] Kleijnen, J.P.C., "Verification and validation of simulation models", European Journalof Operational Research. Elsevier Science B.V. 82(1), 1995, pp145-162.

Professor John K. RaineDepartment of Mechanical EngineeringUniversity of CanterburyPrivate Bag 4800ChristchurchNew ZealandTelephone: +64 3-364-2571 Fax: +64 3-364-2078E-mail: J.Raine@mech.canterbury.ac.nz

©IMechE 2001

576 ICED 01 -C586/024

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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

1 Introduction

Product redesign is common in many industry sectors, for example in automotive andaerospace, where 'new' products are derived from earlier designs as a means to maintainingproduct quality whilst reducing design and production lead time. However, the redesign ofsuch complex products is seldom straightforward and can be effected by the propagation ofchanges - a small initial change can instigate numerous other changes, possibly having seriouscost implications. Despite this risk, industry currently lacks a clear approach for predictingand representing change propagation [1] and is dependent on the past experience of productexperts to minimise its effect.

The aim of this research is to reduce unexpected change propagation in product design. Theobjectives of the work reported in this paper were to explore the scale of change propagationin aerospace design and to develop an approach for predicting the effects of changepropagation in redesign. A computer tool has been developed to support this approachaccompanied by an efficient format for representing such information.

2 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, civiland military markets. Within these markets customers have different requirements forequipment, radar, weapons and load-space. It is therefore particularly important that theimpact of these differing requirements are fully understood before the contract for a new craftis signed. Hence, the model presented in this paper is intended for use during tendering andfor assembling design teams in early conceptual design for customisation.

The research began with an extensive series of interviews with chief designers and a managerresponsible for producing tendering estimates for new projects within GKN to explore thenature 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 4steps (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 wereidentified, for example the introduction of two additional countermeasure dispenser pods.

3 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 furtherdeveloped and incorporated into an executable method usable by industry. It is thisdevelopment, along with some of the insights gained from the interviews, which are presentedin this paper.

3.1 The change propagation model

The Change Propagation Model is derived from a Product Model, itself the result of thedecomposition of the product into a set of systems and sub-systems, and their relateddependencies (Figure 1). These dependencies, obtained from an analysis of the productarchitecture, are defined in terms of the likelihood that the redesign of a component will forcethe redesign of another and the impact, or extent, of that redesign. A matrix entry representsthe 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 areidentified, which together represent the whole of the product. These define the row andcolumn headings in the product model matrixes. Second, the direct likelihood and impactrelationships between the components are determined. To date this latter activity has beenundertaken by interviewing people with experience of designing the product in question andthrough workshops that are used to elicit a consensus view.

578 ICED 01 -C586/070

The characterisation of component relationships by their likelihood and impact allowschanges 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 possiblepaths of change propagation can be determined. The change propagation algorithms, based onprobability and Venn diagram arguments, can then be used to identify the overall likelihoodand impact of a change propagating to other components. The risk, or likely impact, can beexpressed in a number of ways, but perhaps the most useful is as the likely cost of the changespredicted. This cost can then be measured directly, in monetary terms, or indirectly, as anexpression of the time required for redesign. Further details of the algorithms used are to befound in another paper [3].

There are many issues regarding the appropriate choice and number of components, thedefinition and quantification of likelihood and impact, and the specification of the initiatingchange. These are the subject of ongoing research. However, a number of these issues, inparticular the sensitivity of the change predictions to variations in the input data, will bediscussed later in the paper.

3.2 A change prediction method

The Change Propagation Model has been incorporated into a change prediction method, asillustrated 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 thechange propagation model. This provides a summary of the change propagation characteristicsfor the whole product. The results of this analysis can be presented in a 'graphical' productrisk matrix (Figure 2 and in more detail in Figure 3), where the size and shape of each elementindicates the likelihood (width) and impact (height) of change between any two systems. Thisallows easy assessment of the potential for change propagation. Indeed systems which aresusceptible 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 analysisof the specific case is required. The change request is first associated with the systems that itimmediately effects. The product change propagation model can then be used to reveal othersystems that may be affected.

A case risk plot (Figure 2) represents the predicted likelihood and impact of these effects (asubset of the data shown in the product risk matrix). Points in the upper right corner of theplot are the most important, as they represent both the most probable and most expensivechanges. When presented with a particular new product requirement, the case risk plot allowsmanagers and designers to see and compare the risk of change to different components. Thisinformation 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 amore informed manner at a lower cost. The following case-study will serve to illustrate theconstruction of the Change Propagation Model and its use in the Change Prediction Method.

4 An example of change prediction

The change propagation model and prediction method have been tested using case studiesfrom GKN Westland Helicopters, based on known changes made to variants of the EH 101helicopter. In all three cases studied, the method predicted all the changes observed, includingthose not present in the original product model. In fact, in most cases, the changes observedwere 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 fourchief 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 identifyand cost particular dependencies, and a smaller number, requiring an averaged view ofdependency with the advantage of reducing the scale of the model. Small matrixes forcomplex products are inherently ambiguous, because the components can be linked throughmany dependencies (see [5] for a discussion of the connectivity).

Two solutions were pursued. The first addressed over 200 components, resulting in a sparselypopulated matrix documenting specific historical changes, aimed at helping designer duringredesign. 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 thelikely 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 impactsare a measure of the degree of change predicted. The product risk matrix for the 19components derived using a three-step propagation analysis is shown in Figure 3. The rowsand columns of the matrix have been reordered to highlight those components most likely toinitiate 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 bereconsidered.

4.2 Change prediction for the EH101

A particular customer requirement involved the introduction of two additional countermeasuredispenser pods, a part of the weapons and defensive systems. This initial change resulted inlocal structural reinforcements (bare fuselage), addition of a deflector plate to protect the in-flight refueling system (fuel and fuselage additional items), repositioning of the UHF antenna(fuselage additional items), nose cap adjustments (bare fuselage), forward looking infra-redradar 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 inFigure 4. This comprises all the data point from the weapons and defensive systems column ofthe 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 18changes were observed, where these represented 2/3 of all the predicted changes found in theupper third of the likelihood scale. In addition, half of the observed changes were notpredicted by direct dependencies and only came to light following the application of thechange prediction method. This latter point illustrates the power of the method in highlightingall areas of potential design change in response to new product requirements.

Two further case studies showed similar results with many of the higher likelihood changespredicted being the same as those observed.

5 Discussion of the results

The preliminary results presented above suggest that the change prediction method haspromise in identifying and rank ordering potential changes as a response to modified designrequirements. 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 whythe current algorithm, based on an investigation of all possible propagation routes [3], cannotbe expanded to larger problems. In practice, however, the computational cost associated withsuch 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 importantconsideration. If the sensitivity is too low, the method will be unable to provide distinctsolutions for varying versions of a product. If the model is too sensitive, slight inaccuracies inthe initial data may result in misleading results. A preliminary investigation into the sensitivityof the method has been conducted. The effect of varying each likelihood and impact value by20% of full-scale (i.e. 0.2) was calculated for the example case presented in the previoussection. Variations causing maximum changes in the predictions were then noted. The orderof the predicted changes, from highest to lowest risk, are compared in Figure 5 for the originaland 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 notmove. 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 predictedchanges 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

6 Conclusions

A method for predicting change propagation in product design has been developed along withan efficient format for representing the results. Initial case study evaluations have beenpromising, with good correlation between predicted and observed changes. The changeprediction 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 managingchange in product redesign. Further work is in progress to develop and validate the methodwith 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] Lindemann, U and Reichwald, R (1998), Integriertes Anderungsmanagement. Springer-Verlag, Berlin.

[2] Steward, D V (1981), "The Design Structure System: A method for managing the designof complex systems," IEEE Transactions on Engineering Management, 28(3), pp71-74.

[3] Clarkson, P J, Simons, C S and Eckert, C M (2001), "Predicting Change Propagation inComplex Design," Proceedings of DETC: 13th International Conference on DesignTheory and Methodology. Pittsburgh, Pennsylvania, 9-12 September.

[4] Coppendale, J (1995), "Manage risk in product and process development and avoidunpleasant surprises," Engineering Management Journal. February 1995, pp35-38.

[5] Eckert, C M, Zanker, W and Clarkson, P J (2001), "A better understanding of change inthe development process", Proceedings of ICED 2001.

Dr P John ClarksonEngineering Design CentreUniversity of CambridgeTrumpington StreetCambridge CB2 1PZUnited KingdomPhone: +44 (0)1223 332 742Fax: +44 (0)1223 332 662E-mail: pjclO@eng.cam.ac.uk

© Cambridge Engineering Design Centre 2001

584 ICED 01 -C586/070

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

SURVEY OF CURRENT UK PRACTICE IN MANAGING TECHNICALDESIGN 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 designis, by its very nature, an activity that involves risk. The only way to eliminate the risk that adesigned artefact will fail to meet its requirements would be to forgo the design process, andinstead reuse an existing artefact of precisely known performance characteristics. Withincreasing product and project complexity the use of formal risk management processesduring 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 riskmanagement approaches [2][3], and to risk management becoming a contractual requirementfor 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 RiskManagement Special Interest Group [5], as has the UK Risk Specific Interest Group of theAssociation for Project Management [6]. However, the importance of risk management variessignificantly with industry, and the emphasis in risk management has been more strongly onproject risk - the likelihood of a project failing to deliver on time and budget - rather thantechnical 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 toidentify the extent to which risk management has penetrated industrial practice, and the natureof the techniques that have been most widely applied. Examples of these studies are Baker etal's survey [7] examining the dependency between industry sector and risk managementpractices (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 inIsrael. Raz and Michael found that simple easy-to-apply tools were the most successful, alongwith simulation, whereas Baker et al suggest that personal/corporate experience andengineering judgement are the most successful techniques, with expected monetary / netpresent value, sensitivity analysis and decision analysis as the principal quantitativetechniques, 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 riskmanagement practice should most productively be concentrated. In the case of the presentwork we have however emphasised in particular the different approaches taken by companiesin the design process to project risk and technical risk. The study was carried out by acombination 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 mightbe used at each stage in the risk management process, and by giving the respondents anopportunity to specify those used in their projects. Questions were then added which aimed todetermine the nature of the risks faced, the barriers to effective risk management and thedegree of integration between project and technical risk management. The questionnaire wasdivided into three sections; the first contained questions to determine the nature of theparticipating companies and the size and general nature of their design projects. The secondand third sections contained questions about tools and techniques for project risk managementand technical risk management respectively. The results reported here concern the first andlast sections.

Most of the questions were "multiple choice" and could be answered by ticking one or moreboxes - sometimes with an optional opportunity to explicitly name another choice which hadnot been included. The structure of the questionnaire is shown in Figure 1 below, along withan indication of how the presentation of a selected subset of the results is organised withinthis 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 thequestionnaire were obtained by: letters to industrial contacts of the research team andsecondary contacts from wider University work (23 responses); telephone calls to companiesobtained 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 SIGof the APM (8 responses). It is clear that such a mechanism for obtaining the sample cannotlead to statistically valid conclusions about the population as a whole: the respondents mustall be assumed to have had a strong interest in risk management (in order to spend the timerequired to complete the questionnaire) and many of them were personal contacts of theresearch team. It should be noted therefore that the respondents probably already had anabove average level interest in risk management, and hence may have been employed bycompanies with a more sophisticated risk management approach than is typical. The samplewas therefore certainly biased, the results can only be regarded as indicative, not statisticallyvalid, and any conclusions drawn are necessarily subjective. The authors believe that this is afactor in much design research: unbiased survey samples are difficult to obtain since thepopulation of most interest is that of commercially practising engineering companies and thedesign engineers who work within them, who often do not have time available to participatein research. As such engineering design research surveys (e.g. [8]) can only point towardsnecessarily subjective conclusions, rather than providing statistically valid proof ofhypotheses, but nevertheless useful insights may be obtained.

3 Results

Of the 63 questionnaires returned, three were omitted because they were not from UK designcompanies and a further three respondents (two construction companies and one softwarecompany) 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 sectorConstructionAerospace

Oil/petrochemicalTechnology/engineering consultant

ManufacturingUtility supply/generation

Coastal/environmental engineeringSoftware

Risk/management consultantsProcess

AutomotiveTOTAL

Number of respondents1811854433322

63

A wide range of engineering disciplines was involved in the projects; respondents were askedto select the three main disciplines involved, and the most popular responses were mechanical(67%), civil (47%), electrical (43%), software (28%), electronic (23%) and aerospaceengineering (13%). The sizes of the projects varied very widely; the average number oftechnical personnel for a project was 47, but responses varied from two to 500. Similarly, theaverage 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% ofrespondents), 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%), productmaintenance (37%) and product disposal (18%).

Respondents were asked to specify whether the main kind of design work involved in theirprojects was original, adaptive or variant design [9]. Fifty three percent of respondentsspecified that their main work was original design, 28% chose adaptive design and 18%specified variant design. However, previous research [8] in which this question wasaddressed to designers suggests that it is likely that many people would classify what is in factadaptive 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 definedas 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, orconcerning 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 purchasedfrom a third-party; Sub-system interactions: uncertainty concerning how components or sub-systems will interact with each other; Design error within sub-system: uncertainty concerningproperties or behaviour of an in-house designed component or sub-system; Aggregate budgetoverruns: uncertainty which cannot be assigned to a single cause, but is due to an aggregationof many uncertain design variables which must not exceed a budgeted limit. An examplewould be the total weight budget for an automotive design, or total power-consumption for anelectrical 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

MaterialsManufacturing processesUsage/loads/environment

Bought-in sub-systemsSub-system interactions

Design error within sub-systemAggregate budget overruns

Almost always13%12%

36%14%23%12%18%

Often40%

33%28%32%

35%26%

36%

Occasionally36%43%'. .32%40%31%52%32%

Almost never11%12%4%14%10%10%14%

Note that in the presentation of results in the tables the percentages of respondents shown fora given risk area are calculated as a percentage of those respondents who stated that the areaapplied to them - i.e. the percentage of those who ticked one of the four boxes "almostalways", "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

MaterialsManufacturing processesUsage/loads/environment

Bought-in sub-systemsSub-system interactions

Design error within sub-systemAggregate budget overruns

Extremely difficult8%4%17%4%18%17%21%

Difficult24%18%26%31%35%30%34%

Quite difficult39%49%43%42%31%49%34%

Not difficult29%29%15%23%16%4%11%

3.3 Which Tools and Techniques are Currently Used?

Company Procedures:

Respondents were asked "Does your company have any formal operating procedures for yourdesign projects or design guidelines which explicitly include risk or reliability assessments forthe 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/processreliability 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 legalrequirements, 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 riskidentification, were used to identify risks that may affect technical risk factors. Brainstorming(79% of respondents), checklists (72%) and interviews (46%) were the most widely usedtechniques for identifying technical risks (along with personal experience (91%) and commonsense (86%)). Risk response analysis (where the secondary risks which may arise from theplanned 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% usedlists developed within the company, 44% used lists developed personally and 15% used thosedeveloped within the industry.

The most widely used tools to support these identification techniques were computer-basedchecklists (used by 44% of respondents). Fourteen percent of respondents stated that theyused published material - examples given by respondents included Ministry of Defencematerial, the PRINCE checklist [12], case histories, technical journals, guides, manuals andresearch papers. Nine percent stated that they used a knowledge-based system to support riskidentification. 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 oftechnical risk factors were qualitative representations (e.g. "major'V'minor"), which wereused by 70% of respondents. This was followed by safety factors (54%), Failure Mode andEffect 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 ofrespondents used decision trees.

Respondents were asked to specify which software tools they used to model uncertainty intechnical risk factors and whether the tools were commercially available or were developedin-house. The most widely used tool was Monte Carlo simulation software, which was usedby 37% of respondents, followed by reliability software (23%) and more specific simulationsoftware (5%). Other software tools named by respondents included spreadsheets, HAZOPsoftware, 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 percentof the reliability software in use had been developed in-house, as had 38% of the Monte Carlosoftware.

When asked "How often do you use the following methods to obtain data on technical riskfactors?" the respondents gave the results are shown in Table 4 below. The greyed areas ofthe table indicate the most popular techniques.

Table 4. Percentage of respondents using specified method to obtain data on technical risk factors

ExperimentService feedback

Third-party documentationDesign analysis

SimulationProbabilistic models

Fuzzy modelsSpecialist reports

Always6%11%4%30%9%6%0%2%

Often40%42%

47%45%

33%12%0%

42%

Occasionally30%

42%47%

17%37%41%4%

46%

Never25%6%2%8%

20%41%

96%10%

Integration of Technical Risk Management with Design and Project Risk Management

When questioned on the extent to which consideration of technical risk was incorporated intothe project risk identification process, 48% percent of respondents stated that the project riskidentification process "very much" included identification of risks which affect the technicalrisk factors, 41% said that it did so only "to a limited extent" and 11% said that project timeand cost considerations were separated from technical risks.

Respondents were asked "During the design project, if it transpires that a technical risk factormay have an impact on project time-scales or costs, how is this information communicated tothe project manager?" and were asked to tick all mechanisms which applied and to specifyany other mechanisms used. Respondents overwhelmingly (98%) used verbal communicationin project meetings, but formal paper-based procedures were also popular (46%), withsoftware and other mechanisms being infrequently used.

3.4 Barriers to Effective Risk Management

The perceived effectiveness of current technical risk management practice was explored byasking "When faced with technical design decisions under uncertainty do you feel that youhave sufficient information available to you to make a rational decision?". In response to thisquestion only 7% were able to answer "Always". Fifty five percent indicated that they oftenhave 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 dealingwith risk by indicating the main reason for difficulty. The options offered and resultsobtained are given in Table 5 below.

Table 5. Main reason for difficulty in dealing with risk

MaterialsManufacturing Processes

UsageBought-In Sub SystemsSub-System Interactions

Design Error in Sub-SystemAggregate Budget Overuns

Collecting data...In principle

9%6%15%10%14%10%7%

In practice54%

49%49%

65%44%58%50%

Modelling imIn principle

13%16%11%17%26%16%13%

pact of data. . .In practice

25%28%26%9%16%16%30%

4 Conclusions

The results obtained concerned a wide spectrum of type and size of engineering designproject, and can be considered representative of practice in "risk-aware" engineering designcompanies, though they do not provide a statistically unbiased sample.

The survey suggests that technical risk management is not well integrated with design andproject management processes. For nearly half the respondents, consideration of technical riskwas not well incorporated into the project risk identification process - i.e. the process ofidentifying cost and timescale risks. Also, nearly half the respondents had no formal paper-based or software mechanism to communicate the impact of technical risks on projecttimescales and costs.

The use of probabilistic modelling techniques was not found to be widespread, withqualitative techniques being more widely used. Software tools, when used, are oftendeveloped in-house or, if commercial, are low-level modelling tools (e.g. Monte Carlo add-insfor spreadsheets) rather than risk management packages. Over half the respondents did notuse any software tools at all to model uncertainty in technical risk factors. Sixty nine percentof the reliability software in use had been developed in-house, as had 38% of the Monte Carlosoftware. This last figure is particularly surprising considering the relative complexity of suchsoftware, when compared for example with development of a simple custom databaseapplication. In contrast, only 18% of the Monte Carlo software used to model project risk wasdeveloped 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 budgetoverruns (54%). The areas where it was seen as most difficult to deal with were aggregatebudget overruns (55% stated this was "extremely difficult" or "difficult"), followed by sub-system interactions (53%), followed by design errors in sub-systems (47%). Hence the twomost problematic areas are aggregate budget overruns and sub-system interactions, which areboth clearly related to product complexity. In every single area, the main reason given fordifficulty 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 technicaldesign decisions. The findings of this survey suggest that efforts should be concentrated ondeveloping systems to help manage complex risk data - for example computer systems tohelp 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 facilitaterapid development of complex risk models during design.

References

[I] Cooper. D. F. and Chapman. C. B.. "Risk Analysis for Large Projects: Models. Methodsand Cases". Chichester: John Wiley and Sons, 1987.

[2] Chapman, C. B. and Ward S., "Project Risk Management: Processes. Techniques andInsights". Chichester: John Wiley & Sons Ltd., 1997.

[3] Williams, T., "A Classified Bibliography of Recent Research Relating to Project RiskManagement", European Journal of Operational Research, vol. 85, pp. 18-38, 1995.

[4] MoD(PE)-DPP(PM) "Risk Management in Defence Procurement", reference D 1DPP(PM) /2/1/12, available from Ministry of Defence Executive, Directorate of Policy(Project Management), Room 6302, Main Building, Whitehall, London., 1991.

[5] http://www.risksig.com/, Project Management Institute Risk Management Group, 2000

[6] http://www.eurolog.demon.co.uk/index.htm, Association for Project Management RiskManagement Specific Interest Group, 2000

[7] Baker, S., Ponniah, D., and Smith, S., "Survey of Risk Management in Major UKCompanies", Journal of Professional Issues in Engineering Education and Practice, vol.125, no. 3, pp. 94-102, July. 1999.

[8] Raz, T and Michael, E, "Benchmarking the Use of Project Management Tools",Proc.30th Project Management Institute Symposium. Pennsylvania. Pa. 1999

[9] Grassland, R., McMahon, C. A. and Sims Williams, J. H., "Survey of Current Practicein Managing Design Risk". Bristol: University of Bristol. ISBN 0-86292-474-X, 1998.

[10] Court, A. W., Culley, S. J. and McMahon, C. A., "A Survey of Information Access andStorage Amongst Engineering Designers". Bath: The University of Bath, ISBN 185790 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 CentralComputer and Telecommunications Agency, a UK government procurement agency.For further information contact the CCTA at Rosebery Court, St. Andrews BusinessPark, Norwich, NR7 OHS

Chris McMahonUniversity 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)1179294423, 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 DESIGNICED 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.

1 Introduction

By all accounts, ship safety is in a transitional state reflecting the shift from design peripheryto a core design factor and from a post-design consideration to a through-life designimperative. Conventional approaches are under scrutiny and potential new approaches comeunder the microscope as the shipping industry is forced into responding positively. Thetraditional inertia has been overcome by a new stronger resurgence of safety as a key issuethat cannot be considered in isolation any longer nor fixed by add-ons, bringing home thelong overdue realisation that lack of safety or ineffective approaches to safety can driveshippers out of business.

On the other hand, current ship design practice is not an efficient process, mainly due tolacking of a framework capable of accommodating scientific advances and emergingcomputer technologies, and the consequent benefits derived therefrom. Attempts to improvethe 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 nothingmore than increasing the speed of the design process and, in some cases, improving thequality of separate design tasks. Deriving from this, there is clear need for a formalised shipdesign framework that accommodates and provides for ship design tasks in a way that allowsfor interaction and iteration in an integrated design environment.

To this end, the paper describes the development of an Integrated Design EnvironmentArchitecture ("IDEA") for Safety. Following the identification of requirements for thedevelopment, the specific elements of the integrated design environment are detailed, withparticular emphasis given to the suitability of Blackboard Systems (BBS), the core of thedevelopment, to ship design.

2 Background

2.1 The ship design process

Ship design is uniquely characterised by the fact that some of the most important decisionsregarding the vessel are taken at the early stages of the process, allowing all later designactions, 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 sametime 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 designprocess 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 ofmany 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 introduceddecades ago by Evans [1], with attempts in recent years focused on enhancements through theintroduction of computer technology and modelling techniques [2, 3, 4, 5]. The ship designspiral advocates an iterative, step-wise solution procedure that is time-consuming andproduces results, which may be acceptable but not necessarily optimal. It certainly does nottake into account whole life cycle issues and is not capable of accommodating effectively andefficiently 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 academiaworld-wide resulting in quality software packages, advances in technology and scientificunderstanding, which combined have shortened considerably the time required during the shipdesign process. Regarding the former, ship design is still in need of a formalised frameworkto control and manage the design process in an efficient way with the potential to takeadvantage 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 thisprocess, safety assessment is the "back-bone" that provides a two-way dynamic link betweentechnological developments and design. On the one hand, it gathers and assimilates technicalinformation, prioritises safety issues, identifies practical and cost-effective safety-enhancingsolutions 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 andre-appraisal of the "tools", in the light of the experience gained from implementation and

594 ICED01-C586/639

ICED 01 -C586/639 595

Figure 3: Relationship between Safety, Costs, and Design Constraints

A chief concern in integrating safety in the design process, particularly when claiming thatthis must be done in a way that safety "drives" design relates to the presumption that anyinvestment on safety does not compromise returns. This concept is ill-based. Figure 3illustrates the relationship between economic and technical issues in a safe ship designprocess. The outer boundary corresponds to a design solution that achieves a perfect balanceamong all safety and cost criteria and constraints, which is presently unattainable. Today'spractice is represented by the inner boundary, whilst it is argued that a safety-effective andcost-effective solution could be achieved by adopting first-principles-based design. Theenhanced awareness on safety-related issues and the improved appreciation of how safety andcost interrelate and interact is slowly beginning to drive home the simple fact that scientificapproaches to dealing with safety are the key to increasing competitiveness.

Figure 2: Safe Ship Design Iterative Process

practical applications. This dynamic interplay is demonstrated in Figure 2. This way, itwould facilitate implementation of technological innovation and hence development of safeinnovative designs to meet the demands of current and emerging markets. A thorough reviewof the Design for Safety philosophy is given in [6].

3 An "IDEA" for safety

An Integrated Design Environment Architecture ("IDEA") provides the designer with ameans 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 therelevant issues are generic. This allows information to dynamically change, for alteringdesign input and innovations can be readily implemented. The design information is stored inobject-oriented knowledge bases, which are updated independently as required. A control andmanagement function is needed to accommodate these issues.

Blackboard Systems (BBS) have been identified to have such a potential and are beingutilised as the platform to overcome the stated deficiencies. The development of a formalisedship design framework, particularly one addressing "Design for Safety", must adopt anintegrated approach, accommodated in a providing environment, which links the ship designtasks and allows for interaction and iteration between them. In this process, a blackboardsystem supports a dynamic interface between tools and methodologies applied to the variousdesign tasks and it stores/retrieves, as necessary, information about ship design in aknowledge base. An "IDEA" for Safety is illustrated in Figure 4, having a central blackboardto control and manage the overall ship design process applying the appropriate knowledgebases, tools and methodologies.

Figure 4: An "IDEA" for Safety

The integrated Design for Safety environment, illustrated in Figure 5, accommodates amethodological assessment of relationships between safety, cost, and design features adoptinga 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 Safetyaccommodates the identification of risk prevention and mitigation measures, cost-benefitquantification of design features/safeguards, assessment of ship performance effects andprovides decision support in order to design safe, cost-efficient ships fulfilling the operationalthemes in an iterative procedure. A holistic description of the various elements of theintegrated environment has been reported in [7].

4 Blackboard systems

Blackboard systems (BBS) are regarded as a part of the Artificial Intelligence family andoriginated with the Hearsay project in the USA twenty years ago [8, 9]. BBS constitute arealisation 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 becarried 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 theblackboard by using external knowledge sources, which are working co-operatively and areactivated by a control mechanism, be it human or software programs, applying the rightknowledge at the right time [11]. In this respect, various sources of knowledge participate informing and modifying the emerging solution by knowledge sources contributingopportunistically when called upon. Furthermore, as steps are taken toward the solution, theprocessing commitments are minimised since the solution is built incrementally and steps offorward chaining can be arbitrarily interleaved with steps of backward chaining. Blackboardsystems are particularly effective for incremental solution generation, which is typical for theship design process, where the knowledge sources contribute to the solution as appropriateoutperforming a problem solver that uses the traditional ship design approach to generate asolution.

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 theproblem and they have a formal structure to receive and send information in order tocommunicate with the blackboard. Knowledge sources are static repositories of knowledge,which are activated in a predetermined way by trigger functions, or instances, which are theactive functions looking for a triggering command, or condition, on the blackboard.Knowledge sources can be referred to as agents in engineering applications where thetechnology supports the integration of fully autonomous software and human expertise.Knowledge sources can be added or deleted from the blackboard system as required withoutinfluencing the overall performance of the blackboard, they can have a wide diversity in ways

ICED01-C586/639 597

598 ICED01-C586/639

of representing information and problem solving techniques, but must operate based upon acommon interaction language. With regard to ship design, lines development could be such aknowledge source, engine selection another, both performed in the ship design process basedupon separate methods, tools, and information.

The blackboard: A global structure that is available to all knowledge sources and serves as astorage medium of raw input data, partial and final solutions, and control information, as acommunication medium and buffer, and as a knowledge source trigger mechanism.

A control component: It directs the problem-solving process by allowing knowledge sourcesto respond opportunistically to changes on the blackboard database. The control triggers anyknowledge source based upon a defined ranking, and it can change the focus of attentionbased on the state of the solution.

Figure 6: Blackboard Systems Components

4.2 Application of BBS to ship design

Blackboard systems offer a powerful problem-solving framework when satisfying the fivearguments on the left side of Table 1 and their application to ship design is justified on theright hand side of the same table.

Blackboard applications are not widely used despite their long history and documentedadvantages. The reason for this is "that blackboards are only worth pursuing for complexapplications" and "while useful for prototyping an application, once developed andunderstood, 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 tobeat in any case. The best example on this is ship designers who produce ship designs basedon feeling and experience. Three situations are given in Table 2 when a blackboard system isnot directly applicable to ship design. These arguments highlight research and developmentrequired for the introduction of blackboard systems in the ship design process.

Knowledge SourcesSoftware specialists each providingexpertise needed by theapplication.The Blackboard

Shared repository of problems,partial solutions, suggestions,recommendations, and contributedinformation.Control Shell

Controls the flow of problem-solving activity in the application.

Table 1 : Applicability of Blackboard Systems to Ship Design

Blackboard Systems

Many diverse, specialised knowledgerepresentations are needed.

An integration framework is needed thatallows for heterogeneous problem-solvingrepresentation and expertise.

The development of an application involvesnumerous developers.Uncertain knowledge or limited data inhibitsabsolute determination of a solution.Multilevel reasoning or flexible, dynamiccontrol of problem-solving activities isrequired in an application.

Ship Design

There are few engineering activities that aremore diversified and specialised than shipdesign.A ship design evolves today by performingheterogeneous tasks in a sequential order.A framework for control and management isneeded.Ship design activities involve numerousorganisations, suppliers, consultants, etc.Alternative solutions can be designed withlittle extra effort absorbing uncertainties.Ship design will profit immensely byenabling dynamic control between two ormore applications such as stability andresistance.

Table 2: Inapplicability of Blackboard Systems to Ship Design

Blackboard SystemsAll knowledge could be easily represented ina framework with which a user is alreadyfamiliar.The application does not need to makedynamic control decisions.

The complete application will not becombined with other systems.

Ship DesignThis has yet to be achieved within shipdesign - the knowledge exists in variousplaces and forms.When implemented this function leads tosavings on time, effort, and fewer errors.Moreover, with the implementation ofsimulation in design this function is needed.Ship design comprises numerous systems -a framework controlling and managingthese systems is called for.

5 Conclusion

Ship design is in need of a formalised framework that allows for efficient interaction andintegration among the ship design tasks and the adoption of an integrated approachaccommodated in a providing environment. Blackboard systems have been utilised as theplatform in such an environment, which provides a dynamic interface between the variousdesign tools and methodologies. Experience so far suggests that blackboard systems providethe appropriate vehicle for accommodating the ship design process and new emergingcomputer 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 shipdesign process. Visualisation is a field that will make huge advances into ship design with thedevelopment of high performance PCs to model and simulate ship operations enabling largesavings 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 toproduce better solutions through this dynamic interaction between operational and designphases.

References

[I] Evans, J.H.: "Basic Design Concepts", Journal of the American Society of NavalEngineers (ASNE). November 1959, pp. 671-678.

[2] Buxton, I.L.: "Engineering Economics and Ship Design". BMT Publication, 3rd Edition,1987.

[3] Andrews, D.: "Creative Ship Design", Transactions of the Royal Institution of NavalArchitects (RINA). Vol. 123, 1981, pp. 447-471.

[4] Mistree, F., Smith, W.F., Bras, B.A., Allen, J.K., and Muster, D.: "Decision-BasedDesign: A Contemporary Paradigm Ship Design", Transactions of the Society of NavalArchitects and Marine Engineers (SNAME). Vol. 98, 1990, pp. 565-597.

[5] State of the Art Report on "Design Methods". The Sixth International Marine DesignConference (IMDC 97), Vol. 2: State of the Art Reports, 23-25 June 1997, University ofNewcastle upon Tyne.

[6] Vassalos, D.: "Shaping Ship Safety: The Face of the Future", Marine Technology. Vol.36, No. 2, April 1999, pp. 61-73.

[7] Vassalos, D., Oestvik, I. and Konovessis, D.: "Design for Safety: Development andApplication of a Formalised Methodology", Proceedings of the Seventh InternationalMarine Design Conference (IMDC 2000X 21-24 May 2000, Kyongju, Korea, pp. 151-165.

[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", ACMComputing Surveys. Vol. 12, No. 2, 1980, pp. 213-253.

[9] Nii, H.P.: "Blackboard Systems: The Blackboard Model of Problem Solving and theEvolution of Blackboard Architectures" (Part 1), "Blackboard Systems: BlackboardApplication 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 Engineeringwithin the Context of Product Design Development", Strathclvde University CADCentre Paper. CADC\P\95-13, 3 August 1995.

[II] Corkill, D.D.: "Blackboard Systems", AI Expert. Vol. 6, No. 9, September 1991, pp. 40-47.

[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 onToday's Shipbuilding", Marine Technology. Vol. 34, No. 1, January 1997, pp. 1-9.

Professor Dracos VassalosDepartment 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 DESIGNICED 0! GLASGOW, AUGUST 21-23, 2001

HOW MUTUAL MISCONCEPTIONS BETWEEN DESIGNERS ANDOPERATORS 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 revenueand human life, and considerable damage to the natural environment. A central role is oftenplayed by the misconceptions that designers have about the intentions of operators ormaintenance staff, and operators' misconceptions about the intentions of designers. Thepurpose of this study is to extract knowledge from investigative reports about how mutualmisconceptions have occurred, and direct it at the primary decision making points in both thedesign and operating processes.

1.2 Background

Various work in the recent past has prescribed specific processes or decision making methodsto improve the attention paid to safety during design (for example Gauthier and Charron1995; Stoop 1997). These methods help set limits on the designer's ability to make unsafedecisions, for example by requiring certain kinds of hazard analysis, and build into the designprocess the benefits of past experience. But any method that constrains the designer can alsomake the design process less responsive to the specific circumstances of particular cases, andreduce the extent to which the designer can imaginatively make designs inherently safe. Anumber of studies have instead concentrated on developing accident databases that providedesigners 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 designdiscipline and type of artefact involved, and often give the designer little insight into thesystemic problems that in fact contributed to the accident. In particular, they often say little ornothing about the expectations that designers and users of the design, such as operators andmaintenance staff, had about each other.

Much is known about various parts of the problem: about the ways the design of an artefactinfluences error in its use (for example Norman 1992), about the characteristics that lead toomissions in maintenance tasks (Reason 1997), about the way that systems suffer fromcomplex interactivity and tight coupling (Perrow 1984), and about the fallacy of the 'defence-in-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 oneanother'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 bothonshore and offshore process plant. Such plant presents a variety of hazards that could arisefrom designers and operators having a flawed understanding of each others' intentions - buttheir 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 ofa failure rapid and unpredictable, and it can pose considerable problems for the evacuation ofstaff 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 aboutoperators' intentions or operators' misconceptions about designers' intentions;the development of agenda-generating mechanisms that use the outcomes of thepreceding stages in an attempt to influence key decision making points in the designprocess;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. Thisfollows the procedure reported in an earlier study (Busby and Strutt 1999) and draws on thedataset used for that study (which concerned offshore installations), together with anadditional dataset of accident reports in onshore installations. Fourteen of these were reportedby 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 includedbrittle fracture, unexpected static electricity discharge, degraded hoses, ruptured pressurevessels and so on. All reports also cited human and organisational error and it is primarilythese 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 lookingfor 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 thesecausal analyses, that appeared to involve some kind of misconception between designer andoperator. 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 wereidentified (that is, who did the misconceiving, and who the misconception concerned). Thereare several factors that complicated this analysis:

The identification of subject and object is not always unambiguous. For example, if thedesigner had failed to anticipate that an operator would use a device in an unintendedway, 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 donot meet their intentions.It is often unclear from the accident investigator's report what beliefs lay behind people'sactions, and it is quite likely that an investigator would often not be able to determinethese beliefs. In some cases, therefore, the analysis involved identifying possible, ratherthan 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 wrongas 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 specificmisconceptions. The purpose has been both to capture the nature of the misconceptions andto try to explain why they had not been undermined by experience. Organisational andindividual experience among engineers, in principle, should weed out dangerous models. Sowhere such dangerous models persist it is important to try to work out what is wrong with theway engineering organisations work, the way engineering knowledge accumulates, or theway individuals learn about the consequences of their work.

3 Results

From the cases, about 120 distinct misconceptions have been identified. Rather than list all ofthem, we have described below some of the generalised modes of misconception togetherwith some of the cases in which they arose. We have concentrated on the misconceptionswhich designers appear to hold about operators.

3.1 Holding mechanistic stereotypes of operators

Several of the misconceptions involved designers making design decisions as though thehuman operators lacked exactly those characteristics that made them human. For example,operators would be required to sustain attention in a warm, comfortable environment for longperiods, scanning for unusual conditions which occurred only rarely. These are typicallyconditions that are incompatible with attention and arousal (Warm 1984). Similarly, thefailure of operators to follow written instructions in operation and maintenance wasimplicated: in eleven of the onshore accidents injury or death resulted following the neglectof 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. Ifdesigners can predict that instructions will not be followed there is an argument they shouldnot rely on instruction following for safe operation. If the objective of engineering is to servehuman society, it seems unreasonable that engineers should not acknowledge humancharacteristics.

One explanation of why designers sometimes fail to acknowledge the limits of humanattention is that the operator simply does not enter the designer's model of the system. Butthis cannot be true if the designer provides a device that requires human intervention. It mustbe the case that the designer's model of the human operator is based on a stereotype thatlacks human characteristics. It seems absurd that designers could really use models ofoperators that lack what they know to characterise a human being, but it may be self-servingto 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 peopleattribute 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 avessel knowingly sailed into a storm even after sustaining early, minor damage. He was undertime pressure, and apparently made a decision based on his assessment of probabilities andoutcomes. But it is unlikely that his probability estimations were good ones. There is anargument that if designers predicted that operators would gamble with using equipmentknowingly in hazardous modes then they could provide information to support them. It is notenough as a designer to say that product X is unlikely to function in condition Y: it isimportant to say that product X in condition Y has a probability p of failing. Again it ispossible to speculate on why designers' models of operators do not seem to acknowledge thatoperators will gamble (and should either be helped to gamble informatively or possiblyimpeded to gamble entirely). It is plausible, for instance, that designers did not predict thatoperators would be under production pressure. Then there would be no reason to gamblesince there would be nothing to gain from it - although, conceivably, operators might gambleif 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 ofcircumstances that operators work in. The failure to predict gambling behaviour would thenbe 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 toacquire little experience in testing boundaries - so boundary infringement is a prime cause ofaccidents. For example, in one case operators had adopted a ballasting practice on a semi-submersible 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 aninstallation. In such cases the operators did not acknowledge safe limits to operation of aparticular device, and the designers had provided a system which allowed or encouraged theoperators to exceed these safe limits. If designers better understood the conditions which leadoperators to exceed limits, and if operators better understood the inherent limitations in aparticular design, this kind of accident becomes less likely.

The accident investigations, unsurprisingly, say nothing about the origins of these causes. Butit seems likely that designers' weakness at inspecting boundary conditions arises from:

analytical difficulty (it can be difficult to identify comprehensively what kind of operationin 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 anaccident, so designers may have little empirical knowledge about a design's operatingboundaries);motivational considerations (designers probably are reluctant to defeat their creations somay find it hard to think systematically about their failure).

It also seems likely that operators' inability to acquire experience in testing boundaries arisesfrom:

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 exploreboundaries);system complexity (it may be infeasible to develop sufficiently realistic simulations).

Since the boundaries of safe operation vary according to environmental conditions incombination with operator actions these difficulties are all amplified. Operators wanting toknow what happens if they adopt a particular ballasting practice, for instance, would need todo 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 isexceeded, but we have described it separately because the boundary is a temporal one and theprocess of reaching the boundary (time elapsing) is not one that operators control. A simpleexample of this was a case where a set of hoses that failed, partly because they had been usedfor too long. But their service life had not been specified by the designers so there wasapparently no clear criterion for replacement for the maintenance and operating staff.Possibly the designers assumed a level of preventive maintenance that was unrealistic for theenvironment, 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 canexpect an operator to be capable of. This will include expectations about whethermaintenance is preventive and whether there is enough knowledge to know when an artefacthas become hazardous. When designers can reasonably expect operators to make highlycompetent decisions about when to replace degraded artefacts it may be the case that theoperators will be in a better position to say when something should be replaced than adesigner. Even then, however, it seems sensible that designers should provide guidance thatcan be used if competence turns out to fall short. This, in most cases, would include servicelife ratings.

3.5 Failing to anticipate operators' non-routine goals

In certain cases the design of a piece of equipment confounded operators' intentions whenthey were trying to do something outside a routine or planned process. Tragically thisincluded operators evacuating an offshore installation in unpredicted circumstances. Theinstallation was a semi-submersible platform which had partially capsized. When operatorstried to evacuate they found that the design of the lifeboat davits precluding launching in apartial capsize, and only allowed launching in a full capsize. Designers appear to identify aprocess which the design has to support, in this case evacuation following a capsize, butapparently sometimes do not reason about how the design can confound operators when thereare differences to this process, in this case a capsize which does not fully develop (at leastinitially). What is required in cases like this is a systematic way of perturbing the conditionsassumed by the designer, and testing whether the design is still satisfactory in the perturbedconditions. Routines like HAZOP do support this kind of reasoning. But its success dependson the designers' ability to identify all feasible perturbations, and then to identify all theconsequences, 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 apotentially hazardous state. For example, maintenance staff left open a hatch that should havebeen closed to prevent water ingress; an operator of a vessel left an autopilot engaged duringclose manoeuvring; a cleaner left an oven on after cleaning. In such cases, the operator hadprobably planned to change the state of the equipment but had failed to execute the plan afterhis or her attention had switched - perhaps following an interruption. Such lapses arepredictable. Putting the equipment into the state that later became hazardous was somethingthe operator had to do to accomplish an immediate goal, while changing the state into abenign condition was not necessary to accomplishing such a goal. It is obviously not feasiblein all cases for the designer to do anything about possible lapses, but it probably is feasiblefor the designer to identify hazardous states and ask whether they could be reached by a lapseon the part of the operator. Sometimes it might be sufficient to improve the cues provided bythe 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 eachother'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 byinappropriate belief systems - such as the expectation among designers that operators willseek 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 beable to avoid the hazardous situations that arise from misconceptions. And, because the beliefsystems 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 designerhad not considered the possibility of an event - not that he or she held a wrong belief aboutthat event. This in turn suggests that the designer's model of the design being operated wasincomplete in such cases. In some respects, missing conceptions are worse thanmisconceptions: 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 importantone when thinking about how to remedy problems of this kind.

It is important, however, to acknowledge the limitations of this study - which are bothcontextual and methodological. The contextual limitation is that the domain that was studiedis quite specialised, and involves the design of highly complex systems which are used byprofessional operators. Misconceptions between designers and users of, say, consumerproducts might be quite different. The main methodological limitation in this study has to dowith the dependence on accidents and accidents investigations in particular to reveal mutualmisconceptions. This means that:

606 ICED01-C586/029

1. Misconceptions that happened not to lead to accidents, but near misses for instance, werenot 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 thatwas implicated in the accident.

3. We know very little if anything of the designer's circumstances - whether he or she wasexperienced, for example.

The upshot is that we can draw plausible conclusions about the misconceptions that candevelop between designers and operators, and suggest what kind of misconception to avoid inthe 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-terraincranes. 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 fordesign for safety. Proceedings of the International Conference on Engineering DesignICED99, Munich, 24-26 August, 1489-1494.Chung PW and Jefferson M (1998). The integration of accident databases with computertools 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 engineeringapproach. 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. GulfPublishing (Houston).Norman DA (1992). Design principles for cognitive artifacts. Research in EngineeringDesign, 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 onEngineering Design ICED97, Tampere, August 19-21, pp 609-614.Warm JS (ed.), Sustained Attention in Human Performance, John Wiley (New York).

Corresponding authorJ S BusbyDept. of Mechanical Eng.University of BathBathBA2 7AYUKTel. +44 1225-826588Fax. +44 1225-826928Email ensjbb@bath.ac.uk

©IMechE2001

1CED01-C586/029 607

This page intentionally left blank

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

A PROJECT VIEW OF THE HANDLING OF UNCERTAINTIES INCOMPLEX PRODUCT DEVELOPMENT ORGANIZATIONS

R Olsson

Keywords: Risk and opportunity management, uncertainty management, integrated productdevelopment.

1 Introduction

The situation in today's complex product development project is growing more and moretowards a total involvement of most functions within the organization. The case of a group offew and, within their own area, highly competent engineers performing most of the tasks infulfilling an idea to a produced product is obsolete. Instead, an interaction across functionaldepartments and within functions is required for a cost-effective success of the outcome of theproject.

As product development schedules shrink, it becomes more and more crucial that co-operation, communication and management of product development, function in a shorterspan of time [1]. Though refinements have been and are made for processes, tools andmethods, still the problems lie at the more mental state of mind within a product developmentorganization. Combining technology and organization and transforming it into a symbioticrelation is a difficult task to manage [2]. New, unproved technologies are inherently risky inthe early stages of product development. The risks usually include a combination oftechnological, manufacturing, financial and business factors [3].

Whilst not fully being able to integrate all aspects of product development, uncertainties arisewithin the product development project and the organization. Uncertainties that will influencethe outcome of project time and cost issues, organizational revenues and the customer's viewof inadequacy of the organization. To be able to function better both within a productdevelopment project and in the assisting and interactive functions within the organization onemust 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 productdevelopment organizations.

Techniques of identifying and analyzing uncertainties along with the action planning are quitewell known and will not be discussed and therefore not included in the objectives. Instead theorganizational and managerial aspects are of interest and therefore form the basis for thispaper.

1CED01-C586/141 609

The following objectives will be covered:

To suggest theoretical bases for handling of uncertainties within complex productdevelopment organizations.

To study the case of handling uncertainties within an organization, to study factors forsuccess, needs and concerns within such an organization.

To propose suggestions for future research directions that will contribute in the area ofUncertainty Management.

The paper is based on findings from a case study conducted within Adtranz, a global providerof railway services, rolling stock and systems. Also empirical findings from previouscorporate initiatives and action research findings from a pilot project form the base for thispaper. It is outlined according to the three objectives mentioned above. The first sectiondescribes 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 thirdsection proposes the direction for future research. The first two sections are described in moredetail 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 25persons within Adtranz. Managers, engineers and other functions within the project or lineorganization were interviewed. An interview guide/combined survey has been prepared by theresearcher 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 personswithin Adtranz. The rate of response was 66%. Due to time constraints all interviewees couldnot be included. The survey consists of 35 questions where 15 of them were open (that is, noanswering alternatives were given).

2 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 focuseson the planned change of human systems and contributes to organization science through theknowledge gained from its study of complex change dynamics.

When describing organizational settings and relations, a separation between the organization'sinternal and the organization's external settings and relations is made to view distinctiveprerequisites. Internal relations and settings could be described in factors constituting theorganizational work setting [2]. The factors are divided into four basic categories, organizingarrangements, social factors, physical settings and technology. Although they have been dealtwith separately, these categories are inevitably interconnected.

Transorganizational systems are comprised of organizations that have joined together for acommon purpose [4]. A common purpose of co-operating internationally within theorganization, in consortia's, with subsidiaries and with subcontractors delivering solutions tothe concept. For an organization, it is crucial to understand not only the organizationalsettings 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 uncertaintyabout whether potentially significant and/or disappointing outcomes of decisions will berealized [5], This definition of risk consists of three dimensions, Outcome uncertainty,Outcome expectations and Outcome potential. Uncertainty is described as an outcome, whichcould result in a positive or negative impact. Uncertainty could either be an opportunity or arisk. The perception of uncertainty often leads to the, quite common but narrow, interpretationof being risks. Though it is much easier to identify negative outcomes from uncertainties, it isof 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 ofalternative concepts, the consequent narrowing of alternatives to a reliable and repeatableproduct produced in production [6]. The development of new products is a classic example ofthe use of project management. From a risk management perspective however, this type ofproject is unique: the risks are high due to the uncertainty as a prerequisite for any productdevelopment project launch, the very nature of the project therefore is to reduce risk. Thediscipline of project risk management has developed over the past few decades as animportant part of project management.

Risk Management usually consists of four basic steps: Identification, assessment, responseplanning/action and monitoring and control but sometimes also the preceding step of riskmanagement planning [7]. However, methods of managing risks are of great importance, thefocus being on the execution of a series of actions in order to achieve a stable and well-knownrisk list with plans for mitigation and monitoring.

Various techniques for addressing and performing the above four steps in risk managementare frequently presented in previous research [e.g. 1, 8]. However, research focusing on theinteraction between project- and functional organization and corporate management seems tobe rare. Furthermore, the focus has been on a single project basis and mostly on the executionphases of a project. As risks arise within product development projects, not all of them can bemanaged within the project boundaries. Instead the responsibility for the management of risksorganizationally lies either in another functional department, at sub-suppliers, at the customersor within the management of the organization.

Research of today seems not to focus on the positive side of uncertainties as much as thenegative. As long as an uncertain issue is not assessed to whether it is considered a risk or anopportunity, uncertainties cannot be properly handled neither within the project nor within theorganization. Traditional project risk management can portray negative aspects deriving fromuncertainties, omitting large positive outcomes i.e. opportunities [9]. Kahkonen thereforeemphasizes project risk and opportunity management, as a means to vindicate a focus onopportunities as well as risks.

3 The industrial situation - Adtranz

Adtranz is a global provider of railway services, rolling stock and systems. They supply masstransit and main line vehicles, plus the related components, train control and communicationsystems. Adtranz has 22,000 employees in 40 countries, mainly in Western Europe, but alsoin India, the USA and Australia. The development of products is built on a global transfer ofknow-how organized centrally per product type and according to the modular concept.

ICED01-C586/141 611

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 dividedinto a platform development process and a tender/order execution process. The activitiesrange from product strategy and the first marketing activity to the complete take-over, supportand service at the customer. The QG methodology consists of lists of issues to be checked atthe end of every sub process as a gate check of completion and quality of work. Though theBP and QG methodology is not the product development model itself, it gives a framework

612 ICED01-C586/141

The following prerequisites describe the situation within Adtranz. Prerequisites that areobstructing the organization to take use of existing techniques and methods within the area ofRisk 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 pre-requisites 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 increaseexponentially 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 particularlyso in the case of major projects.

3.1 Adtranz Business Process

Within the Adtranz group, a common process model called Business Process (BP) is appliedin all product units as the basis for deployment, further development and application ofprocesses and procedures. Also a methodology called Quality Gates (QG) is applied formonitoring of progress at different pre-determined gates. As the BP and QG methodologyitself is a process model developed for the enhancement of a globally structured process, itstill handles uncertainties and is therefore considered as an approach for an overall handlingof uncertainties.

and guidance for developing a product. In more detail, this model consists of a workbreakdown structure (WBS) specifically designed for each Product Unit. Such WBS describesdevelopment work to be fulfilled in every step of the project, functional interaction andobjectives for each and every activity description. Though the BP and QG methodology itselfis a means for identifying, assessing, planning and monitoring of uncertainties known inadvance 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 anadd-in within the BP and QG methodology, it serves as the means for capturing and handlinguncertainties throughout the nroduct develooment nroiect.

Figure 2. The figure shows the observed relation between uncertainties included in QG checklists and the totalamount of uncertainties within a product development project.

3.2 Organizational view on the existing Business Process and Quality Gatemethodology

It is common knowledge that a model for product development must be a part of anyorganization developing complex products. The application of such an approach as the BPand the QG methodology is considered a well-structured approach, providing a common"language" within the organization. The results also indicate that this model ensures astandardized way of working with enhanced ability to monitor and control a productdevelopment project worldwide. The findings also indicate that the purpose of the BP and theQG methodology must be clearly defined and communicated throughout the organization. Tofurther explain the need of the "knowledge of purpose", a common understanding and afeeling of participation amongst employees and proved benefit of use has to be facilitated. Itis quite clear that the BP and the QG methodology is not considered sufficient for an adequatehandling 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 useof the QG methodology and the Project Risk and Opportunity Management process (PROM).The QG methodology handles uncertainties known in advance. Such uncertain issues aregathered from post-project feedback, the integrated work within the entire project and thecreation of project tailored checklists. These checklists are grouped into deliverables and keydeliverables in areas agreed upon within the project. Since all issues causing uncertainties to aproduct development project cannot be included, this method leaves large areas ofuncertainties to be dealt with within the management of the project. As seen in figure 3, itindicates a view of the unsatisfactory ability to handle uncertainties within the BP and QGmethodology.

ICED01-C586/141 613

Figure 4. The figure shows the interviewees perception of what will happen to uncertainties not included inchecklists.

The PROM approach is a methodology for handling uncertainties from the single projectperspective. The methodology defines the strategy of creating a project based uncertaintymanagement process, the sources for identification of uncertain events, the method of

Figure 3. The figure shows the interviewees perception of how well the handling of uncertainties is consideredwithin the Business Process and Quality Gate methodology.

When looking outside of the project boundaries, 80% of the interviewees consider the BP andQG methodology not to handle risks and opportunities within the line organization to asatisfactory extent. This supports the continuous focus on the interaction between the projectorganization and the line organization. In organizations such as Adtranz it is important to holdthe ability to manage cross-functional interaction as well as to manage common causes ofuncertainties within an international environment.

As this methodology relies on the active management of the development project and thereactive attitude towards uncertainties, it is important that checklists to follow up in QualityGates will produce wanted results. Figure 4 shows the perception of what will happen toissues not included as a deliverable in such a checklist. The major opinion is that they will notget the proper focus, be de-prioritized and only become visible later in the project progresswhen a proper handling it is probably too late. Also the opinion is that issues not included willmean a risk of them being forgotten about or actually being ignored.

614 ICED01-C586/141

assessing uncertainties, the response planning and the method of follow-up and control. Acomputerized program supports this methodology. The emphasis is on both risks andopportunities. Though this methodology is well known and is used, to a various extent, withindifferent 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 themanagement 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 beused.

4 Conclusions and future challenges

Organizations developing large complex products face a great amount of uncertainties. Suchuncertainties are inevitable in any kind of project due to the very nature of innovationprojects. For organizations facing a low series development, highly costly and complexproduct, 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 sufficientenough. Considering an international project organization, it is not enough only to focus onthe tools and methods used for handling uncertainties.

The findings also show the delicate conflict between the administrative workload and the lackof predictable benefits of a process for handling uncertainties. It is quite clear that a process ofhanding uncertainties must have the ability to show the benefits to motivate an initiallyincreased administrative workload.

The approach with checklists has a positive effect on the handling of uncertainties, but theycannot be extended to cover all possible uncertainties. Therefore, checklists can only be seenas a complimentary check of uncertainties. In the start up of a project, as an active method ofidentifying 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 notanything that contradicts to the validity of these findings considering the case of othercompanies.

This paper also suggests that theories on risk management should be extended to cover alsoorganizational theories, general management theories and the management of major complexprojects. In a more holistic view, this will provide a perspective on how to manage large, low-series, complex, and multinational product development projects.

ICED01-C586/141 615

The organizational structure is believed to influence the outcome of handling uncertainties, bythat including the business-oriented perspective of uncertainty management and the viewpointof a project portfolio.

Risks and opportunities will still, despite all techniques and methods, be an organizational andmanagerial issue and therefore the interaction and the enabling of handling uncertaintieswithin the whole of the product development organization will be crucial.

The Author would like to acknowledge Adtranz for their sponsorship, the ENDREA researchschool and other researchers in the field of Risk Management for their support.

References

[I] Smith Preston G (1999), "Managing Risk as Product Development Schedules Shrink",Research Technology Management, Vol. 42, pp. 25-32.

[2] Porras J.I and Robertson P.J (1992), "Organizational Development: Theory, Practiceand Research". In: Dunette M.D and Hough L.M (eds.) Handbook of Industrial andOrganizational Psychology 2:nd Ed, Vol. 3. Consulting Psychologist press, Palo Alto,CA, USA.

[3] Hartmann George C and Lakatos Andras I (1998), "Assessing technology risk - a casestudy", Research Technology Management, Vol. 41, pp. 32-38.

[4] Cummings Thomas G, "Tranzorganisational Development" (1984). In: Staw B.M andCummings L.L (eds.) Research in organizational behavior, Vol. 6, pp. 367-422. JAIPress Inc. Greenwich, CT, USA.

[5] Sitkin S.B and Pablo A.L (1992), "Reconceptualizing the determinants of riskbehavior", Academy of Management Journal, Vol. 17, pp. 9-38.

[6] Ulrich K.T. and Eppinger S.D (1995), Product Design and Development, MacGraw-Hill: New York, NY, USA.

[7] PMBOK 2000. A guide to the project management body of knowledge, Projectmanagement Institute PMI, Newton Square, PA, USA.

[8] Ward S.C (1999), "Assessing and managing important risks", International Journal ofProject Management, Vol. 17, pp. 331-336.

[9] Kahkonen K (2000), "Balancing Project Risks and Opportunities", Project ManagementInstitute Annual Seminars & Symposium, Houston, Texas, USA, proceedings.

[10] Williams T. M (1995), "A classified bibliography of recent research relating to projectrisk management", European Journal of Operational Research Vol. 85, pp. 18-38.

[II] Adtranz (1999), Business Process model. Internal document, Adtranz, Berlin, Germany.

RolfOlssonDepartment of Machine Design, Royal Institute of Technology, 10044 Stockholm, SwedenPhone: +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 DESIGNICED 01 GLASGOW, AUGUST 21-23, 2001

DECISION-MAKING - HOW TO AVOID DYSFUNCTIONS? HOW TOANALYSE 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 andmanagement

1 Introduction

In connection with the industrial objectives that concerns the optimisation of quality, cost anddelay, we present a dysfunctions study for the decision making processes. Our approach inthis work is to establish a generic representation which considers any company as a networkof actors who can make decisions to reach an objective. A functional analysis of processmodelling 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 thedecision 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 dysfunctionsand 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 particularfocus on the choice of actor and with a presentation of tools developed to improve thatparticular kind of decisions. These tools are gathered under the name SACADO (Choice ofActor and Organisation Decisions Aiding System). In SACADO, a target process is proposedto minimise risks of dysfunctions. This method also provides tools to analyse a givendysfunction in order to find causes and recommendations. Finally, SACADO can help inimproving an organisation by analysing its dysfunctions.

ICED 01 -C586/187 617

2 Some definitions

In a company, projects are the translation of the strategic trends into actions. So as toaccomplish a project, people have to be chosen as responsible for some actions. At thestrategic level of a company, decision-makers have to choose people to be project managersand then, a project manager has to build his project team. On such choices depends the globalsuccess of a project. The "choice of actor" is a decision made by a decision-maker thatconsists in selecting, evaluating and choosing a person to accomplish a action. As we saidbefore, such a choice can be made either at a very high or low level of the company. Anexample 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 adysfunction.

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 meansis 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 otherdecisions and it is difficult to find the beginning or the end."

Mezher [6] describes another aspect of the decision by considering decision as "a processwhich 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 stochasticcessation of an entity's capacity to accomplish a required function. " Boucly [7], According toVillemeur [8], "after a failure identification, the entity is considered out of order. Abreakdown is always due to a failure." By analogy, we consider an actor in a company as anentity whose function is to decide. If the decision-maker is not able to make his decision, thenthere is a dysfunction.

618 ICED 01 - C586/187

Figure 1. Decision Time Line

ICED 01 -C586/187 619

We, therefore, propose the following definition of a dysfunction in a decision process : adysfunction is a stochastic cessation of an actor's capacity to make a decision, toaccomplish an action. If the action expected to be accomplished has not been realised, thenthere is a dysfunction. The gap between the effective result and the negotiated objective to bereached is called the dysfunction value.

3 Two models

Current modelling systems used in a business environment may be characterised as having astatic kernel, and mono-actor, that is, a single user/decision-maker. The quantity ofinformation required for more realistic models involving changing kernels and multiple actorsis large. Nevertheless, such extensions of models are being considered, in particular tomanage product development including social, psychological, customer and softwareperspectives [4].

From another point of view, a great number of product development approaches represent thefirm as a set of components (environment, products, processes and resources) to be co-ordinated.

We propose here two models that we consider to lay the foundations of our approach : theDTL (Decision Time Line), as a decision model, and the target process as a core process thathelps 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 sixmost important steps in any decision process.

The DTL includes the decision process from the request to the answer. This dynamicrepresentation of a decision making process is constructed in concert with the conceptualarchitecture 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 arequest for a decision, followed by a negotiation phase which represents the interaction ofthe primary actor and other actors to establish the request environment (i.e. ground rulesin terms of time, resources, and type of decision required).

If this initial negotiation leads to the request being considered by the primary actor, thenthe request is identified. The identification includes decomposition of the request into sub-requests, when necessary, and the identification of the competencies needed to accomplisheach component.

The synthesis phase deals with problem resolution/decision-making, if the request ishandled directly by the actor, or co-ordination/synthesis if the request has been handled (atleast 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. Eachelementary dysfunction are related to a DTL step, independent from each others and cannot bestudied 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 afunctional 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 ofdecision, choice of actor, and which helps to avoid dysfunctions. But even if the differentsteps are properly followed, risks of dysfunctions still exist, nothing can completly erasethem.

This target process can be used to evaluate the risks and be aware of them. It is a more precisedecomposition of the identification and synthesis phases of the DTL, applied to the choice ofactor.

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 fiveothers.

620 ICED 01 -C586/187

ICED 01 -C586/187 621

Figure 2. The target process as a core process for a decision-maker

4 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 managershave been asked to fulfil a decision card (which has been designed upon the DTL and thetarget process) for dysfunctions that appear in their project. An example of such a card isshown in figure 3. Different kinds of dysfunctions have been studied: past dysfunctions inprojects at completion, and past dysfunctions or potential risk of dysfunction in projects inhand.

Context and quantificationoftaskstoperfom

Steps 2 to 6 ofthe target process

Result analysis,recommendation andcapitalization

Context

Tasks to perform (Quality, Cost, Delay)

Required competencies

Potential actor Chosen actor and Why

Risk evaluation and Action plan

Dysfunction and Gap (Quality, Cost, Delay)

Recommendation

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 aconsequent number of cards, it is possible then to study the general trend for a given companyto cope with dysfunctions.

4.2 How to analyse dysfunctions?

The competencies model is used to analyse the reasons of a dysfunction [2]. As shown infigure 4, a dysfunction in a project may have reasons from different natures either linked tobehavior, 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 beenrecognized competent for a given action (problem of knowing who).

When choosing a project manager, a decision-maker can search for competencies such asdirecting, coaching, supporting, and delegating. The lack of one of these requiredcompetencies could be a source of dysfunction in the decision process. This is a problem ofattitude.

4.3 Predictions and capitalization

The capitalization database provides a means for dysfunction prediction, by capturing thefirm's experience from prior decision-making tasks. Software accessing the capitalizationdatabase and the decision-making model can give an early warning to a decision-maker whenan action or decision-making strategy is likely to lead to a known dysfunction andconsequently a problem in quality, cost, or delay.

The capitalization database can also be used to conduct a statistical study of dysfunctionswithin the firm: What are the risky steps in the decision-making process? What are the mainsources of dysfunctions? What are the main effects?

ICED 01 -C586/187 623

5 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, onlypriority dysfunctions can be taken into account so as to look for their causes and then giverecommendations. It is important to notice that recommendations are context dependent. Evenif it is always possible to give a list of actions to avoid a dysfunction, the pertinence lies in thecapacity to elaborate a strategy of actions more than in the recommendations themselves.

We have so far considered individual decisions and competencies. Neither collectivedecisions nor collective competencies have been taken into account in our approach. It wouldnow be interesting to see how generic our methodology is and if it can be applied to decisionand competencies as far as a group is concerned.

An industrial experience has taken place at VALLOUREC and testified that SACADO couldbe an answer to a real industrial need.

References

[1] Durand, T., L'alchimie de la competence., p.1-38, Paris, 1998.

[2] Stal-Le Cardinal, J., Mekhilef, M., Bocquet, J.-C., A biiective user's profile orientedmodel for design action capitalization.. Third Biennal World Conference on IntegratedDesign and Process Technology, Berlin, Germany, Vol.3, p.48-55, 1998.

[3] Rees, R., Wtiat is a failure?, IEEE - Transactions on Reliability, Woodinville, USA,Vol.46, p.163, 1997.

[4] Ullman, D.G., D'Ambrosio, B., A taxonomy for classifying engineering decisionproblems and support systems.. Design Engineering Technical Conferences ASME,Corvalis, Oregon, USA, Vol.2, p.627-637, 1995.

[5] Sfez, L., Critique de la decision.. Presses de la fondation nationale des sciencespolitiques, Paris, 1992.

[6] Mezher, T., Abdul-Malak, M.A., & Maarouf, B., Embedding Critics in Decision-Making Environnements to Reduce Human Errors. Knowledge-Based Systems., n°ll ,pp. 229-237, 1998.

[7] Boucly, F., Maintenance : couts de la non-efficacite des equipements. AFNOR gestion,Paris, 1998.

[8] Villemeur, A., Surete de fonctionnement des systemes industriels, fiabilite, facteurshumains, informatisation. Paris, 1988.

[9] Project Management Institute Standards Committee. A Guide to the ProjectManagement Body of Knowledge. Upper Darby, Pa. : Project Management Institute,1996.

Julie Stal - Le CardinalEcole Centrale Paris, Laboratoire Productique Logistique, Grande voie des vignes, 92295Chatenay 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

Figure 1. The graph above qualitatively depicts the normal communication interactions under NASA's currentpractice 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

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGNICED 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

1 Abstract

Given the challenge by NASA Administrator Daniel Goldin to develop and embrace DesignFor Safety practices, tools and methodologies, this paper details an approach to be taken byresearchers at Stanford's Center for Design Research and the Learning Lab in meeting thischallenge. The recent disappointments of the Mars Climate Orbiter and the Mars PolarLander have given rise to this challenge along with NASA's continued focus on missionsafety and effectiveness. One of the issues highlighted by Administrator Goldin at the 15thAnnual NASA Continual Improvement and Reinvention Conference this year were problemswith proper knowledge transfer between designers, operators, and risk managers. Withincurrent mission development practices, risk managers, operators, and designers come togetherduring rare program reviews. As a result of these integrated meetings, several action itemsare taken by all stakeholders that require additional efforts with impacts on cost, schedule, andperformance while mitigating risk and ensuring safety. The figure below depicts the activitiesof stakeholders during a mission development under the current environment of limitedknowledge exchange. In the following, a brief overview of NASA's Design for SafetyInitiative will be given. Additionally a survey of NASA's current practice of Continuous RiskManagement (CRM) will be made. Once NASA's development environment and practiceshave been defined, problem areas in NASA's current methods will be outlined. Finally theproposed design for a risk management decision aid will be detailed that will assist inreducing the program risk signature. A program's risk signature is an indication of the levelof risk in cost, schedule, and performance.

2 Design for Safety Initiative

Recent catastrophic failures of some highly visible NASA missions spurred NASA to performa top-down review of all system development practices. In each mission area three problemareas kept surfacing. To address these significant issues, NASA started the Design For SafetyInitiative. Three emerging technology areas have been focused on as sources for potentialsolutions.

Problem AreasPoor System Risk and Multi-objective Trade-off AnalysisRigid and nonadaptive systems

Knowledge Engineering

Solution AreasPoor knowledge management

Intelligent System RiskManagementTechnologies for resilient systems

Table 1. NASA has identified three problem areas that contribute significantly to recent mission failures. Aspart 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 withinthe domain of the first two problems and their corresponding recommended solutions.Improving Knowledge transfer between designers, operators, and risk managers will relyheavily on knowledge engineering practices to capture contextual information on eachstakeholder's efforts. Additionally, the use of Intelligent System Risk Management will makeuse of this contextual database to support rapid and superior risk assessment and riskmitigation.

2.1 Barriers to the DPS initiative and other Risk Management process

Members of the European Space Agency identify several barriers to effective implementationof Risk Management. The most common barriers are listed as follows: Technical arroganceand individualism of the engineering staff, information ownership linked to personal power,lack of proper understanding of the advantages of Risk Management, Shoot the messengerProgram Manager approach, and the inclination of Program Managers to believe that theyhave always been doing Risk Management. [3] The Design For Safety Initiative will have tocontend with all these barriers to implementation. Based on the various risk managementprograms 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 overcomeall of these barriers to risk management implementation.

3 Current Risk Management Techniques at NASA

NASA Program Guidance 7120.5A, "NASA Program and Progress Management Processesand Requirements" states "The program or project manager shall apply risk managementprinciples."[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 Documentconnects all steps. [11] This process comes directly from the Software Engineering Institute'srisk 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 involvesdeveloping a risk statement and the context/rationale in which it exists. Analysing the riskcalls for the stakeholder to determine the impact to the program, the probability of thisoccurring, the timeframe in which the risk is required to be mitigated, a classification of therisk, 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 riskmitigation plan focused on eliminating the risk before it occurs rather than increasing systemrobustness to survive the risk occurrence. In the next step those responsible track the riskstatus in case the perceived risk situation arise. The final step determines how to mitigate therisk, usually implementing the existing pre-defined risk mitigation plan. Key to all these stepsis effective communication and documentation of risks. Gerosa of the Alenia AerospazioSpace Division describes the typical risk factors that exist in space programs as: Technology;Requirements; Manufacturing; Verification, integration, and test; Development status; Teamexperience and availability; Planning; Subcontractor/Supplier; Customer/Contractual/Legal;and Financial. [5] CRM relies on the vigilance of the Program Manager to ensure these riskfactors are addressed during mission development and execution.

As part of their system level risk management training in CRM, the SATC has published asample risk management plan for a fictional project meant to be the example of how toaccomplish risk management within a project. This "Project Zeus" risk management planapplies the five-step CRM process as well as details the risk management responsibilities ofall development stakeholders. [2] The plan describes several personnel intensive methods ofrisk identification ranging from formalised questioning designed to expose risk and designteam brainstorming. Members of the Integrate Product Teams (IPT), the IPT lead, and theSystems 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 theteam lead or Project Manager's responsibility to either develop the risk mitigation plan orpass the responsibility to another organisation. Tracking of the risk status is done by theowner of the risk and communicated to the Project Manager (PM) during weekly or monthlymeetings. Decisions are made by the PM to control the risks during weekly and monthlymeetings. "Project Zeus" relies on weekly project, IPT, and monthly project meetings tocommunicate risks and their status. Formalised project documentation is used to documentrisk information.

"Project Zeus" and other real NASA missions suffer from the lack of continuous interactionillustrated in Figure one. Project stakeholders continuously make decisions that affect the risksignature of the development program. Weekly and monthly risk updates place thestakeholders in a constant state of reacting to risk information instead of proactivelyaddressing potential risk situations as they evolve. The entire risk management processcreates significant additional responsibilities for all the project stakeholders. The increase informal program documentation, specifically for risk along with the normal documentauthoring, approval, and publishing cycles, not only contributes to the growth in the workloadof 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 tobe taken at various time intervals. The additional duties placed on project personnel moverisk 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 ofall program stakeholders. Key to the success of any NASA mission are the efforts of theoperators. Unfortunately the only time operators as asked to consider the risks are duringIntegrated Product Team meetings. The operational community typically has the greatestinsight to the impact and probability of various risk events occurring.

ICED 01 -C586/470 627

Figure 2. The above graph represents how risk Management Decision Tool would not only drastically improvein 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

Automated Requirements Measurement Tool (ARM) is a software development managementtool developed by SATC for providing NASA project managers metrics regardingrequirement specification documents. [7] ARM searches documents for various significantphrases, developing metrics for lines of text, imperative phrases, continuances, weaklyworded phrases, directive phrases, options, unique subjects, and readability statistics. Byanalysing these metrics, requirements with the greater risk potential are highlighted for furtherreview. While valid for software specifications, the tool has not yet been expanded to coverthe domains required for a system level implementation.

In five Israeli companies known as leaders in risk management, an assessment of the validityof risk management tools was performed. [10] The study categorised the tools into five groupsbased on the SEI risk management process with and an additional category for tools thatprovide background information in support of a stable risk management environment. Thebackground group of tools received the highest usage rates. The tools in this category supportvarious portions of the entire risk management process. This result indicates that riskmanagement practices are highly coupled with other management practices. Top five riskmanagement tools used by these companies were Simulation (Background), Responsibilityassignment (Planning), Risk impact assessment (Analysis), Configuration control(Background), and Subcontractor management (Background). Responsibility assignment andSubcontractor management both focus on identifying an owner of the risk. Risk impactassessment 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 predictivetool. Configuration-control functions as a risk mitigator by controlling the program baselineand managing changes to critical system components. The most used risk management toolswere the tools that assisted in all phases of risk management and even relevance to othermanagement practices associated with the execution of a successful project.

4 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 improveNASA's in-process risk identification and communication challenges.

4.1 System Architecture

The Risk Management Decision Aid will consist of six components. These includeKnowledge 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 requireinterface to others. Each will be implemented to make maximum use of legacy software and knowledge-basewhile 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 areRECALL-derived program knowledge capture systems dispersed through the stakeholders'activity areas, programmatic email archives, and databases of formal programmaticdocumentation.

RECALL is a design-knowledge capture tool developed by researchers at Stanford Universityto 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 organisedaccording to sketch activity. Traditional design capture tools capture only audio and video.These legacy systems required tremendous amounts of post processing to make the datauseful for reuse. RECALL indexes the design context information with thumbnails of thesketch activity. As the sketches are easily recognised for their efforts, this allows users of thisdata to quickly locate which contextual data is needed for review. To meet the needs of theDFS initiative, modified RECALL systems will be peppered throughout stakeholder commonteam areas. These systems will be located where project personnel normally congregate todiscuss the project and make decisions that affect the program risk signature. To integrate theuse of the system into the program's normal work habits, the cognitive overhead required tomake use of these RECALL stations will be minimal. Each system will be connected to theDesign Communication database for archival and processing purposes.

The Programmatic Email Archives are simple storage databases of project related emailcommunication. The emails contain not only important design and decision historycommunication, but also contain real-time information of actions impacting program risk. Itis envisioned that both the Risk Identification Expert System and the Risk Evaluation ExpertSystem will use this information. Formal Programmatic Documentation such as requirements

ICED 01 -C586/470 629

documents, design specifications, and operating instructions, contain valuable informationregarding the program baseline. These documents will be stored in the DesignCommunication 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 DesignCommunication Knowledge-Base, the Project Structure Database, the Risk Assessment andAnalysis Knowledge-Base. The Design Communication Knowledge-Base is the mainrepository of project specific knowledge. Captured via the Knowledge Acquisition System,this database contains real-time information about decisions and discourse regarding theprogram, a time-history evolution of programmatic information, and current program baselinewith respect to both the design and the risk. The Project Structure Database containsinformation regarding the organisation of the program. This includes information such asprogram organisation chart, IPT members, and contact information. One of the critical piecesof information in this database is a risk profile for each of the program personnel. This riskprofile contains information regarding which program elements the author is involved withand a catalogue of past risk related experience. This risk profiling is essential for the RiskIdentification Expert System to be able to perform its tasks of integrating several disparatepieces of information in order to assist in identifying potential risk events. The RiskAssessment and Analysis Knowledge-Base contains both the current state of the system riskand the information required to assist the expert systems in aiding stakeholders in their effortsto identify and evaluate risk. Based on lessons-learned and other institutional riskinformation, 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 reducethe system risk. The two systems are the Risk Identification Expert System and the RiskEvaluation Expert System. Traditionally Decision Support Systems and Expert Systems havefocused on assisting individuals in their decision-making processes. Druzdzel comments thatexperts, though capable of better decisions than novices, are still susceptible to the samejudgmental biases as novices. He gives an example where the ability of psychiatrists todiagnose future violent behaviour in patients was compared to the ability of a simple linearDSS 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 supportasynchronous decision support among several group members. [6] The RDMA will haveelements of a Group Decision Support System due to the complexity of NASA programs, themany risk factors to be considered, and the number of stakeholders involved. According toDruzdzel and Flynn, Descriptive systems are based on human intuitive reasoning andNormative systems have their foundations in decision theory, probability theory, and decisionanalysis. [4] It is critical that the RMDA be based on normative methods to avoid the biasesof human reasoning, specifically as it relates to NASA missions. This assists in overcomingsome of the barriers to effective risk management such as technical arrogance and thepropensity of program managers to rely only on past risk abatement experience. Pal andPalmer advocate a hybrid case-based / rules-based DSS structure to take advantage of thebenefits of both DSS development methods. [9] Case-based systems involve making use ofpast experiences to determine the recommended course of action. Rules-based systemsrepresent domain knowledge in the IF - THEN format. The use of Case-based systems allowfor exceptions to the more rigidly structured Rules-based architecture. The flexibility toconsider 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 tosend probes to Mars, while specific experiments rely on domain specific knowledge of limitedusefulness beyond the mission timeline.

The Risk Identification Expert System (RIES) assists stakeholders in identifying potential riskevents. By making use of the Design Communication Knowledge-Base, the Risk Assessmentand Analysis Knowledge-Base, and the Project Structure Database, the RIES determinespotential risk events and notifies the stakeholders with responsibility for that risk area. Thedata captured from the RECALL-based program information capture systems is sifted for riskidentifiers, similar to the operation of the ARM tool. The archive of programmatic emails isutilised in a similar matter. The RAAKB is used to assess the current risk signature andperform a preliminary assessment of impact, probability, and timeframe for initial delivery tothe 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 programpersonnel involved, rather than waiting for weekly, monthly, or quarterly meetings to surfacethese potential risk events. Additionally, the RIES will allow for shared notification ofpotential 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 toevaluate the risk event, suggest potential risk mitigation activities or concepts for increasingsystem robustness, and update the current risk status of the program. Through the use of anormative, hybrid case-based/rule-based group DSS, each stakeholder makes their assessmentand evaluation of the risk events alerted by the RIES and other means. As the REES is aGroup DSS, tools will be in place to assist the various stakeholders to come to a consensus onthe risk impact, probability, timeframe, and priority. Additionally the REES will be theinterface by which stakeholders view the current program wide risk status as maintained bythe 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 normalworkings as these new capabilities are brought on-line. During the initial set-up of RMDAthere will be some significant resource impacts with respect to infrastructure changes andtraining on the system. Once up and running, the impacts to organization and individualefforts would be minimized. The RMDA is designed to mesh into the normal working habitsof program stakeholders. The only significant impact to day-to-day efforts is the increasedawareness of potential risk events and the corresponding response to that knowledge. Thisextra 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 signatureson NASA programs over $10 million. In smaller programs the cost of implementation wouldoutweigh the programmatic benefits gained from RMDA. For NASA the cost of RMDA ismuch less than the economical and political losses associated with a $70 million missionfailure. Beyond NASA's Risk Management needs, the RMDA could reduce the risk signatureof projects in several other domains. There are benefits to the development of DefenseSystems, specifically with respect reducing both development risk and operational risk. Asautomobiles become more complex, a tool like RMDA would assist the Automobile industryin flagging risk adverse activity during development. Consumer Product Development,typically at a smaller scale than NASA programs, would also benefit from RMDA, especiallyif the development stakeholders are distributed geographically. Many industries wouldbenefit from the risk signature reduction afforded through the adoption and use of RMDA.

ICED 01 -C586/470 631

5 Conclusion

The Risk Management Decision Aid consists of capture tools, knowledge-bases, and decisionsupport systems designed to support NASA. NASA's current risk management programs donot involve all stakeholders, and allow for only sporadic risk communication. Additionallythey are hampered by a focus on subsystem risk management rather than a system levelapproach. Current practices do not significantly reduce the risk signature of NASA missionsenough to avoid catastrophic failures. The RDMA will improve the risk signature through theuse of the knowledge capture technology; knowledge-base engineering; and Normative,Group Decision Support Systems. By decreasing the time between risk informationcommunication and assisting in rapidly assessing the risk, stakeholders can either mitigate therisk or increase system robustness. The RDMA will ultimately provide NASA the means toaccomplish more economical, safe, and effective missions for space exploration.

References

[1] http://dfs.nasa.gov NASA's Design For Safety Website

[2] http://satc.gsfc.nasa.gov/crm/ NASA's Website for Continuous Risk Management

[3] Chacuat, J. "Risk Management a Tool Embedded in Project Management." EuropeanSpace Agency 1st Risk Management Workshop. 1998.

[4] Druzdzel, M. and Flynn, R. "Decision Support Systems," Encyclopaedia of Library andInformation Science, Kent, A. (editor), New York: Marcel Dekker, Inc., 2000.

[5] Gerosa, S. et al, "Methods and Applications of Risk Management in Space Programs,"Proceedings of the 30th Annual Project Management Institute 1999 Seminars andSymposium. Philadelphia, Pennsylvania, USA, October 1999.

[6] Hafner, A. "Group Decision Support Systems, Executive Team-Management Tools forthe Military." Program Manager, January - February 1994.

[7] Hammer, T. et al, "Requirement Metrics for Risk Identification," Dec 96, last accessed23 Jan 01 from http://satc.gsfc.nasa.gov/support/SEW_DEC96/sel.html

[8] NASA Program Guidance 7120.5A, "NASA Program and Progress ManagementProcesses and Requirements", April 1998.

[9] Pal, K. Palmer, O., "A decision-support system for business acquisitions," Journal ofDecision Support Systems, Vol 27, pp. 411-429, 2000.

[10] Raz, T., and Michael, E., "Benchmarking the Use of Project Risk Management Tools,"Proceedings of the 30th Annual Project Management Institute 1999 Seminars andSymposium. Philadelphia, Pennsylvania, USA, October 1999.

II1] Rosenberg, L. et al, "Continuous Risk Management at NASA," Proceedings of AppliedSoftware Measurement / Software Management Conference, Feb 1999, San Jose,California, USA.

[12] Yen, S., Fruchter, R., Leifer, L., "Facilitating Tacit Knowledge Capture and Reuse inConceptual Design Activities," ASME DTM Conference, Sep 1999.

Capt John M. Feland IIIHQUSAFA/DFEM, Suite 6H2, 2354 Fairchild Drive, Colorado Springs, CO 80840, USATel: 719-964-8058, Fax: 719-333-2944, Email: gohogs@cdr.stanford.edu

©IMechE2001

632 ICED 01 -C586/470

Authors' Index

AAgogino, AM 19-26Ahmed, S 75-82Aldanondo, M 131-138Andrade, R 299-304Aoussat, A 361-368

B

Badke-Schaub, P 251-258, 457^164Barr, G 497-504Basson, A H 385-392Bell, D G 243-250Bender, B 313-320Bender, B 313-320Bermell-Garcia, P 99-106Bjarnemo, R 377-384Blanco, E 11-18Blessing, LTM 313-320Bocquet, J-C 269-276, 617-624Borg, J 219-226Bramklev, C 377-384Brannstrom, O 305-312Brookes, N J 433^40Buijs, J 353-360Burgess, S C 497-504Burvill, C 277-284Busby, J S 601-608Butter, D 99-106

CCaillaud, E 131-138Carrillo, A G 481^88Carrizosa, K 465^72Chakrabarti, A 3-10Chung, PWH 601-608Clarkson, P J 43-50, 321-328, 345-352,

497-504,577-584Coates, G 393-00Grassland, R 585-592Culley, S J 83-90, 179-186

DDarlington, M J 83-90Das, B P 601-608de Medina, HV 449-156de Pennington, A 409-416Deasley, P J 417-24Donaldson, KM 505-512

Dong, A 19-26Duffy, A H B 123-130, 155-162,

163-170, 195-202, 227-234393^100, 537-544, 561-568

E

Eckert, C M 43-50, 321-328, 441–48,473–80,577-584

Elstrom, B-O 305-312Eris, 0 171-178

F

Fagerstrom, B 329-336Fan, I-S 99-106Farrell, J 123-130Feland, J M 625-632Feldmann, D G 59-66Frank, C 285-292Frankenberger, E 115-122Freisleben, D 553-560Fuxin, F 369-376

GGardoni, M 11-18, 285-292Girard, P 67-74Grante, C 513-520Gullander, S 401–08Gwyn, B 123-130

HHadj Hamou, K 131-138Haffey, M K D 561-568Hansen, P K 171-178Hibberd, R E 601-608Hills, W 393-00Howell, L L 521-528Hughes, E J 601-608Hughes, P 277-284Hughes, R 277-284

I

Ivashkov, M Y 139-146

J

Johannesson, H 329-336Jonson, G 377-384

633

KKennel, T 425–32Konovessis, D 593-600Krus, P 513-520Kunz, A M 425–32

L

Lamothe, J 131-138Langdon, P M 3-10, 107-114Larsen, J B 521-528Lauche, K 187-194, 425-432Lee, B S 163-170Lehtonen, T A 293-298Leifer, LJ 243-250Leifer, L 171-178, 211-218, 465-72Lattice, F 433-440Lewis, W 147-154Li, G 99-106Liang, T 243-250Lim, S 163-170Lindley, M W 545-552Link, P 529-536Lloyd, T 211-218Lockledge, J C 27-34Lowe, A 179-186

MMabogunje, A 171-178, 465-172Magleby, S P 521-528Malvisalo, J M 293-298Marie, F 269-276Matthews, PC 107-114Mbiti, K 425-32McDonald,: 123-130McKay, A 409^16McMahon, C A 179-186, 585-592Mekhilef, M 617-624Melo, A F 321-328, 345-352Menand, S 35^2Merlo, C 67-74Millet, D 361-368Miiller, S 425^132Murakami,T 51-58Muranami, M 545-552

NNakajima, N 51-58Naveiro, R M 449-56Norling, P 401-408

oO'Donnell, FJ 537-544Oestvik, 1 593-600Ohrvall-Ronnback, A 401-408Olsson, R 609-616

P

Palmberg, J-O 513-520Payne, K H 417-424Pilemalm, J 261-268, 401-408Pons, D 569-576Porter, R 99-106Potter, S 83-90

R

Raine, J K 569-576Rehman, F 219-226Riitahuhta, A O 293-298Rodgers, P A 203-210

SSalustri, FA 27-34Samuel, A 147-154Schabacker, M 553-560Schmidt,J 59-66Schueller, A 385-392Schwankl, L 235-242Shah, T 179-186Sheppard, S D 505-512Sheppard, S 465-472Shimamura, J 51-58Simons, C 577-584Sims Williams, J H 497-504, 585-592Smart, P 433-440Smith, J S 195-202, 227-234Song, S 19-26Spiroudis, S 529-536Stacey, M K 43-50, 441-448, 473-480Stal-le Cardinal, J 617-624Stempfle, J 251-258, 457-464Stoeltzlen, N 361-368Strachan, S 123-130Suistoranta, S 337-344

T

Thoben, K-D 91-98Thompson, G 305-312Thomson, G A 489-496Tollenaere, M 35-42

uUllman, D G 545-552

VVajna, S 553-560Valkenburg, R 353-360van Overveld, C W A M 139-146Vassalos,D 593-600Verbeck, A 187-194

WWallace, KM 75-82, 107-114Wallmeier, S 251-258Weber, F 91-98

Weir, J 147-154West, G 123-130Whitfield, R 1 393-400Whybrew, K 569-576Williander, M 513-520Wu, J-L 19-26Wu, Z 155-162Wunram, M 91-98

YYan, X-T 219-226

Z

Zika-Viktorsson, A 261-268