Design Management: Process and Information Issues (Iced) (Issues v)

... tags. The determination of the assigned set for the 390 ICED'99 documents was carried out manually by the authors of this paper by making judgements as to the relevance of documents against the conference themes. Papers were assessed as either relevant or not-relevant to each of the various themes and hence were associated with any number of multiple themes. The results for each of the nine themes were then combined into a single average figure for each document zone. Whilst the classification performance for each of the themes can vary considerably, the average plots provide a means of isolating the effect of zoning.

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

182

ICED 01 - C586/433

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

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

5

Analysis of the ICED'0l abstracts

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

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

ICED 01 - C586/433

183

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

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

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

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

184

ICED 01 - C586/433

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

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

6

Conclusions

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

ICED 01 - C586/433

185

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

7

Acknowledgements

Part of this work was carried out under the IDEA project which is funded by the UK EPSRC (grant number GR/L90170). The authors would like to thank this project's industrial sponsors (Airbus UK, CSC and TRW Aeronautical Systems) for their assistance. References [1]

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

186

ICED 01 - C586/433

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

ANALYSIS AND CLASSIFICATION METHODOLOGY FOR OBJECTIFICATIONS IN COLLECTIVE DESIGN PROCESSES A Verbeck and K Lauche

Keywords: Information design; empirical study

1

analysis, classification

and retrieval: taxonomies;

co-operative

Introduction

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

2

Importance of objectifications for the R&D process

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

1CED 01 - C586/456

187

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

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

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

documented general practices (e.g. principal solutions for design problems, user hints, heuristic rules), reference books (e.g. catalogues), tools and facilities (e.g. software tools).

188

ICED 01 -C586/456

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

3.1 Overview The tool consists of five parts: formal features, localisation in the process, individual function, team function and organisational aspects of knowledge management and cost-benefit ratio. Aspect

Criteria

1. Formal features

content and people involved type (slide, sketch, physical model, software) features (colour, 2/3D, manual / CAD) formal notes like date, initials , index

2. Localisation in process

For the lifecycle of the project: initiation, pre-selection, conception and planning, realisation, introduction, commercialisation

Source

Systems Engineering

for the cognitive problem solving process: situation analysis, goal setting, forming of concepts, choice of concepts, evaluation, decision 3. Individual function -

1CED 01 - C586/456

analysis storage evaluation solution finding communication documentation internal exercise legal requirement

Hacker, Sachse, Schroda [2] Pache. Romer, Lindemann, Hacker [3]

189

4. Team function

generation usage effort needed further development maintenance by cither one / two / several or / all members with cither the same or different disciplinary background from either the same or different departments

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

-

5. Organisation

Knowledge management function: transparency, acquisition, sharing, development, use, storage of knowledge

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

Retrieval individual, collective store, effort and restrictions of access Usefulness Information contained, problem specific, solution oriented, iterations needed, cost-benefit ratio, readability to others, generalisations to other problems Table 1. Sections and criteria for the classification tool

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

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

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

190

ICED 01 - C586/456

!

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

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

1CED01-C586/456

191

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

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

4

Example

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

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

192

ICED01-C586/456

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

5

Conclusions

We suggested a research methodology that can be applied not only to the individual sketching and modelling, but also to objectifications made and used by a group of designers. The classification draws also on the readiness for knowledge management systems. The tool proofed helpful to access to the history of former developments that we analysed for critical success factor in the upcoming project. It also provided a token to start an interview in a comfortable atmosphere as some designers feel more at ease to show an object than to give a verbal description of their work. However, the tool cannot be applied for pure document analysis as not all information requested is static and readable from the document or object itself. A detailed instruction makes the tool available for academic research as well as for knowledge management assessment in industry. The pilot use in social science education suggests that the analysis of objectifications is a promising method for empirical research not only in design studies. However, we believe most benefit is achieved when interdisciplinary research teams share their research methods and their understanding of artefacts. The tool is intended to turn our experience into codified knowledge for the design research community. References [1]

Leont'ev, A.N., Activity, Consciousness, and Personality, Englewood Cliffs: PrenticeHall, 1978.

[2]

Hacker, W, Sachse, P. & Schroda, F., Design Thinking - possible ways to successful solutions in product development, In: Birkhofer, H. Badke-Schaub, P. & Frankenberger E. (eds.), Designers - The Key to Successful Product Development. London: Springer, 1998.

[3]

Pache, M., Romer, A., Lindemann, U., Hacker, W., Mechanismen und Strategien beim Einsatz von Handskizzen in friihen Konstruktionsphasen. Kongress der DGPs. Jena 2000.

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 Common Objedifications in Advanced Manufacturing Systems, Proc. of TEA'97. p. 283-285, 1997.

[6]

Lauche, K., Ehbets Muller, R. & Grote, G., Collective Conceptualisation in Early Phases of Innovation Processes. Proc.of Design 2000. Dubrbvnik, 119-124, 2000.

[7]

Konda, S., Monarch, I., Sargent, P. & Subrahmanian, E., Shared Memory in Design: a Unifying Theme for Research and Practice, Research in Engineering Design, 4, 1992, p. 23-42

[8]

Reich, Y., Konda, S., Subrahmanian, E., Cunningham, D., Dutoit, A., Patrick, R., Thomas, M., Westerberg, A.W. and the n-dim group, Building Agility for Design Information Systems. Research in Engineering Design. 11, 1999, p. 67-83.

[9]

Probst, G., Raub, S. & Romhardt, K., Managing Knowledge. West Sussex: Wiley, 1999.

[10] Verbeck, A., Lauche, K. & Weber, W.G., Objectifications and sociotechnical features supporting integrated R&D teams to cooperate, Proc. of ICED 99. p. 217-222, 1999. Dr. Kristina Lauche Department of Psychology University of Aberdeen Aberdeen AB 24 2UB Scotland UK Tel. +44(0)1224272280 Fax +44 (0) 1224 273211 k. [email protected] .uk

Dr. Alexander Verbeck ESEC S A Hinterbergstrasse 32 CH-63 3 0 Cham Switzerland Tel. +41-41-7495111 Fax +41-41-749 52 50 Alexander. Verbeck@esec. com

©IMechE2001

194

ICED01-C586/456

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

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

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

1

Introduction

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

2

Modular Design and Re-use

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

ICED01-C586/046

195

3

Supporting 'Design for Re-use'

There is a current drive towards modular structuring of products, motivated by the body of evidence as to its benefits. Despite significant correlations between the two, currently no modular design methodology specifically emphasises support for 're-use'. In the 're-use' field studies have shown 'design for re-use" can have a significant impact on the realisation of 'reuse' related benefits [6], Since it suffers from the most notable lack of support, of all the reuse processes [7], the potential for a modular design methodology/tool to support this process is examined. Modular Design in support of 'design for re-use' would be better facilitated by: •

Supporting the dynamic knowledge generated by the designer within the designer's different viewpoint requirements, as the design proceeds from the abstract to the concrete, and mapping knowledge relations between these for improved design understanding.

•

Supporting module generation based on various viewpoint and/or lifecycle objectives and facilitating a mapping between each to optimise module definition and design.

•

Supporting the re-use of generated modules and their associated knowledge through the provision of an explicit formalism for design knowledge, dependency knowledge and module definitions.

•

Facilitating the exploration of 'design by re-use' by mapping potential design changes/decisions onto the previous modular solution and its associated development knowledge.

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

196

ICED 01 -C586/046

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

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

4

A Modular Design Methodology for Re-use

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

ICED01-C586/046

197

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

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

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

Relation (type, direction) Figure 2 (a) - Concepts, attribute and constraints

198

(b) Relations between concepts

ICED01-C586/046

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

Figure 3 - An Interdependency Matrix Application

4.1.3 Element 3 - The Clustering Mechanism Various clustering and grouping techniques are currently under investigation to support the module design and optimisation process. The techniques are required to support module design based on a number of criteria, including: • Maximisation of internal relations between concepts. •

Minimisation of external relations between concepts.

•

Concept, attribute and relation constraints.

•

Significant lifecycle objectives i.e. manufacturing, maintenance, technology life-spans etc.

•

Maximum and minimum module number and size.

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

ICED 01 -C586/046

199

Figure 4 - Mapping Mechanism

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

Figure 5 - Envisaged Methodology Application Process

200

ICED01-C586/046

4.3 The Application Field The methodology is currently under development in the field of marine design in conjunction with BAE Systems Marine Ltd (Forward Design Group) and Alenia Marconi Systems. The marine field was chosen based on the findings of a previous study in the area which highlighted a significant correlation between support for the process of 'design for re-use' and the achievement of 're-use' related benefits [6], More specifically, we focus on the potential modularisation of the engineering (hardware) design of a weapons systems command console. The console was chosen for a number of reasons including: •

New Generation Console Development: The console is currently undergoing a significant redesign which results in easier access to documentation on previous generation consoles, and the ability to analyse the results of the methodology's application against both the new console design solution and the process undertaken to achieve it.

•

Sufficient Complexity: The console's requirement to integrate a number of differing functions, mechanisms and technologies is expected to result in the development of a more robust methodology.

•

Embodiment of Ship Design Issues: The console must take into account a number of ship design issues, including: Ship Class Maintenance, which requires that all previously designed ships in that class must be of similar outfitting to ensure adequate integration of all ship systems. As the design and manufacture of a naval ship class can span decades this is an especially pertinent issue in the design of a console which embodies technologies subject to rapid development (processors, video, VDU's, control mechanisms, etc). System Integration, which requires that elements of individual ship systems (propulsion, waste water, navigation, communications) must be designed to not only integrate within the individual system to which they belong but the ship as an entire system. Long in Service Life Span, which requires specific emphasis on both the robustness of components and the minimisation of retrofit requirements of individual ship systems. Thus, these issues provide a case with significant life-cycle objectives on which to base the development and analysis of the methodology.

5

Conclusion

The correlation between the principles of modular design and the requirements of 'design for re-use' has been presented. The main issues that attribute to the inadequacy of current modular design approaches in supporting this process have been highlighted and discussed. To address these issues a 'modular design methodology for re-use' has been presented that is currently being developed in a bid to provide better support for the relatively neglected process of 'design for re-use'. References [1]

Sosale, S., Hashiemian, M., and Gu, P., "Product Modularisation for Re-use and Recycling", ASME, Design Engineering Division, DE, Vol.94, pi95-206, 1997

ICED01-C586/046

201

[2]

Miller, T.D., "Modular Engineering of Production Plants", International Conference on Engineering 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", International Journal of Production Economics, Vol. 60, p!45-153, 1999.

[5]

Huang, C.C. and Kusiak, A., "Modularity in Design of Products and Systems", IEEE Transactions on Systems, Man and Cybernetics - PartA: Systems and Humans, Vol.28 No. 1, January, pp 66-77, 1998.

[6]

Duffy, A.H.B., and Ferns, A.F., "An Analysis of Design Reuse Benefits," in Proceedings of the International Conference on Engineering Design, Munich, 1999.

[7]

Smith, J.S., and Duffy, A.H.B., "Product Structuring for Design Re-use", Proceedings of the 5th WDK Workshop on Product Structuring, February 7-8, Tampere University of Technology, Tampere, 2000

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

Construction", Power

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

202

ICED01-C586/046

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

CAPTURING AND CLASSIFYING INFORMATION IN UNDERGRADUATE DESIGN TEAM PROJECTS P A Rodgers Keywords: Design rationale, design education, student design teams, information analysis, classification and retrieval.

1

Introduction

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

2

Design Rationale Methods

Design rationale generally includes not only the reasons behind a design decision but also the justification for it, the alternatives considered, and the argumentation leading to decisions made. However, as Shipman and McCall [3] point out, design rationale can be viewed in three different ways: •

Communication: capturing and retrieving naturally occurring communication (e.g. design discourse) among members of a design team. The recording of design communication is not meant to have any effect on the design process.

•

Documentation: the documentation of information about design decision making, including what decisions are made, when they are made, who made them, and why.

•

Argumentation: the reasoning that designers use in framing and solving problems. This includes both the reasoning of the individual designer and the discourse among team members in a design project.

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

ICED 01 -C586/118

203

design rationale is the Issue-Based Information System (IBIS) framework for argumentation proposed by Rittel et al. [5, 6]. This approach to design rationale is based loosely around four organisational atoms, namely: •

Issues: topics that must be resolved before a design specification can be generated;

•

Positions: may be solutions or methods for resolving issues;

•

Arguments: ideas that either support or refute a position;

•

References: documents cited in support of arguments.

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

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

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

3

Capturing and Indexing Design Rationale: A Case Study

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

204

ICED 01 -C586/118

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

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

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

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

ICED01-C586/118

205

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

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

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

Figure 4. Initial Secure Bicycle Parking System Issues

206

ICED01-C586/118

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

Figure 5. Secure Bike Parking System Positions Examples

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

3.4 Bicycle Parking System Arguments Arguments against the position illustrated at the extreme right of Figure 5 included: •

"kids would not be able to push their bikes up the ramp" (Isla);

•

"the gap underneath may inadvertently act as a trap for children" (Alexis)',

•

"BMX-style bikes would not be accommodated in the ramp concept as it stands" (Giari);

•

"the height of the ramp sides may be problematic for some bicycle gear mechanisms" (Aaron);

•

"there may be difficulties actually locking the bikes to the ramp system" (Gian);

•

"access to lock and unlock bikes near the middle of the ramp configuration may be difficult" (Ma).

ICED01-C586/118

207

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

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

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

4

Conclusions and Results

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

208

ICED01-C586/118

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

5

Acknowledgements

The author would like to thank everybody at Penicuik High School who were involved in this project. In particular Paul Beards, the head of the Design and Technology department, for his co-operation and support. The author would also like to acknowledge the dedication and diligence of the 2nd year BDes Interdisciplinary Design students throughout this very fulfilling collaborative project. References [1]

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, The Netherlands, 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 the Artifact", 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 Paper 131. 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 Second Generations", Bedriftsokonomen. 8, 1972, pp. 390-396

[7]

Cao, Q. and Protzen, J.P., "Managing Design Information: Issue-Based Information Systems 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. Rodgers School of Design and Media Arts, Department of Design, Napier University, Merchiston, 10 Colinton Road, Edinburgh EH 10 5DT, Scotland, UK. Tel: +44 (0)131 455 2678, Fax: +44 (0)131 455 2292, Email: [email protected], URL: http://www.napier.ac.uk/depts/design/home.htm

©IMechE2001

210

ICED 01 -C586/118

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

INCORPORATING INCENTIVES INTO DESIGN DOCUMENTATION TOOLS T Lloyd and L Leifer Keywords: Motivation, incentives, documentation tool, survey.

I

Introduction

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

1CED01-C586/472

211

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

2

Methodology

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

212

1CED01-C586/472

The survey was self-administered and contained five core questions and a set of background design experience questions. Figure 1 shows the five core questions stated in the professional survey. The first and second academic versions differ from the professional version when requesting percentage of time spent on design activities, the major column divisions are for the course experience and for professional experiences. In addition, the first academic version also omits the first core question. 1. Rank the following design task by how much you enjoy doing them? Where 1 is most enjoyable and 8 is least eniovable. Identifying - problem identification Brainstorming - idea and concept generation Benchmarking - users and existing designs and concepts investigation .Decision making - idea and concept selection Prototyping - prototyping concepts and components Documenting - capturing the design rationale Evaluating - getting feedback on brainstorming, benchmarking, decision making, mock making and or documentation Reflecting - looking back on the design process and evaluating what went well and not so well Other 2. What percentage of time do you typically spend on the design process from your experience at your current company and from your experience at your previous companies? At Current Company Identifying Brainstorming Benchmarking Decision making Prototyping Documenting Evaluating Reflecting Other

At Previous Companies Identifying Brainstorming Benchmarking Decision making Prototyping Documenting Evaluating Reflecting Other

3. What motivates you to do design work? 4. What do you feel is most challenging about recording your design rationale? 5. How important is the following to you as a designer? Indicate High importance with an H, medium importance with £ M, and low importance with a L. _Staying technology current Knowledge about previous relevant designs ^Communication with co-workers Time management _Knowledge about venders and manufacturers

Recording your design rationale Observing the potential user Generating a variety ot ideas Other

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

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

1CED01-C586/472

213

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

Code Create

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

Code Opportunity Cost Format/Medium Details Skill Time

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

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

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 sampled only a small subset of the designer population designing in northern California, the findings may have an inherent bias due to the clustering of the sample pool. To investigate the extent of this potential bias, the subjects were asked for the percent of time spent on various tasks in the design process and the results are shown in Figure 2. It is believed that

214

1CED01-C586/472

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

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

3.2 Establishing the Baseline of Documentation Motivation

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

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

1CED01-C586/472

215

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

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

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

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

216

1CED01-C586/472

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

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

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

3.4 Primary Areas for Documentation Effort Reduction

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

1CED01-C586/472

217

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

Summary and Conclusions By building documentation incentives into the documentation tool, the tool's dependency on its environment can be attenuated. Understanding designers' pre-existing motivations to do design work may point to the kinds of feedback designers find rewarding when geared towards important design activities. This coupled with documentation effort reduction, may be the path to inventing effective documentation tools. Towards exploring this idea, the survey results established a list of designers' pre-existing motivation to do design work, and how common each motivation is between designers. It also determined designers' perspectives on the importance of design information activities and the major challenges to documenting design rationale. The next step towards incorporating incentives into documentation tools is prototyping several incentives developed from designers' most common pre-existing motivations and design activity importance. Following this, the next step is incorporating these incentives into an existing documentation tool that exhibits high levels of documentation effort reduction. Following the advancement of these steps, the prototype will be tested using both student and professional interactive focus groups. References [1]

Stewart, Thomas A., "Knowledge worth $1.25 billion", Fortune, 142 (13), 2000, p302

[2]

Grudin, Jonathan, "Why CSCW applications fail: Problems in the design and evaluation of organisational interfaces" , Proc. Conference on Computer-Supported Co-operative Work. ACM, 1988, pp. 85-93

[3]

De Long, David A., Liam, Fahey, "Diagnosing culture barriers to knowledge management", 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 Leifer Stanford University Center for Design Research, Mechanical Engineering Department, Building560 Panama Mall, USA, Tel: 650.723.0159; 650.723.2062, Fax: 650.725.8475; 650.499.6481 E-mail: [email protected]; [email protected] , URLhttp://www-cdr.stanford.edu/CDR/cdr.html ©IMechE2001

2is

1CED01-C586/472

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

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

1

Introduction

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

ICED 01-C5 86/664

219

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

2

Formalism and knowledge representation

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

220

ICED01-C586/664

Table 1. Notation of formalism for knowledge representation

Symbol {}

aeb aA b a vb aeb a=>b a«-»b a -* b

_, a >—b LaJ M F Fa P

D{0} d H {0} S i

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

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

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

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

ICED 01 -C5 86/664

221

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

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

Figure 1 Consequence generation due to selection of attributes of features

222

ICED01-C586/664

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

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

4

System architecture and implementation

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

ICED 01 -C5 86/664

223

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

5

Case Study of Sheet Metal Design

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

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

5.2 Generation of Violations/Consequences and Alternative Design Solutions Suppose that the minimum leg length (Unbent Length A) for the bend defined by the designer is 10mm. This information together with bending operation and thickness of sheet metal

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

224

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

ICED01-C586/664

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

6

Discussion and conclusion

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

ICED 01 -C5 86/664

225

system extension. These include: "Is the original phenomenon model still valid for sheet metal component design?" "Is the knowledge classification still suitable for the new domain knowledge?" "How can a domain specific knowledge intensive CAD system become even more knowledge intensive in a wider scope?" "How can such a system be extended to become a true knowledge intensive engineering system?"[5] Many successful prototype systems derived from research projects often have a relatively narrow scope and shallow depth in terms of the contents of domain knowledge represented. The successful evaluation of the first version of FORESEE encouraged the authors to extend the approach and its associated modelling methods to a wider engineering application area. The key findings from the research include that: •

the original proposed life-cycle consequence phenomenon model is still valid and effective for the new domain -sheet metal component design and it proves that a well established model is very important for knowledge intensive CAD to be extended towards knowledge intensive engineering;

•

the life-cycle consequence knowledge representation, based on the semi-formal formalism, employed in the research of the initial FORESEE system proved effective, though there is a need to adopt, restructure and regenerate the form features of sheet metal components, making it more rigorous and applicable for the new domains;

•

the scaling-up of a knowledge intensive system proved to be more difficult than it was initially thought. There is still a need to elicit domain knowledge and life-cycle consequence knowledge in a new domain though this has proven to be easier than the original knowledge acquisition for the first domain - plastic component design, due to the formalism adopted.

References [1]

Borg, J, Yan, X. T. and Juster, N. P. "Exploring decisions' influence on life-cycle performance to aid 'design for Multi-X'", Artificial Intelligence for Engineering Design, Analysis and Manufacturing: 1999, 13, 91-113.

[2]

Brown, D. Which way to KIC? IF IP TC5 WG5.2, In International Conference on Knowledge Intensive CAD, Vol. 2, Carnegie Mellon University, Pittsburgh, PA, USA, Chapman & Hall, 1996, .pp. 291-295.

[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 For Concurrent Engineering', Manchester, UK, 1998, pp. 169-184.

[4]

Rehman, F. "An investigation into the use of metal component manufacturing knowledge to support product and process design synthesis ", MSc Dissertation, CAD Centre, The University of Strathclyde, Glasgow, UK, September 2000.

[5]

Tomiyama, Tetsuo, "A manufacturing Paradigm toward the 21st Century", Integrated Computer 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 Weir Building, University of Strathclyde, 75 Montrose Street, Glasgow Gl 1XJ, UK. Tel: +44141 548 2852, Fax: +441415527986 Email: [email protected] ©With Author 2001

226

ICED01-C586/664

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

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

1

Introduction

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

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 following provides evidence to verify the potential of improved 're-use' mechanisms.

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

ICED01-C586/048

227

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

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

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

Figure 2 Current and Foreseen Overall Metric Benefits [7]

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

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

228

ICED01-C586/048

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

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

3

What can we re-use?

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

Figure 3 - Design Complexity Map [12]

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

ICED01-C586/048

229

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

230

ICED01-C586/048

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

4

Utilising knowledge in design re-use

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

ICED01-C586/048

231

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

Figure 4 -The Learning Activities [15]

5

Where - the applicability of knowledge re-use

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

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

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

232

ICED01-C586/048

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

6

Conclusion

In answer to the question: 'design knowledge re-use' -why what and where? We have shown that there is significant value in capturing and re-using the knowledge and experience of current and past designs. In addition, we acknowledge that a greater understanding of the role of knowledge in 're-use' is required. We establish within the spectrum of a comprehensive reuse model, that the knowledge generated throughout the evolution of a design requires a consistent approach to its capture, modelling and structuring. However, it has also been shown that for effective 'exploration' and 're-use', such knowledge must be maintained to prevent its stagnation and improve its applicability. Further, learning from design knowledge by generalising, removing the specifics of a design case and/or aspects of the domain, is shown to generate a source of knowledge with greater applicability within and across domains. In addition, this generalisation supports partial re-use of past cases (and their associated knowledge), and can facilitate positive 'design fixation'. Such 'formally' supported design knowledge' extends the 're-use' approach to both earlier stages in the design process and to design environments with more original content than re-design cases, to which current 're-use' practice is predominantly limited. References [1]

[2]

[3] [4]

Gao, Y., Zeid, I. and Bardasz T., "Characteristics of an Effective Design Plan to Support Re-use in Case-based Mechanical Design", Knowledge Based Systems, Vol.10, 1998, p337-350. Khadilkar, D.V. and Stauffer, L.A., "An Experimental Evaluation of Design Information Reuse During Conceptual Design", Journal of Engineering Design, Vol.7, No.4, 1996, p. 331-339. Jones, M.E., "Reusing Integrated Circuit Designs", Computer Design, July, 1995 Culley, S.J., "Design Re-use of Standard Parts", Keynote Paper, in Proceedings of Design Reuse - Engineering Design Conference, Brunei University, UK, 1998

ICED 01 -C586/048

233

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

[13] [14]

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

[19]

[20]

[21] [22]

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

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

234

ICED01-C586/048

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

DOCUMENTATION AND EVALUATION IN EARLY STAGES OF THE PRODUCT DEVELOPMENT PROCESS L Schwankl Keywords: Design information management, information representation, systematic product development.

1

Introduction

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

Figure 1: Important factors for innovative product development processes

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

ICED 01 -C586/331

235

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

2

Documentation in early stages

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

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

236

1CED01-C586/331

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

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

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

ICED 01-C586/331

237

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

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

Figure 3: Database for concept ideas

3

Early analysis of product properties

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

238

ICED 01 -C586/331

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

Figure 4: Effort and success in context of new technology

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

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

1CED01-C586/331

239

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

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

Figure 5: different solutions with similar properties

4

Implementation and verification

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

240

ICED 01 -C586/331

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

5

Future work

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

Figure 6: Sketch board

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

1CED01-C586/331

241

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

6

Conclusion

The form and the data base have already been used successfully in several development projects. Using the form with given areas, more information is demanded from the person who is sketching the concept than by the use of simple sketching paper. A further advantage is that the team members are motivated to document any further ideas raised in the discussion. So the ensuing evaluation and selection processes should be simplified. By formulating critical questions, identifying relevant parameters and selecting an analysis procedure in common, the methodical evaluation process becomes easier. Apart from archiving the ideas, there are also different visualization possibilities and a simple data exchange between various software programmes. By consistent documentation with the tools presented here an extensive knowledge and information base can be established in a short period. Employees, in particular the new employees, can get an overview of all projects done at the company and also use this data base to suggest new creative concepts. References: [1] [2] [3]

[4] [5]

Bernard, R., "Early Evaluation of Product Properties within the Integrated Product Development". Shaker Verlag: Aachen 1999. Ehrlenspiel, K., "Integrierte Produktentwicklung". Miinchen, Wien: Carl Hanser Verlag 1995. Gierhardt, H. et al., "24h-Entwicklung - Bin Grundlagenprojekt in der Antriebsentwicklung". Entwicklung im Karosseriebau.l 1./12. Mai Hamburg, vdi Bericht 1543 Schwankl, L.; Pache, M., "Collaboration between University and Industry in Engineering Design". Co-Designing 2000 Malorny, Ch.; Schwarz, W.; Backerra, H., ..Die sieben Kreativitatswerkzeuge K7. Kreative Prozesse anstoSen. Innovationen fordern". Miinchen: Hanser Verlag 1997.

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

242

ICED01-C586/331

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

MAPPING EXPERIENCE - LEARNING FROM EXPERIENCE OF PEERS THROUGH SOCIO-TECHNICAL INTERACTIONS T Liang, D G Bell, and L J Leifer Keywords: knowledge and information management, design reuse, lessons learned systems

1

Introduction

In project-oriented product development communities, the ability for designers to learn from the experience of others across projects enables them to build upon and subsequently advance the performance-baseline previously established by their peers [1]. This not only applies to experience associated with particular products, but also with particular processes. In fact, learning from other's experience associated with processes has been identified as a critical factor for product development firms to maintain a competitive advantage [2]. To better support this practice, many firms have implemented technical systems such as "best practice" and "lessons learned" databases in order to support the capture and re-use of experience across project teams. While such systems have shown demonstrable success in contexts such as field service [3], they have not shown comparable success in product development. Studies of such systems in product development indicate that purely technical approaches have inherent limitations, and that social issues are an important contributor to effective learning [4, 5]. This study presents empirical findings on learning from the experiences of peers in product development, with particular focus on learning about product development processes through social interactions. This study identifies features of peer-to-peer interactions that are significant for effective learning, and outlines implications for the design of related social-technical systems.

2

Research settings and methods

The setting of this study was the product development organization of a large multi-national firm, which develops office machines and uses an enterprise-wide product development process. The organization has many product programs working in various phases of the firm's product development process, and one of the prescribed elements of the formal process that teams struggle with is program planning for technology readiness. At the beginning of each phase, each product program must have a detailed program plan that estimates the time and resources necessary to complete the upcoming phase, and includes a detailed schedule for tasks and deliverables. At the end of each phase, the program's progress is judged against the details of their program plan. Teams struggle with making plans that are simultaneously compelling and achievable. This study involved an intervention, where peers from three relatively similar product programs interacted with the goal of helping one of the programs learn from the experience of the other two with regard to program planning for technology readiness. The intervention lasted for three and a half hours, and involved a total of nine participants. Two of the three participants from the peer programs were the technical leaders of their respective product programs. The learning team consisted of the program leader and people from various

ICED01-C586/478

243

functions such as product architecture and product quality. The learning program team decided the topic of the event and selected the peer programs from which to invite the peers. This intervention was videotaped and later analyzed. As a result of the analysis, several significant social features of interaction were observed, and a descriptive model of the interactions was constructed. These observations, in turn, helped produce several key requirements for the design of future systems intended to support learning from the experience of peers in product development. This study was guided by the following two questions: 1. What are the significant social features of interaction that facilitate learning from the experience of peers in product development? 2. What are the sotio-technical design implications of such features for learning from the experience of peers in product development?

2.1 Interaction analysis methodology An interaction analysis methodology was used to analyze the video and audio record of the interactions that occurred among participants. This method was adapted from that outlined by Jordan and Henderson [6], which includes group analysis of video records in conjunction with ethnographic fieldwork. This method relies on a combination of participant observation, in-situ interviewing, historical reconstruction, and analysis of artifacts, documents, and networks for providing the framing context. In this study, multiple cycles of interaction analysis were performed. In each cycle the observations from the previous cycle was further tested, evaluated, and refined. Specifically, the analysis cycle employed in this study consisted of the following four steps: 1) identifying conversational threads, 2) interpreting interactions, 3) characterizing features of interactions, and 4) testing generality of characterization. These four steps are outlined below. Identifying conversational threads A transcript of the event was first analyzed for conversational threads. The purpose was to obtain an overall understanding of the topics being discussed in the event, and to aid further analysis by dividing the transcript into manageable segments. An expected side benefit was that the process of identifying threads would also help to identify the most significant segments of the event. As in our everyday conversations, the threads of conversation intertwine with each other. Identification of the threads was done with great reliance on a thorough knowledge of the product programs, of the participants, and of the event itself. The threads were organized into two levels, with the first level being a broad topic and the second being the specific issue under that topic. Interpreting interactions A large amount of analysis work in the early cycles was spent on semantically interpreting the interactions. Interpreting and understanding these interactions were greatly aided by 1) the researchers' formal training in product development; 2) the deep understanding of the context that was acquired through ethnographic studies; and 3) the fact that the researchers participated in the event. To capture the interpretations, a two-column format was adopted, with the transcript in the first column and the interpretation in the second.

244

ICED01-C586/478

Characterizing features of interactions After interpreting the interactions, analysis was conducted to find a meaningful and reliable set of features of interactions. The semantic interpretation in the previous step provided the in-depth understanding of the interaction that was necessary to perform this analysis. In this step, each exchange of interaction in the event was characterized in terms of interactional moves. These characterizations of interaction gradually evolved with each cycle of analysis. The characterization informed better semantic interpretation of the data, which in turn helped to build better characterization of the features of interaction. In the end, a relatively stable set of interpretations and features emerged through this self-reinforcing feedback cycle. Testing generality of features The final step of the analysis cycle was to test the generality of the features. Features were tested generally true in the event were added to a list of significant features. example, it was observed that learning members verified lessons that they heard from peer with another peer. Once this feature was identified, the rest of the transcript searched to see if this occurred repeatedly throughout the event.

3

that For one was

Observed features of interaction and a descriptive model

As the event data is rich and is much more than we can show in this paper, we will describe three most significant features of interaction that were observed, and offer brief examples to substantiate these observations. Context comparison is a key to making sense of the conversation Context comparison activities such as comparing progress between the learning program and the peer programs were observed throughout the event. Context comparison allows the experienced peers to better understand the context of the learning team, and thus allow them to prioritize what experience to share and how to share it. More importantly, context comparison also enabled the learning members to judge the applicability of others' experience to their own program. Through the act of context comparison, the participants converged onto a set of terms and metrics, which are typically found in documents used for managing the product development process. These terms and metrics became the common references from which experience of one is related to another. These are the contextual characteristics that the participants were observed to have compared: 1. product characteristics (e.g. "Is your product as complex as ours?") 2. program progress (e.g. "In which phase of the process were you in?") 3. organizational roles and accountabilities (e.g. "Does your business group have that too?") 4. management tools and techniques (e.g. "Which tool did you use to ...?") For example, one of the documents being frequently referred to during the event was a document typically used by the management to benchmark program duration. In this document, all product programs in the company are grouped into nine categories according to product newness and complexity. For each of the categories, a set of benchmark data is offered so new programs can have a sense of the amount of time that it takes to develop a product of similar newness and complexity. Instead of using these benchmark data, participant in the event used this document to make sure that the learning program is of similar newness and complexity to the peer programs, such that their experiences were directly relevant and applicable to the learning program.

ICED01-C586/478

245

Needs specification brings out learning elements by inducing localized reflection It was observed in the data that an explicit problem statement or a need statement often brings long and detailed reflections from the experienced peers. The detailed nature of the reflections allows the learning members to project the reflected experience onto their own program and draw actionable implications for the near future. Furthermore, the details allow the learning members to ask concrete follow-up questions for meaning clarification. Different forms of needs specification observed in the event include: 1. problem statements or need statements (e.g., "How do we deal with this change?") 2. scenario playback requests (e.g., "Going back to Fall of 1997, did you ...?") 3. if-then interrogations (e.g., "What could you have done differently?") 4. requests for additional details (e.g., "Is there a rationale for ...?") For example, one of the problems that the learning program leader was struggling with was to deal with shifting phase-gate review criteria, on which the program team was periodically assessed according to the firm's product development process. Because of a recent change on the formal process, some of the deliverables from the next product development phase were shifted upwards into the phase for which the learning program was planning. The program leader was frustrated about this change because the shift made all benchmark data in the newness-complexity document invalid. Without the benchmark data on the amount of time it took similar programs to complete the phase, the program leader was left with a much more difficult job of planning for the next phase. After clearly stating the problem, the program leader voiced her frustration and asked, "So, tell me how those benchmarks change when you've now moved the phase-one exit line?" Her problem statement set off one of the most detailed reflections from the peers during the event. It was evident from the program leader's later summary that she had learned valuable lessons from that conversation. Verification of implications validates learning elements and produces actionable outcomes Verification of implications is another significant feature of interaction that was observed from the event data. It was observed that learning members tended to verify the significance of a lesson they heard from one peer with the second peer, as well as to verify the accuracy of the lesson by repeating them back to their peers. Afforded by the interactive settings, the learning members not only formulated in their own terms the experience as described by their peers, but also stated them in front of their peers and gave them a chance to correct or supplement if necessary. For example, after hearing from the first peer the fact that they underestimated the time to develop the full hardware for the test system, the program leader turned to the second peer and asked, "Was that true with your program too?" The program leader sensed that the lesson might have some significance even before she asked the question, and with confirmation from the second peer, she verified the significance of the lesson. When verifying the accuracy of the lesson, learning members restated the lesson as well as its implications in their own terms, and restated them in the form of a summary or sometimes as a "think-out-loud" projection. For example, shortly after the second peer confirmed the significance of the lesson, the program leader said, "So, I heard you say, don't underestimate what it takes to build full-system hardware..." Similar to this, after hearing from the peers the importance of involving the program reviewers in the planning process, the program leader stated, "So, we need to get our reviewers' buy-in at the planning stage."

246

ICED01-C586/478

3.1 Experience Mapping - A descriptive model The five significant interactional moves that emerged from the analysis were: context comparison, problem statement, localized reflection, meaning clarification, and implication verification. To describe these interactional moves and the sequential relationship among them, a descriptive model was constructed. Given that this model came from data gathered from one event, it is not meant to be a comprehensive model that would fit all interactive learning situations, although it is believed that it is general enough so it is applicable to many situations of learning from experience of peers in organizations. The purpose here is to help to locate opportunities for supporting these learning activities by having such a model.

Figure 1. Experience Mapping: a descriptive model of interaction-based experiential knowledge sharing in the product development context.

This model lies at the heart of this mode of learning here being characterized as Experience Mapping. Through activities in this model, experience from one context is mapped onto another. Here, mapping implies not only surveying the past experience, but also navigating through it, finding the most relevant "elements", and relating that to the current situation. The interactional moves were jointly enacted by the learning members and experienced peers. Nevertheless, needs specification, meaning clarification, and implication verification were mostly initiated by the learning members. Context comparison was initiated by both parties and occurred in various points throughout the event. Localized reflection was mostly initiated by the experienced peers, but was usually prompted by the program team's problem statements. The arrows in the diagram indicate the usual sequence of action, which is by no means the only sequence possible. In fact, the interaction sequences were routinely broken by context comparison activities throughout the event. An interaction sequence usually starts with problem statement where a learning member stated a need or a problem, or voiced his or her frustration over a matter. That would usually set off a round of localized reflection from the experienced peers, which is sometimes followed by questions from the learning members asking for quick and straightforward clarifications. Finally, with the reflections from their peers, the learning members would reconfirm with the peers by summarizing those lessons in their own terms. Then they would also express their project actions and obtain validation on the appropriateness of those actions from their peers. Learning interaction is influenced by social and political situations Learning, like all activities in the workplace, is embedded in the larger social and political context. Thus, the interaction between peers is inevitably influenced by the intricate socialpolitical environment. Unlike classroom learning, the learning team and peers do not have

ICED 01 -C586/478

247

learning relationship of student and teacher. Rather, they are in multiple relationships that are organizationally consequential. While the experienced peers are teachers in this event, they can also be peer reviewers who will assess the performance of the program at a future phasegate review. In any case, they are peers of the reviewers and their opinions of the program can be extremely influential to the reviewers. Although the program members felt the need to talk about the problems that they were facing in order to obtain concrete lessons from their peers, they had to be careful about what was disclosed because their words would partially make up the reputation of their program. This tension between disclosing enough information to learning and portraying a competent image was apparent in multiple occasions in the event. For example, at one point during the event the learning program leader felt that she needed to explain her technology before she could obtain valuable advice from her peers. She then selected a few slides and presented an overview of the technology. One of the peers was nervous about the fact that some of the technologies are so new that they might still be unproven, the peer voiced that concern and said, "so, I'd start asking, has anybody ever done anything like this? Inside or outside the company?" The program leader started defending her program and then decided to just say, "and I am not giving you a full picture here. So, please don't walk out of this with any kind of message." Not only did the learning members have to manage the tension of learning and disclosure, at times the experienced peers also had to do the same. For example, after some conversations it became clear to the learning program leader that the peer program was able to pass a phase review without having fully completed their prescribed deliverables. Paraphrased here, the program leader essentially asked, "How did you get away with that? Is there a fudge factor with the process?"

4

Socio-technical design implications

The interaction-based framework used in this study provided face-to-face interaction between learning members and their peers. The interaction enabled negotiation of meaning between the learning members and the experienced peers that is observed to be necessary for effective inter-team learning in product development contexts. Taking a socio-technical approach, we believe that some of the interactions observed in this event can be supported by sociotechnical systems. Here, we offer implications of the observations as design requirements. These socio-technical requirements become useful when trying to scale an interaction-based system to a larger community. Although we also provide brief discussions of possible solutions with current technologies, we believe that a whole new level of social awareness is required to design tools to support inter-team knowledge sharing and learning in product development. Three key requirements are: 1. the need for a semi-private interactional space, 2. the need to facilitate demand-driven localization, and 3. the need for shared objects of comparison. Semi-private interactional space It was observed that problem statements tend to draw locally actionable lessons from the peers through their reflection. It was also observed that there is tension between disclosing one's problems and protecting one's reputation. In order for the learning members to talk somewhat freely about their problems and frustrations, and for the appropriate peers to provide sincere responses, a semi-private interactional space is needed. In this study, the

248

ICED01-C586/478

meeting room provided a semi-private interactional space where the interactions were limited to the people in the room. Participants appeared moderate what they disclosed based on their existing relationships and knowledge of each other. Furthermore, the dynamics of conversation interplayed with interaction in such a way that the topic of discussion was interactively negotiated between the participants. With the distribution of product development communities around the world, the ability to interact in the same physical space can be limited, and information technology such as online forums can support distributed interactions that transcend physical proximity. Implications for designing semi-private interactional spaces in such distributed contexts include providing technologies that not only support dynamic interaction (synchronous and asynchronous), but also enable participants to control who has access to their verbatim disclosures of information that could have negative effects on their reputation. Demand-driven and localized reflection It was observed that reflections from peers produced locally actionable lessons when it was induced by a demand from the learning members. Therefore, a system needs to provide learning members an avenue to express their immediate problems and needs, and allow the experienced peers to understand the necessary background context to provide a useful reflection of their relevant experience. The system can provide some basic contextual information about the learning member's background and a description of the product program in which the learning member is engaged. Furthermore, the system should provide enough information for the experienced peer to contact the learning member, perhaps even anonymously if they choose to do so. Again, information technology can support this kind of interactions in distributed contexts. With communication technologies that have formalized structures such as online forums, it's important that the structures support problem- or need-centered interactions, as well as multiple interpretations and perspectives. This will help learning members and experienced peers from different functional backgrounds and organizational roles to see problems from their own perspective. While structures for demand-driven and localized reflections can be made explicit in the technologies, the structures can also be left to the domain of social practice. In this case, the technology should support flexible interactions where participants can structure their conversations according to their own demand-driven and localized needs. Shared objects of comparison Shared objects of comparison were observed to be crucial for relating the contexts of the learning team and their peers. As observed from the analysis, many of these objects were process-oriented documents that were used in day-to-day operations. In this study, objects of comparison like the product complexity matrix were used strategically for comparing contexts. These shared objects were used both to identify the most appropriate peers prior to the interaction, and were used during the interaction to facilitation communication and address relevance through context comparison. Information technology can support both uses of shared objects of comparison, however technology should not prescribe the objects since they can change over time and are often socially constructed. The technology should support objects that are locally meaningful, and in the context of product development processes an implication is that they account for locally meaningful characteristics of product complexity and processes. Technology should allow users to define locally meaningful metrics of comparison, and to assign values to those metrics for context comparison.

ICED 01 -C586/478

249

5

Discussion and conclusion

Recent advent of computer and internet technologies brought forth many affordances that have the promise of breaking the physical barriers of space and time. Undoubtedly, some of these technologies have already drastically changed the way we work and live. In the context of learning from the experience of peers in product development communities, many tools were designed to take advantage of these affordances. While most of these tools focused on distribution of documents across space and time, they lack the support for negotiation of meaning through interaction that is necessary for effective learning of peer experience in product development contexts. With the deeper understanding of how negotiation of meaning takes place through interaction, we can embark to design a new generation of socio-technical solutions that can support it. Furthermore, since learning is such a situated and social phenomena, we strongly advocate that the implications from these new-found insights be addressed during the design of the solution, not outside the design or after implementation.

Acknowledgement The research was supported (in part) by the MIT Center for Innovation in Product Development under the NSF Cooperative Agreement Number EEC-9529140. References [1]

Leifer, L.J., et al. Experience Capture and Reuse for Complex System Design Deployment: position paper based on our experience using the internet. In The International Conference on Problems of Control and Modeling in Complex Systems (CPCMCS). 1999. Samara, Russia.

[2]

Wheelwright, S.C. and K.B. Clark, Revolutionizing product development: quantum leaps in speed, efficiency, and quality. 1992, New York, Toronto: Free Press; Maxwell Macmillan Canada; Maxwell Macmillan International, xiv, 364.

[3]

Bell, D.G., et al., Dynamic documents and situated processes: building on local knowledge in field service, in Information and Process Integration in Enterprises: Rethinking Documents, T. Wakayama, et al., Editors. 1997, Kluwer Academic Publishers: Norwell, MA.

[4]

Liang, T., Mapping Experience: Understanding Socio-Technical Inter-Team Knowledge Sharing in Product Development Communities, in Department of Mechanical Engineering. 2000, Stanford University: Stanford, CA. p. 140.

[5]

Liang, T., Bell, D.G., and Leifer, L.J. "Re-use or re-invent?: Understanding and Supporting Learning from Experience of Peers in a Product Development Community," Forthcoming in Journal of Engineering Education, 2001.

[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 Liang Xerox Palo Alto Research Center, 3333 Coyote Hill Road, Palo Alto, CA, 94304, USA, Tel: 650.813.7302, Fax: 650.812.4334, E-mail: [email protected]. ©IMechE2001

250

ICED01-C586/478

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

TRANSFER OF EXPERIENCE IN CRITICAL DESIGN SITUATIONS P Badke-Schaub, J Stempfle, and S Wallmeier Keywords: Experience, human resources, information transfer, design teams.

\

Introduction

It may be unnecessary to repeat the consistently named customer demands for industrial companies: they have to reduce cycle times, they should decrease costs, they should ensure and improve the quality of their products and they should offer new solutions - to name only the most frequently claimed demands for product development. But regarding the different requirements and the complex process of designing, the necessity to produce useable and novel solutions seems to be the most comprehensive and challenging requirement in order to face world-wide competition. Thus, creativity and innovation seem to be the key characteristics of successful design practise. Although a lot of authors discuss several different origins of creativity such as divine gift, persistence, perceptual knowledge, and some other, in empirical investigations knowledge and experience prevail as the main ingredients for the development of new products and solutions [1]. Moreover the significance of information transfer of experience during the design process must be addressed. With increasing complexity of technology individuals have to work together in order to raise individual solutions, which are part of a major common product, to a shared level. Furthermore, experience is an individual characteristic that can be exchanged through communication, however. Thus, the question arises how the transfer of experience can be assessed and supported and which factors are facilitating and inhibiting this process. This paper relates to the question of how designers transfer experience in different types of critical situations in an efficient way. This means that on the one hand experience is considered as an individual cognitive prerequisite in the individual designer and on the other hand, experience is seen as an important part of the information transfer process, in the context of collaboration and communication.

2

Characteristics of experience

Experience is acquired mostly through extended deliberate practice, thus expertise is formed in a multitude of different situations and their constituents in the specific working environment, in which more or less appropriate actions are taken [2]. But what are the specific characteristics of an experienced person?

2.1 Characteristics distinguishing experts and non-experts The most empirical studies about expertise are investigations about the differences of expert and novice performances in different problem spaces [3]. These data reveal some important

ICED01-C586/531

251

differences between experienced and less-experienced people, especially due to their different cognitive models. Nevertheless it should be mentioned that expertise should be seen as a continuum, with the outstanding expert on the one edge and the novice with rather modest experience on the other. In addition expertise comprises different components such as general and specific knowledge, methodological knowledge, skills and self-management strategies. According to the results of empirical studies differences between experts and non-experts can be attached to three different levels [4]: •

General process: There are differences between experts and non-experts in regard to the rapidity and accuracy of the general information process.

•

Knowledge-organisation: There are differences in regard to the organisation of knowledge. Experts are able to build cohesive chunks in the specific problem space. Thus, the decisive characteristics of an expert is not the quantity of knowledge but quality, that is the organisation of knowledge.

•

Cognitive-complexity: Experts build more complex representations of information, and it is supposed that experts do have a higher capacity of the working memory. The reason may lay in the building of chunks, which are able to represent more elements with less 'memory cell'.

2.2 Characteristics distinguishing experienced from non-experienced designers As there are very few empirical investigations about the differences of experienced and less experienced designers, it seems worthwhile to mention some important results in short. Gilnther [5] aimed to compare the strategies of experienced designers without education in design methodology (p-designers) and designers with education in design methodology (mdesigners) in a laboratory experiment. He found that the p-designers needed 30% less time in the average than the m-designers in completing a good or satisfactory solution. The reason was that experienced designers spent less time on conceptual design, elaborated fewer variants, did less documentation of the process and partly skipped phases of the design process. These results illustrate that the experienced designer seems to be a victim of the time constraints of the daily work. The one satisfactory solution produced in a short time is more appealing than the search for an optimal (creative) solution selected out of a few variants. Gunther contrasts the characteristics of the "time-oriented-process" with the "quality-oriented process" and states that the time-oriented process provides solutions 'state-of-the-art', mostly only very few concepts, whereas the quality-oriented process produces innovative solutions. Eckert, Stacey and Wiley [6] report about the burnout syndrome of experienced designers as an escalation of the effects of pressure on expert designers with the consequence of a decrease of creativity. Whereas time-pressure is only one limiting factor equally true for experienced and less experienced designers, Purcell and Gero [7] illustrate the aspect of mental fixation which is mainly a problem of experienced designers. This problem arises because designers with expert knowledge have very strong associations between elements of their knowledge. This high amount of factual knowledge leads to a pre-selection of solutions according to the elements from previous similar problem situations, which may not be relevant in the actual situation and thus may lead to incorrect or at the best to conservative solutions. These results highlight the danger of experience. Experience is mainly used to design quick routine solutions whereas the ability to produce innovative ideas decreases.

252

ICED01-C586/531

Reflecting these results encourages a differentiation of the requirements of design. Designers are confronted with ill-structured problems as well as with well-structured problems, so that it seems worthwhile to follow the differentiation of Hatano & Inagaki [8] between routineexpertise and adaptive expertise. Routine expertise is mainly developed in the field of work, which is characterised by constant and repeating requirements whereas adaptive expertise develops especially in the context of changing requirements and problems. In the process of the repeated performance parts of the involved knowledge may become unconscious and may mutate from explicit to implicit knowledge which is often difficult to verbalise. Based on these assumptions it is not surprising that experts often have difficulties to transfer their knowledge and their applied rules to other people [9]. So, if we focus on the transfer of experience we should concentrate on problems with less routine and more adaptive expertise.

3

Investigation

3.1 Research Methods In a joint research project engineers and psychologists have investigated ten design processes in four companies by compiling detailed records of the design process as well as collecting data on the individuals, the group and external conditions [10]. In a thorough analysis, the observed design process has being differentiated into routine situations on the one hand and critical situations on the other in order to concentrate on situations that have an important influence on the further direction of the design process and the product. These 'critical' situations are then described by influencing factors and their interrelations [11]. Furthermore, the communication between members of the observed design team in critical situations was assessed and categorised [12].

3.2 Main findings In the following we want to elaborate the significance of experience in the context of collaboration during the design process. Frequency of occurrence of communication in critical situations First of all we analysed the frequency of occurrence of communication in critical situations and during the whole working time. Although in our investigations designers were working individually about 70% of the whole working time, communication between colleagues occurred in 90% of all critical situations. This result illustrates the importance of information for the exchange of decisive design information (cf. Figure 1). In an additional study [12] interviews in 10 R&D departments of major German companies the importance of colleagues as the most frequently mentioned source of information transfer in everyday design work were underlined: Verbal communication was described as the most important mode of the information seeking process.

ICED01-C586/531

253

Figure I. Communication in critical situations and during the whole working time. Importance of experience in critical situations The next question was to analyse how often experience was rated as an important individual prerequisite during the handling of each critical situation. Experience was rated high, if the experience of the designer with the specific problem area was longer than mostly five to seven years - in case that the observer couldn't decide about this fact the designer was asked about his experience in the particular field. The data revealed that in 49% (n = 336) of all critical situations (n= 682) experience of the designer was rated as an important influencing factor (cf. Figure 2).

Figure 2. Experience rated in critical situations according to biographical data or according to the selfassessment of the designers.

254

ICED01-C586/531

Experience and performance in critical situations Appreciating that experience plays an important role in critical situations yet we do not know, if high experience is correlated with successful performance in the particular critical situation. This study refers to the question to which extent the experience of the designer is transferred into a successful result. Thus, the next step was to analyse how often high experience and information availability was combined with a successful result. The data illustrates that whenever an experienced designer was involved in the critical situation the transferred knowledge was mostly useful (cf. Figure 3): More than 80% (n= 219) of all critical situations with the participation of a highly experienced designer (n= 271) were performed successfully. But it is also remarkable that in almost 20% of all critical situations the highly experienced designer was not able to turn the situation to a good account. Nevertheless it is necessary to point out that experience was only one influencing factor contributing to a network of interrelated factors from the field of the individual designer, the group, the external and organisational aspects and the characteristics of the problem itself.

Figure 3. Experience and performance in critical situations. Experience in different types of critical situations

As we have mentioned earlier, the whole observed design process was recorded and divided into routine situations and so-called critical situations. Why? The analysis of design work reveals that not every moment is of the same importance for subsequent design activities and for results obtained later. For example, at certain moments we may observe designers sitting at their CAD station adding holes and screws during the embodiment design phase of a component; at other moments they are engaged in deciding on concepts or solution principles. Obviously, we can distinguish between 'routine work' and 'critical situations', that determine 'choice points' in the process, and thus in the whole project. These critical situations influence the remaining design process in a positive or negative way. Derived from the steps of general problem solving, we can contrast different types of critical situations regarding their aim in the problem solving process, such as 'goal-analysis and goal-decision', 'solution-search',

ICED01-C586/531

255

'solution-analysis and solution-decision'. Moreover, we can observe situations that are important in their social context such as 'conflicts' and 'disturbances' (cf. Figure 4).

Figure 4: Critical situations in the process of design work.

According to the definition of experience as knowledge about facts and strategies in combination with skills in a specific work domain we would not expect that experience in the design context facilitates the management of critical social situations such as disturbances and conflicts. Thus, we analysed the impact of high experience in critical situations of the type goal elaboration (=goal analysis and goal decisions) and solution search.

Figure 5: High experience in relation to successful and unsuccessful results in two types of critical situations.

256

ICED01-C586/531

It turned out that the designers were able to transfer experience in an efficient way in regard to the development of solutions. But experienced designers in our investigations had more problems transferring helpful information in situations of goal elaboration (cf. Figure 5). The data reveal that in 36% of all critical situations of the type goal elaboration the result of the situation turned out as unsuccessful. In contrast, in more than 73% of solution search the situations were crowned with success. Searching for reasons we should ask what are the specific requirements of situations with goal elaboration in contrast to situations with solution search? Table 1. Typical requirements in situations of goal elaboration in contrast to solution search.

Goal elaboration Transfer of information is requested to fixed requirements Precise knowledge about the factual requirements Recognition of the context and relevance of the particular goal

Solution search Amplifying and limiting the search area of ideas and solutions Generation of ideas: intuitive, not necessarily systematic analysis There is no 'one and only' solution

As we point out in Table 1 the two types of situations are very different in regard to the requirements. In the context of goal elaboration the experienced designer is asked to contribute precise information concerning existing requirements. However, the knowledge of the experienced designer is not necessarily concerned with the actual requirements; he often transfers information from similar problems he knows from the past in a routine manner. Additionally, the designer who is asked for information is not involved in the complete network of the problem space; therefore he or she may put the focus on a completely different (maybe wrong) part of the problem and may not be aware of side and long-term effects of the given answer. If such information meets an inexperienced colleague the experienced designer may create severe problems in the future. Whereas goal elaboration is very much restricted to the 'correct information', which is related to the prescribed requirements, the solution search is especially concerned with idea generation and idea evaluation. In situations of solution search we observed many situations of informal discussion, where the experienced designer was asked to generate an idea and to discuss hindering or facilitating aspects of the developed solution. Thus, in this context experience is of high value because unclear ideas can be substantiated or brought into another view. The discussions move between limiting and amplifying the scope of the problem but the experienced designer is not asked for the generation of the one right solution. In this context experience frequently initiates a thorough analysis and a deeper thinking, a process which leads to successful solution search more often.

4

Conclusions

In the paper we pointed out that the transfer of experience does take place in the design office very common and that the transfer of experience is of relatively great effectiveness in critical situations. However, experience is of different value in different types of critical situations. With regard to situations in which solutions are generated we can state that experience - in relation to Hatano, G. & Inagaki [8] 'adaptive experience' - can be transmitted successfully for the most part. This is more doubtful in situations of goal elaboration. One major problem

ICED01-C586/531

257

lies in the context of informal discussion in design offices. Whereas this strategy of informal information seeking is very recommendable in obtaining a good group climate and creative discussions [12], it also enhances ad-hoc and non-reflected answers. Usually designers prefer to search for information by asking their colleagues, because in doing so they receive a lot of additional information including a rough idea of the quality of their own idea, solution or decision. According to the results of the study we would suggest to reinforce informal group discussions in the context of solution search, but the process of information transfer during situations of goal elaboration should be supported by an information tool - not necessarily computer-based tools - which provide quick and current information about requirements. References [I]

Cross, N. and Clayburn Cross, A., "Expert Designers", in E. Frankenberger, P. BadkeSchaub and H. Birkhofer (eds)., Designers. The Key to Successful Product Development, pp. 71-84, London, Springer, 1998.

[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.), Human Memory and Cognitive Capabilities. Amsterdam, Elsevier, 1986.

[4]

Steinberg, R.J., "Expertise in complex problem solving: A comparison of alternative conceptions", in P. Frensch and J. Funke (eds.), Complex problem solving: The European perspective. Hillsdale, LEA, pp.295-321, 1995.

[5]

Gunther, J., "Individual influences on the design process - time-oriented vs. qualityoriented 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 and K. 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 Intuition and Expertise in the Era of Computer", New York, Free Press, 1986.

[10] Wallmeier, S., Badke-Schaub, P. and Stempfle, J., "Empirical diagnoses and training in design departments", Proc. of the TMCE. Delft, April, 1999. [II] Badke-Schaub, P. and Frankenberger, E., "Analysis of design projects", Design Studies. 20, 1999, pp.465-480. [12] Badke-Schaub, P. and Frankenberger, E. (1999),. "Design Representations in Critical Situations of Product Development". Proceedings of the 4th Design Thinking Research Symposium. MIT, Boston, 1999. Dr. Petra Badke-Schaub (Mrs) University Bamberg, Institute of Theoretical Psychology, Markusplatz 3, D- 96045 Bamberg, Germany, Tel.:++49 (0)951 8631863, Fax: ++49 (0)951 601511, e-mail: petra.badkeschaub@ppp. uni-bamberg. de © Petra Badke-Schaub 2001

258

ICED01-C586/531

Organization and Management of Design Including sub-sections: Project Management Product Strategy and Management Planning and Workflow Management Concurrent Engineering and Integrated Product Development Distributed Design/Supply Chain Integration Design Teams Management of the Clarification Phase Performance Evaluation Risk and Uncertainty Management

This page intentionally left blank

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

PRODUCT DEVELOPMENT MODELS FOR SHORTER LEAD TIMES AND MORE RATIONAL PROCESSES - ITS EFFECTS ON THE WORK SITUATION FOR PROJECT MANAGERS AND PROJECT GROUP A Zika-Viktorsson and J Pilemalm

Keywords: Project management, project work, human resources.

1

Introduction

Time as a scarce resource Time to market is since the past ten years a factor highly stressed in product developing companies. This factor is added to the requirements cost, performance and quality and has caused rethinking and changes in companies and projects. The strive towards a faster product development can be considered a consequence of growing international competition, the accelerating technical development, more products and shorter life cycles, and the diversification of customer needs. Higher effectiveness through lean product development and standard models Lean product development is a concept heading towards higher effectiveness. It is a broad concept, encompassing a number of techniques as concurrent engineering, cross-functional teams, and integrated rather than coordinated cooperation. One of these techniques is organizing work in projects with heavy weight or autonomous team structures. Project organisations by itself implies a clear time limit, a date when the task should be accomplished. Project management literature describes projects as a rational method to organise development work optimised to the objectives for time, function and costs. Projects are seen as functional in order to handle undertakings of more unique nature with development as the central feature. In industrial product development the basic reason for organizing work as projects is to implement a planning strategy. One way of making the product development process more efficient in a company is to implement structured models for standardising product development activities. In general, the reason for a company to implement such models is to obtain a more effective use of resources and time. Other reasons are to create consensus for the project process and the project management, a necessity caused by increased complexity in both technique and organisations [1]. Beside the more efficient use of resources such models are supposed to facilitate control over projects from an internal as well as external point of view. A standard model for projects may also make it easier for the team members to know what expectations are placed on them.

ICED 01 -C586/461

261

Focus on time - implications on team Elevated time goals and organising for shorter lead-times impact co-workers as well as coworkers impact the ability to shorten lead times. Group effectiveness as performance addressed to the goals for the project is an essential factor. The project team must exert sufficient effort to accomplish the task at an acceptable level of performance. An effective team is a prerequisite for accomplishing a project within narrow time frames. Beside the obvious needs for effort the members in an effective team also have to bring adequate knowledge and skills. The members must be able to employ task performance strategies that are appropriate to the work and coordinate their work at the same time as motivation and commitment are created and maintained. Further, an effective team must have a potential to avoid inappropriate ideas and contributions as well as they must possess learning and sharing skills. They need capabilities to avoid flawed implementation of plans and develop ways to proceed with the work [2]. Not only the capabilities of the available team are crucial. Team effectiveness is interdependent with organisational context, boundaries between tasks and groups, and team development [3]. One disadvantage with working in time-focused projects can be a too heavy workload, which can give drawbacks on individuals as well as objectives for the project. Product development projects high in complexity together with work in multi-functional teams and elevated time goals can cause too much strain on the members in the projects. There is a risk that intensive project work brings a much too high work strain as a consequence of high demands on effectiveness and efficiency together with parallel activities [4]. To tight time schedules give less time for reflection and decision-making, which lower the quality of the product, and can be negative for the members and cause negative work strain [5].

1.1 The aim of the paper The paper will present results from a qualitative interview study made to explore the positive and negative consequences for project managers and members in project teams highly focused on the time objectives. The study looked at the work situation on the project level in two companies that implemented standard models for how to handle product development. The models were implemented as means to shorten the lead times for the projects.

2

Data and methodology

Data for the study was collected from 16 co-workers in product development projects (of which 8 were project leaders), equally dispersed at two companies. The two involved companies were Swedish manufacturing companies in the mechanical industry. The companies had implemented new models for the product development process with the aim to run the projects faster and with better structure. For both companies, the development of new products was important for the long-run success. Further, the type of product development work in these companies was technologically sophisticated and the development undertakings included new products and variants of existing products. The planned length of the various projects, the interviewees were working in, varied between two and seven years. The sizes of the core project teams varied between seven and 20 members.

262

ICED 01 -C5 86/461

The interviews involved questions addressing co-operation, co-ordination, workload, time pressure and decisions. The interviews were semi structured and with the length of one to one and a half hour. The interviews were tape-recorded and analysed according to principles for grounded theory [6]. The study had an explorative approach with qualitative methods. The qualitative approach is justified by the complexity of the studied situation. To grasp both qualities in the models and experiences of working with focus on shortening lead-times a qualitative approach was needed. An explorative approach was needed because of the lack of research concerning timefocused project work and psychosocial work-environment. This paper shows results, which is a part of a more comprehensive study involving a broader scope and a third company [7].

3

Findings

With an aim to make the product development projects faster the two companies had introduced new models for the whole product development process and the projects within. The aim was to improve the procedures for managing, monitoring and planning the product development in general, as well as the separate projects. The new models were supposed to be a way to improve the quality in the work process by making the activities more concurrent and support the multi-functional co-operation, and at the same time make the projects accomplished on a short time. The new models should support and prescribe the work by giving a holistic and comprehensive view of the product development process. They should also introduce better routines and structures as well as elevate the time objectives. Former models imaged the product development process (and project process) as sequenced activities emphasizing construction, and functional goals. They mirrored work methods and strategies where functional objectives and technical performance was superior to objectives for time.

3.1 Experiences of working with the models for product development projects The models as a support. At the project level the new models were generally seen as a good support in the overall work with planning. The models and the routines had given the project managers new tools for executing the projects. They were also functional as a common platform for all the projects within the companies. The models were considered as contributions to better understanding of the product development process and the project management at all levels in the companies. The models as a burden. Even if the new models were created with the aim to suit the specific business in the particular company, shortcomings were reported. According to the interviews the models were fitting product development projects at a low level of complexity. Thereby the models couldn't be a functional support or guide for projects characterized by great dynamics, parallel and concurrent activities, high complexity and high speed. The models couldn't support these kinds of projects well enough. The routines prescribed by the models tended to become a burden for the project managers, making it difficult to accomplish the project as effectively as they wished. According to the interviews the models were considered as stiff and inflexible.

ICED 01 -C586/461

263

Needs for neglecting the model. Because of the elevated importance of time objectives it was sometimes a need to neglect the prescriptions connected with the model. In the interviews it is described how the complex nature of the project together with the demands for speed made the project manager searching for short cuts. Thereby there was a need to neglect some of the routines. Because of the nature of the product development project, it wasn't possible to keep up with the prescribed process nor the work methods or administrational routines.

3.2 Experiences of working towards shortened lead times High commitment and pride. Even if the interviewees reported some negative aspects on working with a sharp focus on time there were also some positive impact on individuals and teams. The work under high pressure was a challenge, which resulted in feelings of pride when the goals were reached. Another positive aspect was that a ground for high commitment between team members was created. More work with plans during accomplishing a project. Emphasis on reducing time gave implications for compressed time schedules for the operative work in the projects. However, the speed, dynamics and complexity put special demands on planning procedures and scheduling methods. The work with plans and with communicating them to team and stakeholders is always an important part of the work for a project manager. However, the elevated focus on time objectives resulted in more work with planning. The compressed time schedule made the smallest deviation affect the plan. According to the interviewees this made it necessary to put a great deal of work updating the plans and schedules continuously. Less time for thinking. The increased tempo and the tightened time schedules made the periods, during work hours, for thinking, reflecting and catching up fewer, or even nonexisting for the project managers. Even though the daily work - off course - calls for a lot of reflective thinking there was a lack of time for thoroughly go trough problems and tactics. There was a need to clean up the desk and get undone administration done, as well as reflect about the structure and the process from a distance, and thereby get possibilities to grasp the picture of the whole situation. According to the interviews there was a need to reflect over the project situation and thereby gain better control over the situation and deviations. Hasty decisions and uncertainty. There was also an experienced lack of time to take into account (in a satisfying extent) important aspects of a problem before a decision. The need for quick decisions created feelings as constantly coping with risks and, in turn demanded selfconfidence and fearlessness together with carefulness and sound judgement. According to the interviews the work with shortening lead times was sometimes synonymous with constantly handling hasty decisions and uncertainty. Greater need for support. An assistant or a 'right-hand man' (or woman) can be of great support for a project manager - especially in projects characterized by uncertainty and high speed. In the interviews there was an example of a partnership that had been of great help. Both by practically relieving some of the workload but also by being a trusted person that supported the project manager in more strategic and sometimes controversial questions. In the high-speed project there was a constant need for quick and effective discussions about several aspects of formal management as well as leadership. This partnership was facilitated by a concordant view upon project management and compliance at the personal level. Needs for empowerment in project teams. It is necessary for a project manager to delegate tasks as well as responsibilities in a complex and fast project. According to the interviews the

264

ICED 01 -C5 86/461

project managers had to decrease the direct and personal way of controlling product related details. They had to trust the project members, their competence and ambitions. It was also considered important to encourage empowerment in the teams. Needs for committed team placed together. A highly committed team was considered as the obvious ground for effective project work within narrow and rigid timeframes. According to some interviewees organizing the project as a heavy weight team and not within a matrix structure enhanced commitment. This made a good ground for commitment partly by avoiding conflicting supervision of more then one supervisor. It was also of great importance to place of the team members together. This localization made it possible to resolve problems in an effective manner where the team could use their capacity to continuously and thoroughly work out the problems coming up. The whole team could work integrated and discuss until all questions were went through. To place a team together gives good opportunities for the members to thoroughly work with problems. Even if there were limits they wasn't settled by a meeting agenda, formal communication channels or distance. Attention on signs for overwork. According to the interviews there was a need for the project manager in the high-speed project to be attentive to signs for team members not feeling well under the high pressure. Beside the demands for monitoring and controlling, to keep the project on track, it was important to focus on how the coworkers cope with the pressure. There was a need not only for the project manager to be attentive to signs for overwork; everybody had to pay attention to this kind of problems. According to one of the statements in the interviews, projects with only male members tend to neglect these kinds of issues and focus too much on practical and technical issues. The risk for lowering the quality in technical solutions. According to the interviews there was a worry among the product developers for a lowered product quality caused by the focus on time objectives. In the interviews there was examples of dissatisfaction concerned jeopardizing the quality. Another aspect on working with high time focus was the impact of the time pressure on creativity and problem solving. According to the interviews there were situations when team members ran out of ideas because of the high pressure. But there were also examples on increased creativity caused by the situation where the team, forced by the time pressure, had to lift themselves up to higher levels to grasp the whole situation and then find out new ways to solve problems. To work very intensive and focused had also created a lot of knowledge. The intensive work together in the team, with the common task, was a ground for high level of knowledge about every aspect of the object for the project. This knowledge together with a rich flow of ideas and an open climate were considered as one of the basic factors for accomplishing a highspeed product development project. Insufficient time for personal development and participating in company activities. In the interviews there was an example of neglecting the more formal development of the team, individuals and the work methods. There was also a lack of time to participate in different company events, which made the project rather isolated.

ICED 01 -C586/461

265

4

Discussion

The aim of the study was to investigate how standardised ways for managing projects together with the claims for shorter time-to-market can affect the work situation on operative project level. The interviews give a broad picture of the experienced work situation in these projects with new standards for routines and elevated time objectives. This picture includes both advantages and disadvantages. Below, the three main parts of this picture are discussed. First. For the manager of a dynamic, complex and high-speed project, a standard model created to suite every project within a company can be difficult to apply. It can even be considered as an obstacle for effective accomplishment. Beside the direct implication of a stiff model on effectiveness at the project level, it can also lower the work satisfaction. Individualism, meaning to retain the own identity and do things the personal way, is opposed to conform to an imposed standard. The standard way of managing a project has to be balanced with possibilities for commitment, flexibility and control. In what extent this is a general problem within companies, can be discussed. However, the uniqueness of a project form and standardization of the bureaucratic form can stand as each other's empirical opposites as ways of organizing [1]. The project management literature states that projects should be handled on a situational basis. But also, the features of scientific management can make a natural ground for primarily aim towards uniformity and standards when creating and implementing new work methods. Second. Endeavours, at the project level, for speeding up the product development call for intensive teamwork. This kind of teamwork evolves naturally around the constantly arising problems. It involves effective communication; rich flow of ideas and possibilities to work thoroughly with arising issues. Provided by prerequisites for effective communication the intensive teamwork can give a genuine and comprehensive knowledge concerning the object for the project. Problem-solving orientation influences how quickly a product is developed [8]. The intensive and successful work together in a team can lay ground for high commitment and pride. Factors as goals, empowerment, climate and human resources plays an important role in cross-functional work in product development. These factors are affecting each other and set the stage for subsequent development [9]. Work group effectiveness can be defined in terms of both productivity and employee satisfaction [10]. Another important factor is self-management, which is the group level analogy to autonomy at the individual job level. It is central to many definitions of effective work groups [11] and part of most interventions. Related factors are participation and selfmanagement that are presumed to enhance group effectiveness by increasing members' sense of responsibility and ownership of the work. Work group effectiveness also demands task significance, in terms of members thinking of their task as having significant consequences [2], An effective team also needs collective belief in their capability to perform their job - i.e. the team's efficacy [12]. Third. Work with elevated time objectives exposes project members and team members to strain. Besides a more direct pressure from the explicit objectives, there is a pressure from decreased control and lack in overview if the project also is highly complex. The experience of control is an important factor for reducing high negative stress levels [13]. Usually project work demands balancing between objectives within time limits. The task for a project

266

ICED 01 -C5 86/461

manager implies trade-offs within a frame settled by the objectives for function, cost and time. But the tighter the scheduled time limits are, the shorter the time for reflecting and evaluating decisions and effects. There is less time for thinking and gaining control and the difficulties concerning to these matters aggravates with the complexity of the project. The need for support in a work team become more obvious as the time pressure escalates. At the operative project level both team members and managers must be supported both socially and instrumentally. Besides the obvious advantages of instrumental support and relief, social support has shown to be an important moderator on strain [13]. Among the need of other important supporters the project manager can need a 'right-hand'. This partner can provide aid during the execution of the project, both in evaluations but also by generating ideas concerning work methods. This partnership can reduce strain and improve the quality in decisions. An increased risk for overstrain within a project can make obligations for the operative project manager to focus more on psychosocial issues such as workload. The pressure in a high-speed and complex project emanates directly from compressed time schedules, but also indirect by jeopardizing quality and hasty decisions. The primary part of leadership in operative project management is goal-focused. Even if a project manager always, at some degree, has to consider relational and psychosocial aspects, there can be more of a necessity to focus on workload and well-being in high-speed projects. The findings in the study indicate problems at the operative level connected with faster projects. Changes made to rationalise the product development and to shorten the project life cycle put demands on the co-workers in the product development. Besides the advantages connected with economy and competitiveness there are also some risks with short lead-times leading to time-pressure that is too heavy. Too high a speed in the processes are not only a risk for overstraining the personnel, it is also a risk for the creativity, the quality in the decisions (and of it lower quality in the products) and the possibilities to develop the people, the methods and the groups. Furthermore, there is a risk for lowering the work satisfaction and thereby receiving a high personnel turnover. The study gives implications for further investigations on how demands for shorter lead times effects humans, the outcome of the projects and the design of project standard models. Important question to be investigated concern the contradiction between the greater importance for controlling and planning in projects characterised by high-speed an complexity, and the deteriorated possibilities to actually do this in such projects. It would be appropriate to use a qualitative research approach to obtain detailed an in-depth understanding in these matters. It is also of importance to investigate how single elements in a standard project model, as well as more general functions for steering, management and execution, are related to each other and to the work done by operative project manager and project team. Further, effects on the output of the project must be concerned. Not only outputs with obvious relation to the formal project goal, but also in terms of development of teams and individuals, knowledge and creativity. Off course, there is also a need for studies looking at workload (and moderating factors) generated within frames settled by objectives for time, resources and function.

ICED 01-C5 86/461

267

References [I]

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 and Effectiveness", American Psychologist, 45, 2, 1990, p120-133.

[4]

Hovmark, S. and Nordqvist, S., "Project organization: Change in the work atmosphere for 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 for qualitative research, deGruyter, New York, 1968.

[7]

Zika-Viktorsson, A., Pilemalm, J. and Hjelm, J., New Way of Working in Product Development: Case Study in Three Manufacturing Companies (In Swedish), Royal Institute of Technology, Department of Machine Design, Stockholm, 2000.

[8]

McDonough, E.F. and Barczak, G., "Speeding up new product development: The effects of leadership style and source of technology", Journal of Product Innovation Management, 8, 1991, p203-211.

[9]

McDonough, E.F., "Investigation of Factors Contributing to the Success of CrossFunctional Teams", Journal of Product Innovation Management, 17, 2000, p221-235.

[10] May, R.M. and Schworer, C.E., "Developing Effective Work Teams: Guidelines for Fostering Work Team Efficacy", Organization Development Journal. 12, 3, 1994, p2939. [11] Pearce, J.A. and Ravlin, E.G., "The design and activation of self-regulating work groups", Human Relations, 40, 1987, 751-782. [12] Campion, M.A. and Higgs, A.C., "Relations between work group characteristics and effectiveness: Implications for designing effective work groups", Personnel Psychology, 46,4, 1993, p823-850. [13] Karasek, R. and Theorell, T., Healthy Work, Basic Books, New York, 1990. Annika Zika-Viktorsson Integrated Product Development, Institution for Machine Design. Royal Institute of Technology, S-100 44 Stockholm, Sweden, Tel: + 46 8 790 63 03, Fax: +46 8 20 22 87, Email: [email protected], www.md.kth.se ©IMechE2001

268

ICED 01-C5 86/461

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

A MULTI-PROJECT MANAGEMENT APPROACH FOR INCREASED PLANNING PROCESS F Marie and J-C Bocquet

Keywords: project management, multi-project, planning, decomposition, and assignment

1

Introduction

Scope of the research: After a short introduction about PMI® concepts for project management, we will focus on three major topics of the project planning process, which are decomposition, assignment, and advancement state management. The scheme of the paper is in four steps: synthesis, problematic, proposals and impacts. The scope will widen in part 5 with a research proposal about generalised multi-project management. The topics, which are in our research activities, but not developed in this paper, will be specified.

2

Formal project management by PMI®

The PMI Standards Committee has developed a document that describes the sum of knowledge within project management: The Project Management Body of Knowledge (PMBOK©, [ 1 ]). It defines a project as a "temporary endeavour undertaken to create a unique product / service", and project management as "the application of knowledge, skills, tools and techniques to project activities in order to meet stakeholder needs and expectation". The PMBOK describes project management using three models: •

the project life-cycle: a project is subdivided into phases, organised by logical and chronological flow,

•

the project processes: series of actions bringing about a result (they map knowledge into deliverables). They are organised into process groups: initiating (recognising that a project or phase should begin and committing to do so), planning (devising and maintaining a workable scheme), executing (co-ordinating resources to carry out the plan), controlling (ensuring that project objectives are met) and closing (formalising acceptance and bringing it to an orderly end).

•

the knowledge areas: logical grouping of competence and the corresponding processes. They split up between two categories: the core knowledge areas: they generate the mandatory project deliverables: project integration, scope, time and cost management, the facilitating knowledge areas: they allow carrying out the core processes effectively: project quality, human resource, communications, risk and procurement management,

ICED01-C586/563

269

The project manager's role is to integrate team actions to deliver project results within the triangle scope / time / cost constraints. As specified in [2], planning and controlling processes are the major studied processes. We will focus on the planning process onto the next parts.

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 facilitating processes. Our scope is about the answer to questions what, who, how, when and how much:

Figure 1: PMI's planning core processes and major planning delivcrables

All these processes apply to the Project plan development: putting the results into a consistent document. This process is facilitated by the Organisational Planning and the Staff Acquisition, which consist of identifying, documenting and assigning project roles, responsibilities and reporting relationships, and then getting the needed human resources assigned to and working on the project. Synthesis: PMI describes a structured planning process, with identified steps. But many companies do not use such a structured process. For those companies, we propose some simple methods to do the main actions of the planning process. For companies that use part or all of PMI's planning process, we propose some improvements or tools that are not specified in the PMBOK. So, there is a reason for everybody to use what follows, but let us see first the problematic of the planning process. 3.2

Problematic

a- How to decompose project deliverables into smaller, more manageable deliverables? Decomposition of the WHAT (project objectives). The deliverable / objective has to be small enough, so that it becomes possible to define and sequence the activities that will realise it. b- How to decompose low-level deliverables (or work packages, as called in the lowest level of the WBS) into activities? Transcription of the WHAT into the HOW (how the objectives and deliverables are achieved by carrying-out of activities).

270

ICED01-C586/563

c- How to decompose activities into smaller, more manageable activities? Decomposition of the HOW. The activity has to be small enough, so that there are resources, which will be able to carry it out. d- How to assign people accountable for work packages, or bigger deliverables? Assignment of a WHO to a WHAT. Finding the person or subcontractor with commitment, ownership and responsibility for delivering the objective within time, scope and budget. e- How to assign resources (people, machines, equipment) to carryout activities? Assignment of some WHOs (who can be material stuff) to a HOW. Finding the persons, machines, equipment or combinations (like partners, subcontractors, internal services) with the skills, technologies and capacities to achieve activity within time, scope and budget. f- How to plan correctly at the beginning of the project? Is it possible/realistic? Is it worthy to try to do so? Putting in a consistent document the WHAT (for scope management), achieved by the HOW, carried-out by the WHO, with WHEN and HOW MUCH parameters (for time and cost). Part 4.1 (Decomposition) brings lighting to problematic a-, b- and c-. Part 4.2 (Assignment) brings lighting to d- and e-. Part 4.3 (Independent sub-projects planning) brings some lighting to problematic e-. Part 5 widens to generalised multi-project management. In summary: Decomposition is a cognitive problem solving process, which depends on many uncontrolled factors, as experience, available information, teamwork and team performance, team members' personalities and intelligence, and complexity management skills. Assignment is a multi-criteria choice process, which depends on human factors, as historical experience and relationships between people, powers and politics, complexity of multiple criteria, information about skills and interests, personal and even private data. Independent planning is a risk management process, which depends on personality of people, experience and historical information about similar situations / teams, and reporting accuracy needed by management.

4

Proposals and impacts

Figure 2 defines our research topic: from a situation analysis, each project manager at each level of the project, is able to generate the process that will satisfy the stakeholders, and the organisation that will carryout the process. We identify three kinds of risks: Functional risk: linked with the project objectives. The more ambitious, complex and resource-limited it is, the higher is this risk. Unrealistic expectations represent 9% of failure in IT projects. Uncertainty and waiting risk: as we do not still have any idea of the solution, there is a risk that this solution does not exist, or that we will find it too late. It is the balance between deciding too early (with the risk of error because of lack of reliable parameters) and deciding too late (with the risk of having no more enough time).

ICED01-C586/563

271

-

Organic risk: linked with the solution decided to realise the need. The more the solution is tested, validated by experience and robust, the smaller the organic risk is. Maybe we could ask too much (functional risk), maybe we could have chosen a bad solution (organic risk), or maybe we have waited too much before deciding for a solution (waiting risk).

Figure 2: basic scheme for project manager's actions and decisions

4.1 Decomposition Decomposition is a cognitive process. A non-human tool is not able to decompose work package or activity. Decomposition builds the project process (figure 2). Proposal 1: As the three problematic talk about different natures of inputs and outputs, there are three different methods for decomposition. Research outputs: standard procedure for each decomposition process: the DDD (Decomposition of project Deliverables into smaller Deliverable*) method, the DDA (Decomposition of project Deliverable into Activities) method and the DAA (Decomposition of Activity into smaller Activities) method. Link with PMBOK: DDD is in Scope Definition, DDA and DAA arc in Activity Definition. The three methods and their differences and similarities will be developed in oral presentation. Proposal 2: Historical information and standard documents and templates are needed to help this human cognitive process. Best arc computer-based templates and historic. Research outputs: Storage of Work Breakdown Structures (to help the DDD function), of activities lists (to help the DDA and DAA functions), computer-based tool to execute one of the three decomposition functions and to integrate results in the project plan and the project database. Proposal 3: Each actor assigned to a part of a project is himself (or herself) a project manager of a smaller project. A recommendation is to decompose one level at the time. Each subelement (deliverable or activity) is assigned, and the person responsible for the sub-element will execute the same decomposition process, with one of the same three decomposition functions. Research outputs: a WBS that is built progressively, and not in a one shot process. Activity lists are progressively built, in the same time as the WBS building. Proposals 1 to 3 are independent. Impact 1: with Proposal 1 & 2, a good method and historical information will increase reliability of decomposition results. The decomposition will be complete, the alternatives will

272

ICED01-C586/563

have been specified, sorted and maybe eliminated (or may still serve as "B plans"). The subelements will be coherent and consistent, and the interface problem will have been studied (it is a very tough problem to manage interface between deliverables, or between teams). The organic risk and waiting risk (see beginning of part 4.) will be reduced. As we know that the amount at stake growths through the phases, the organic risk reduction is a major gain in the planning process, especially to avoid planning mistakes, and rework or delay penalties. Impact 2: with Proposal 3, each actor has a one-level vision in all directions: one fatherelement, some brothers, and some sons. This reduced vision allows a more accurate management, because of the reduction of complexity of environment. Each manager can for example make a stakeholder analysis (as father manager becomes the customer, and as sonmanagers become suppliers), and a make-or-buy analysis, in his (or hers) competence domain.

4.2. Assignment Assignment is a cognitive process. A non-human tool is not able to assign somebody or something. Assignment builds the project organisation (figure 2). Proposal 1: There are only two kinds of assignment: people responsible (accountable) for a deliverable (output of the Initiation process, seeing deliverable as project), and resources (people, machines, equipment) carrying out an activity (output of the Resource planning process). Research output: the required skills and level (able to do or to delegate) of each role. Proposal 2: There are only two kinds of competence: management skills and technical skills. Research output: a classification of some skills in this two-column table. Proposal 3: A competence database is a useful tool to help for choice. It is possible to implement such a database in companies when it evaluates what can do the person, and not the level of competence she has in different skills. It reduces many problems of rewards, database maintenance and evaluation system. Research output: a data structure for competence database. It includes level 1 to 4 evaluation of skill and levels 1 to 4 evaluation of interest about working in this skill (developed in oral presentation). Proposal 4: the project manager may be guided with a standard assignment procedure, just as for procurement. Assignment of people has many similarities with choice of a subcontractor. Research output: a 7-sleps assignment process. Below is the process for human assignment (the process for machine and equipment, or subcontractor assignment, is not developed here): 1. Identify the required skills: For a deliverable, manager looks for an accountable, responsible person, so a person having management skills (level 4, proposal 3), and having enough technical skills to be able to manage the deliverable-related sub-project (level 3). For an activity, manager looks for person(s) having enough technical skills (level 4) to be able to carryout the activity (actions or tasks). 2. Select and sort the corresponding persons, with knowledge about their skill levels and interests, [f there is no result, manager knows the person will be external or to be trained. 3. Contact the selected persons. 4. Receive the assignment proposal. As for procurement, it describes the statement of work, the project, the context, the environment, and the actors already involved. 5. Answer the motivation: as for solicitation process, the contacted persons give an answer about their motivation and their vision of the work to be done and the fixed objectives.

ICED01-C586/563

273

6. New selection and sorting including motivation for the project. 7. Direct Communication / Objective Negotiation / Source Selection / Assignment Contract. Proposal 5: a computer-based tool may help project manager, but the final decision keeps human. The step 7 can not be computerised. Research output: a multi-criteria selection and sorting tool, including skill level, skill interest (step 2), and project interest (step 6). Proposals 3, 4 & 5 are linked, but proposal 3 may be applied independently. Impact 1: an assignment decision reduces uncertainty and waiting risk, but increases the organic risk. A process supported by a standard method and a computer-based tool that is linked with a competence database reduces this risk of error. As the choice of the members of the team may dramatically influence the project results, this is a major gain in the planning process. Impact 2: as the process is standard and the search is automatic, the time will be reduced. Impact 3: as required skills and people competencies are known, process objectivity growths. Impact 4: as each WBS element has an accountable, responsibilities are clearly defined and shared, especially if the decomposition has well managed the interface problem. Impact 5: It is possible to include training plan in the assignment process: people not competent (level 1 or 2 for skill level) but very interested (level 4 for skill interest) can be used after a training period. Impact 6: the process can be used for e-assignment, in the case of distributed, or networked or extended project, with actors not in the same place at all.

4.3. Independent sub-projects planning / budgeting / assignment As sub-projects contribute to a project, they may have different advancement states. One may already be under development (with actual costs), while another one is just planned (with budgeted costs), another one is just estimated (with estimated costs) or even not (with no idea). Their advancement state can be independently managed. Independent sub-projects advancement state management is part a cognitive process, part a feeling process and part a reporting process. Advancement state management gives stakeholders satisfaction (figure 2). Proposal 1: the management of sub-projects of a project, the management of projects of a programme [3] or portfolio, the management of sub-phases of a phase, and the management of sub-deliverables of a deliverable are similar. Research output: everybody in a project is project manager of something (of the entire project, of a part of the project, of a phase of the project, a deliverable, an activity...), except resources who carryout an activity. Proposal 2: as every project actor is a project manager (except for activities), he (she) should have the required skills (managerial and technical), like leading, communicating, negotiating, problem solving and organisation influencing [4], [5].

274

ICED01-C586/563

Proposal 3: as every project actor is a project manager (except for activities), he (she) should use the same decomposition and assignment processes. Proposal 4: as every project actor is a project manager, he (she) manages its advancement state as an independent parameter. It means that he (she) has an objective, a deliverable, a budget, a deadline, a team, and that the advancement state (estimated, planned, under development, to be corrected, validated) is negotiated with the environment. Research output: a waiting risk estimation is under development to help the manager to report to his (her) environment about the risk of deciding too early and the risk of deciding too late. Impact 1: proposal 1 involves that a project manager of middle-level is the seller for someone, and the buyer for someone else. One time you are in project management (you are the seller), the other time you are in procurement management (you are the customer). Impact 2: as nearly everybody must have some managerial skills, there is a training effort to undertake. The consequence will be more efficient relationships, because of knowledge about the terms, the language, and the basic and common principles or tools. It will be easier to understand each other and to work together effectively. Impact 3: the waiting risk is increased by the choice work / plan / wait for parallel subelements. Indeed, we may wait too much, and be late, or overrun costs by crashing (adding more resources to respect deadlines). In the other side, we may decide too quickly, and be wrong, and must have some rework, or changes in scope, time, cost or quality. Impact 4: as every risk, waiting risk is also an opportunity. So, this independent advancement state management may procure some benefits in terms of time, cost (especially cost of quality) and number of overall changes [6]. As we know that the quality cost may represent 12 to 20% of the total project cost, and that rework and errors due to bad requirements are strong parts of this cost, we can say it is a major gain in the overall planning management. Impact 5: as the risk increases and as the reporting accuracy is not so easy, there is an important place for trust between actors, or between actor and contractors [7].

5

Generalised multi-project management

The project managers, or sub-project managers, decompose their stuff into smaller and more manageable project (or deliverable). They assign a person accountable for each sub-element. The cycle is the same until they decompose a small deliverable (work package) into activities. Then, one of the Work Breakdown Structure branches is ended, but another branch may still be at a low decomposition level. We may have unbalanced WBS, or plans with some empty parts [8]. At the same time, we may have some sub-projects planned, other ones under development, and other ones validated. The planning is managed with only three functions.

6

Applications & perspectives

A perspective is the development by student projects of a shareware of some functionality listed above (the proposals' research output deliverables), like decomposition process assistant, assignment process assistant, historical information storage & search, graphical innovations for project vision and online links between project reviews decisions and project

ICED01-C586/563

275

plan. The purpose is that some industrials give money to finance the development of complete software, or of a module for existing software.

7

Key conclusions

We have introduced some improvements in project planning. They are based on PMI's standards, but many companies, which do not use such standards and so structured processes, may still use our proposals without the PMI's basis. They are independent (even some are linked) and can be applied separately. In summary, we give the project manager help to : •

decompose the scope of what he is accountable into smaller parts (deliverables or activities),

•

assign accountable person to these smaller parts (if it is deliverable), or carrying-out resources (if it is an activity),

•

manage and report the advancement state of the part he (she) is responsible of, and the risk that is linked with this state.

References [1]

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 and predictions". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium, 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 PMf Research 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 Management Network. Vol. 14, number 11, 61-63, November 2000.

[6]

Chapman— "Project risk management: the required transformations to become project uncertainty management". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium. 241-246, Paris, France, June 2000

[7]

Hartman F. — "The role of TRUST in project management". Proceedings of PMI Research Conference 2000: PM Research at the turn of the millennium. 23-28. Paris, France, June 2000.

[8]

Abramovici — "Long duration projects: the fixed rolling schedule". Project Management Network, Vol. 14, number 12, 47-48, December 2000.

Franck Marie Ecole Centrale Paris, Laboraloire Productique - Logistique, Grande Voie des Vignes, 92295 Chatenay-Malabry Cedex, France, (33)1-41-13-16-06, (33)1-41-13-12-72, [email protected] ©IMechE2001

276

ICED01-C586/563

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

APPLYING CONCEPTUAL DESIGN METHODS TO ENGINEERING MANAGEMENT P Hughes, C Burvill, and R Hughes Keywords: mechanical product design, business process re-engineering, competitiveness, design for manufacture.

1

Background

A review of the available literature discussing the management of product based innovation led to the identification of the following major objectives, meet market demands; compatibility of proposals to the company's long term strategy; continual generation of innovative proposals; appropriate technology support; a continuing mechanism for validation of decisions; and, maintenance of relationships with external organisations [1,4,8,10,15]. Also identified were the special needs associated with the management of innovation [3,7,13], The use of systematic design methods that provide a formal structure for the definition of problems and evaluation of design concepts [6,10,11] was considered a suitable basis for the development of management tools by a small Melbourne based engineering firm that specialises in mechanical product design (Integra Systems Pty Ltd). Design methods were successfully used to assist the firm in corporate decision making and the logical storage and analysis of information. Further, the tools created within the firm allowed the inclusion of new information over time and assisted in decision making that led to a series of changes to corporate strategy. This paper will provide a brief overview of the experiences of the firm. It is expected that the management techniques described will be applicable to other firms developing innovative products and services.

2

Introduction

A case study is presented that demonstrates the benefits available from the use of conceptual design methods in strategic decision making, in particular, those associated with evaluation of corporate strategic plans through the use of conceptual decomposition and evaluation matrices [13], The design tools facilitated flexible decision making with regard to the strategic planning, business development and management processes within the firm. The use of formal design methods for product and process development within the firm facilitated their use in the decision making process. This approach has assisted the following decision making processes: select the industry sector or sectors best suited to the firm's overall capabilities (table 1); identify opportunities for activities within the chosen industry sector (table 2); and, derive and continuously refine its company strategies to best exploit the opportunities within the chosen sector (table 4). The case study shows that formal design methods provided the necessary evidence to allow the firm

ICED 01 -C586/594

277

to redirect its business processes when necessary to ensure ongoing survival, either through the preferred approach within the industry sector, or through the choice of sector.

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 to introduce innovation to a manufacturing sector, the uncertainties associated with comparing available markets and the attributes of the organisation can be alleviated with an evaluation matrix [11]. Table 1 shows the evaluation matrix used to select the most appropriate industry sector for the firm under review - substituting industry sectors for design concepts, and necessary corporate attributes for design criteria. The overall expertise of the firm dictated that selection would fall within the manufacturing sector. The selection criteria chosen is broadly applicable although the concept ratings are specific to the firm under review. As there is typically no median or datum for comparison when attempting to enter an industry as an innovator, ratings were based on a quantitative scale rather than the alternate '+' or '-' approach, where '0' is the median. In table 1, '!' indicates low certainty or poor opportunity and '5' indicates high certainty or good opportunity. Within the case study, table 1 demonstrated that the firm's mechanical design expertise is high in all aspects of manufacturing engineering and that by reviewing the industry sector averages, the firm's principal areas of expertise were in the sheetmetal and toolmaking sectors. Table 1 also showed that punching and forming from sheet metal coil provided development opportunities.

4

The design of a business strategy

Morphology is a common tool for the development of alternative design variants [2,10], where a morphological chart will typically consist of rows divided according to the concepts (functions and sub-functions) of a design proposal, with columns identifying alternative solutions for each concept (variable). This approach has been applied to the identification of alternative approaches to business operation (table 2), where rows are divided according to business functions and columns identify attributes associated with the business functions. For the firm under review, this allowed a range of business operation variants to be defined with reference to the necessary concepts required for the business variant to be considered for implementation. The creation of the concepts and solution variables in figure 2 is an ongoing process that effects the attractiveness of alternative business variants. The creation of the business operation morphological chart in table 2 involved an extensive review of the chosen industry sector. Potential Failure Modes and Effects Analysis (FMEA) assists the engineering designer in exploring, to the extent possible, potential failure modes and allowing their associated causes/mechanisms to be addressed and evaluated [13]. This design tool has been applied to the assessment of business operation proposals (table 4) to assess issues associated with possible failure of a proposal, and facilitate quantification of the risks associated with the mode of failure. The modified FMEA in table 4 lists limitations associated with a business operation

278

ICED 01 -C586/594

proposal, describes the possible consequences and the likely causes. Remedial strategies are offered that may be able to correct the cause of the limitation. As for the business operation morphology approach, the use of FMEA to review corporate decision making accommodates ongoing changes to the business organisation and to the available market.

5

Application to an engineering firm - a case study

The firm under review used the tools described in section 4 to continually adjust its overall business strategy. The firm has attempted the following operational strategies and has been able to identify the strengths and weaknesses of each strategy: a combination of consultancy services and a range of relatively low cost, medium volume products; downgrade consultancy services and introduce a distribution service of internationally sourced high technology components; design and manufacture low to medium volume machines as products for sale that incorporate the sourced high technology components (providing a means by which technologies could be introduced to the chosen market); and, withdraw machines as saleable items and use them within a customised production cell where the technology advantage can be exploited when competing for manufacturing services (allows testing and refinement of the technologies in-house). These operational strategies evolved within the firm and as new proposals were defined, they were introduced to the review process and analysed against the existing strategies. The firm does not align itself to any one strategy to the exclusion of the others but applies the most appropriate strategy to each situation. Table 3 highlights the attributes associated with the product based approach (variant) to business operation identified by the firm from the overall chart (table 2). Opportunities that are outside the scope of the firm are quickly identified using this approach. Uncertain or critical variables are highlighted to assist the decision making process as these are associated with issues most relevant to the business strategy FMEA (table 4). Issues associated with the existing and proposed correctional measures were quantified using risk numbers. Benefits resulting from the introduction of the FMEA approach include: rapid identification of likely critical failure modes and the prediction of associated consequences; quantifying of the impact of the identified modes of failure relative to other modes of failure and to the associated mode following correctional action; and, provide a measure with which to assess proposals for operational changes within the firm.

6

Conclusions

Formal design methods have been successfully applied to the management processes of a small firm whose principal focus is product and process innovation for the manufacturing sector. Opportunities associated with this approach include: define the strengths and weaknesses of an organisation; formal selection of industry sectors that reflect internal organisational strengths; assess whether a proposed approach to business operation can be accommodated by the available resources; and, predicts whether limitations within the chosen industry sector (e.g. uncertainties and inconsistencies) are likely to be significant impediments to success. The case study demonstrated the successful use of these modified design methods. Applying formal design methods to management processes provided a framework for managing the firm in a creative manner, encouraging human decision making attributes such as intuition and experience. The framework also provides a means of recording and reviewing the opportunities

ICED 01 -C586/594

279

and ongoing changes within the chosen industry sector. As an example, a synthesis of attributes from the alternative approaches to business operation led to the design and manufacture of a sheet metal punching manufacturing cell (figure 1), combining coil based sheet metal expertise, advanced metal punching systems developments, and a well understood and documented overview of the sheetmetal punching industry sector. Using this approach, the company has been able to double its product based turnover each year over the last four years whilst rationalising resource levels through automation and reducing manufacturing costs. References fl]

Boag, D.A. and Rinholm, B.L., "New Product Management Practices of Small High Technology Firms", Journal of Product Innovation Management. V6, pp. 109-122, 1989

[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 Factors in 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 that work", 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 new products", 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 and innovation tti '99. Melbourne, Sep. 1999 [13] Samuel, A.E. and Weir, J.G., Introduction to engineering design. ButterworthHeinemann, Oxford, 1999 [14] Scherer, A. and McDonald, D.W., "A Model for the Development of Small HighTechnology Businesses Based on Case Studies from an Incubator", Journal of Product Innovation Management. V 5, pp. 282-295, 1998 Corresponding author Dr Colin R. Burvill Lecturer, Department of mechanical and Manufacturing Engineering, The University of Melbourne, Victoria, Australia, 3010. Tel +61 3 8344 4545, Fax +61 3 9347 8784, E-mail: [email protected]

280

ICED 01 -C586/594

Table 1. Industry sector selection (evaluation matrix) [8]

Industry Sector

MANUFACTURING ENGINEERING Sheetmetal Working Punch Profile

Industry 5 5 Experience Educational 4 4 Background Colleagues in 4 4 industry Computer 2 A Tools Plant & 1 0 Equipment Unexploited 3 5 Market Low Tech. 2 4 Sector High Labour 3 2 Content Breadth of 3 5 opportunities No technology 5 5 advancements 32 :;3:8; Totals

Toolmaking

Form

Mill

Turn

EDM

General Engineering

CNC Profile

Structural Eng.

3

1

4

4

4

5

3

5

3

4

2

2

4

3

3

3

3

2

4

2

2

4

1

1

3

3

2

2

4

2

4

1

1

4

2

2

2

1

1

3

2

2

2

2

4

1

4

1

4

2

4

2

4

5

2

2

5

3

3

1

1

1

3

2

2

1

4

1

4

2

5

0

2

0

2

5

0

0

5

1

1

4

4

0

3

0

0

3

0

0

1

0

5

0

0

0

0

0

0

4

5

0

0

0

0

4

5

2

4

5

2

5

1

5

4

1

1

1

2

4

2

1

3

1

1

1

3

1

1

1

1

1

2

4

2

5

5

4

1

4

1

4

2

4

2

3

3

3

3

3

4

3

3

4

1

2

5

2

5

4

2

4

2

1

1

4

4

2

2

2

2

4

4

4

5

3

1

5

1

5

4

1

3

1

3

1

1

4

4

1

1

3

4

1

3

3

3

3

5

5

3

5

5

5

2

5

2

4

4

4

4

4

4

2

2

4

3

3

3

3

23 25 28 32 43 3J 24 21 24 22 29 15 29 38 25 20 20 20 23 23 32 23 22 25 29 25

Table 2. Business operation morphological chart [7] Solution Variables Concepts

!

a

h

f

d

High Process Labor Content

No recent major advancements in technology

1

Industry Sector Opportunities

Identify unexploited markets

Low technology compared to related sectors

2

Company Focus

Locally produced innovative products

Import replacement

Value-adding imports

Synthesis of technologies

3

Production Functions

Materials Handling

Decoiling and Straightening

Material Feeding

Plate Punching

Plate Forming

4

Products and Services

I x)w cost - Medium volume products

High cost - Low volume products

A combination of 4a and4b

High Technology Products

Value added imported! product '

Business Development Funding Avenue for Market Penetration

Collaborations with Collaborations with Self funding through Self funding through other high technology R&D institutions consulting services product sales organizations

Joint ventures with ( other companies !

5

6

7

Barriers / Constraints

8

Personnel and Resources

9

Evaluative Measures / Process Refinement

I

,

Market directly

Market through distributors

Product and technology licensing

An upgrade path approach to product introduction

Create productsfrom! synthesis of in-house ' technology •

Meet industry sector or market demands

Market need for product / service

Levels of in-house experience

Available budget and cash flow

Delays in market , acceptance |

Multi-skilled team

Use personnel from other companies and research organizations

Low technology with High technology with high lahor low labor

Profitability

Market acceptance

_ . Serviceability

Evidence of Choice of Downsizing of Industry trends companies wanting to undeveloped Manufacturing Sector towards outsourcing specialize production techniques

282

Low synthesis of 1 technologies , | Offer High i technology Design . and analysis services [ to industry '

Stacking and Collating

Set-up and Changeover Systems

Manufacturing cells

Low volume machines

Technology cells and workcenters

Virtual 3D Design

External funding investors and financial institutions

Technology grants and Government assistance

Manufacturability

Available company resources

Available technology

Use of contractors

Access to required tools

Colleagues and associated companies with shared values

Reputation for product and service quality

Repeat orders / ongoing business

Customer referrals

Computer Based Failure Analysis

Industry based research

1 , |

! In-house efficiency - Selling horizon (I>ong! | _ vs. short selling cycle)' Cost vs. return

Market subject to uncertainty

Industry sector inability to embrace change

Predictive machine function simulations

Offline CNC programming

Clients downsizing in- Customers' perceived value of product / house production service facilities

Customer willing to follow upgrade path

Delay in bringing product to market

Time for market to accept product

ICED01-C586/594

Table 3. Business concepts and solution variables - strategy overlay for "product based" approach. Critical opportunities: low technology market (Ib) with high process labour content (Ic), no recent major advancements in technology (Id) and low synthesis of technology (le). Critical barriers: meeting industry sector or market demands (7a), market need for the product (7b), available budget/ cash flow (7d), delays in market acceptance (7e) and downsizing of in-house production facilities (7i).

a

b

1 2 3 4 5 6 7 8 9

c

d

e

f

g

h

i

j

k

•1

Figure 1. Sheet metal punching system - applying the accumulated knowledge of the firm under review within its chosen industry sector.

ICED01-C586/594

283

Table 4. FMEA [10] of business operation ("product based" approach). Risk number (RN) is the product of the likelihood of the business decision failing (O), the significance of the effect that failure on the firm (S), and the liklihood of detecting failure before it adversely effects the ongoing survival of the firm or the chosen business approach (D).

Existing Situation O S D RN

Business Strategy Analysis Limitation Limited market need for product Product innovation radical and advanced

Improved Situation

O S D RN

Limited market acceptance of product Inability to introduce products without comprehensive range

Cause Downsizing of manuf7 7 9 441 acturing industry sector Conservative market buying 8 7 9 504 patterns Range too complex or large 8 7 9 504 to manage with existing corporate structure

Prototyping and conduct 3 3 3 27 small scale market research 3D virtual prototyping and 2 2 4 16 computer based selling Liaise with other companies with complimentary 3 3 6 54 products

Unable to sell product with adequate profitability

Manufacturing costs too high

8 9 7 504

Modify products to reduce labor or material expense

Reduced customer satisfaction

Development times exceed market expectations

9 6 8 432

High cost of product R&D

Delays bringing product to market

Insufficient funds and resources

9 8 9 648

Product incompatible with existing plant

Limited market acceptance of product

Incompatibility with existing infrastructure

8 9 9 648

Product range not broad enough to satisfy market High technology products expensive in low technology market Product delivery delays

Consequence

Suggested correctional measures

Slow market penetration

O = Occurrence

S = Significance

Probability of occurrence

Effect on Business Development

Very low Medium low Medium Medium high High

1 2-3 4-6 7-8

Barely noticable Not detrimental to business Reasonably serious Detrimental effect on business development 9-10 High negative effects on business development

5 6 8 240

Communicate realistic time 2 2 2 8 frame for product delivery at the outset Collaboration with research 5 6 7 210 institutions to broaden available resources Create in-house solutions to 5 7 7 245 compete with users of existing plant

0 = Detection

Likelyhood of detection before business is Risk Number adversely effected 1000 I High 1 High 2-3 Medium high 2-5 Medium 125 6-8 Low risk 1 4-6 Medium 9 7-S Medium low 10 9-10 Low

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

FINDING AND IMPLEMENTING BEST PRACTICES FOR DESIGN RESEARCH ACTIVITIES M Gardoni and C Frank

Keywords: best practice, Knowledge Management, lessons learned systems, information analysis, classification and retrieval, design reuse

1

Introduction

The fast changing competitive environment in which most companies operate are forcing them to change their strategies in order to remain competitive. It is within the design activities that most impact on strategic objectives of quality, cost, delivery and flexibility can be made [1]. The challenge of design research is to develop and transfer new design concepts and technologies in order to prepare industrial design units to realise innovations in design methods and technologies. Some main design research activities are : strategic and technology surveillance, to analyse industrial design requirements, to put into context new design concepts, and to transfer new knowledge and technical solutions into industrial design units. Design research activities nowadays are confronted with a rapidly technology and industrial requirement change and therefore might need a support that helps to ensure the performance and capacity for research activities. Indeed, researchers have to spend time to organise and optimise their research processes in order to generate good results with the available resources. This could be a key argument for the use and the identification of "Best Practices". There could be a need to separate out the key and often-used practices and relate these practices to performance in order to present useful guidelines for action [2]. The aim of this paper is to propose a systematic way to optimise daily design research activities by finding and implementing Best Practices. We will describe where and how it could be possible to introduce Best Practices and illustrate our method. Furthermore we will discuss the probably existing relationship between Best Practices and knowledge management systems. We will illustrate that our method could lead to the introduction of a Best Practices Database which could be related with knowledge management activities. Finally, cultural, organisational and technical problems and constraints which are related with the introduction of Best Practices will be discussed.

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 have produced outstanding results in another situation and that could be adapted four our situation."

ICED01-C586/488

285

•

For Chevron, a large company in the United States, "Any practice, knowledge, know-how, or experience that has proven to be valuable or effective within one organisation that may have applicability to other organisations." Moreover, they distinguish different levels of Best Practices: Good Idea, Good Practice, Local Best Practice and Industry Best Practice.

We consider that the use of the term "BEST" Practice is not suitable because a practice can hardly be the best for all criteria: quality, cost, delay, etc.. Moreover a practice can fulfil the needs within a context but not within another one. We prefer then to deal with "Operational Advices". However, we will retain the term "Best Practices" because it is widely used. To harness Best Practices, we try to characterise their context and criteria in order to take into account most of their influential parameters [4]. To this aim, a special interest is given to use the Pattern approach. The purpose of this approach is to constitute a "Know-how base to solve a problem frequently occurring in a particular field" [5], Moreover, enterprise modelling methods such as CIMOSA [6], with the concept of modelling views and the generation principle, describe the behaviour and the functionality of a system from various modelling viewpoints [7]. These modelling views can be represented by a meta-model. The objective of this meta-model is to be at the same time generic, exhaustive and representative in a certain context. All these views can be related to the description of a design "context". Within this framework, various views of the characteristic elements of this context can be extracted from the meta-models. Moreover, we intend to use a skills model [8] to be able to compare the skills required to use the Best Practice and the skills owned by the users. The difficulty is to estimate the distance between these two instances of the skills model.

Figure 1. An example of skills model

3

Best Practices Management

Identifying and classifying fields for Best Practices applications for research activities is difficult. Voss et al. [9] argued through their research for the Made in Britain and Made in Europe studies, that companies which have achieved world class status have adopted Best Practices and achieved high performance in operational areas. Therefore, there is an argument to suggest that, by implementing Best Practices at the operational level, operational performance can be improved, and consequently the performance of the overall organization can be improved. Nevertheless, there seems tendency to use this expression for static processes rather than for dynamic ones which both could be placed in the operational level of an organization. Static processes are repetitive whereas the dynamic ones contain innovative

286

ICED01-C586/488

activities, making processes looking different. In an organisation, static processes could be optimised by a mechanism of comparison. So best solutions for common processes and problems can be generated. Design research activities are more or less structured in research processes and oriented by industrial requirements. Several activities in these research processes could be structured and optimised by Best Practices in order to make design research activities more efficient. We propose a formalisation of a method based on knowledge capitalisation cycle [10] to find improvements.

3.1 The knowledge capitalisation cycle The knowledge capitalisation cycle is characterised by four main steps in order to support the development and reuse of knowledge: locate, memorize, re-use and up-date. These steps can be described by several activities as seen in the figure below.

Figure 2. Knowledge capitalisation cycle [10]

Our method to generate Best Practices is based on these steps and activities. The knowledge capitalization cycle describes the activities how to capture and distribute knowledge. We consider Best Practices as being knowledge elements. This means, every Best Practice can be considered as a knowledge unit or as a defined set of knowledge units what could justify our approach which is based on the knowledge capitalization cycle.

3.2 One method to generate and transfer Best Practices Our proposition uses criteria on existing processes or parts of processes in order to create a better support for repeated tasks and implement Best Practices. Indeed, there is a need to define the relationship between Best Practices and performance in order to understand which practices should be implemented to improve particular aspects of performance. Performance indicators can and should be used as criteria in order to choose Best Practices and support processes. Our proposition (see also figure 3) begins with the identification and formulation of the need and the objective to improve the operational performance of a process or parts of a process. A specification of the problem and the requirements shows the tasks which could be improved. The need, or objective, should be reflected in the specification of a measure of performance which reflects the area to be improved, and helps monitor change and to identify a new Best

ICED01-C586/488

287

Practice. This phase and the identification of measurers might be difficult because of the lack motivations of the involved person. A common definition, with the help of meetings and interviews, might be helpful in order to identify the measurers. Before one can transfer Best Practices, it is necessary to define and find them: a phase of searching and evaluating of possible solutions. This research can be made inside and outside an organization. Approaches for identifying Best Practices could be: benchmarking teams, best practices teams, knowledge networks, and internal audits [3]. The framework of defined measures of performance specifies then a potential list of Best Practices influencing each measure. This list of Best Practices needs then to be evaluated and prioritised in terms of the strongest positive relationship with the measure, taking into account any negative side effects which could exist [11]. These activities of identification and specification are related to the activities "identify, locate, hierarchize" of the step "locate" of the knowledge capitalization cycle (figure 2). After the identification of the potential Best Practice follows the phase of transfer and adaptation: Transferring means to choose the Best Practices from the list of Best Practices which might be the best solution to improve the process. If necessary, this Best Practice has to be adapted to the new process and its environment. These phases of transferring and adaptation are related to the steps "memorize" and "re-use" of the knowledge capitalization cycle. The transfer and especially the adaptation of new Best Practices are probably the most difficult activities hi order to improve the operational performance. A new practice has to be adapted and accepted by an already existing system, environment, and by people. This system or environment is characterized by its organisation form and habits, by its using technologies and by the people managing this organisation, technology and process. Not only the Best Practice needs to be adapted to the new environment but also the system and the people need to be adapted to the new Best Practice. Therefore this adaptation process needs the competence of the people involved in this process. Methods for identifying the necessary competence [8] have to be applied before and during the adaptation process in order to ensure the necessary competence and resources which help and to transfer and adapt the new Best Practice. The skills model (figure 1) could assist to identify the existing and necessary competence in order to overcome people's problems related to the change of their module of thinking and working. With the help of learning and assisting processes required skills to use the Best Practice should be transformed into owned skills. In order to avoid problems with transfer and acceptance caused by people, the future users of the new Best Practice should be involved in the definition and selection process of this Best Practice from the beginning on. After transferring and adaptation, the Best Practice can be used for the new process. While using the Best Practice it is necessary to measure and evaluate the improvements with the defined criteria and measures described in the phase where the Best Practice was identified. If the expected results are not yet achieved, a re-adaptation of the Best Practice might be necessary. After evaluation of the results and after the complete adaptation of the Best Practice and the system or environment where the Best Practice is implemented, the Best Practice could be added to a "Best Practice Database" in order to make it accessible for other users and for other problems and processes which need to be improves.

288

ICED 01 -C586/488

Figure 3. Generating and transferring Best Practices

As mentioned in figure 3, the activities in order to identify, transfer, adaptation, use, evaluation and storage are representing a cycle of activities. This cycle structure supports our approach which is related with the knowledge management cycle.

4

Best Practices and knowledge management activities

The formulation and storage of Best Practices allows other actors to have access to different Best Practices. This may help to endure the Best Practices finding and implementing process. Moreover, it is also useful to track existing practices to maintain competitive advantage.

4.1 Knowledge management to support Best Practices transfer and adaptation The formulation and storage of Best Practices is important. Nevertheless, the simple storage of the Best Practice might be useless if actors do not know the environment and especially the context in which the Best Practice is used. Therefore we propose to formulate and store Best Practices always with their context in which they are used. This helps other actors to identify the useful Best Practices for their problem by comparing the context of the Best Practice with the context and environment of their problem. Knowledge Management activities and methods could help, with appropriate technologies, to give and formulate the context for a Best Practice. An example could be the MICA approach [4]. This specific interactive messaging system has been developed and experimented in order to harness non-formal information and to capitalise relevant information exchanges. Moreover, with other methods and technologies like forums, email, intranet, document management, etc. it could be possible to describe the reasons for the use of a Best Practice, the initial problem, the improvements, the criteria, etc. All these information are helpful for the identification and reuse of Best Practices. Knowledge management methods and technologies could allow to show and to formulate the connection between different use cases of the same Best Practice. One Best Practice might be used for different environments and for different problems and it might be interesting to track and to show the history of development of a Best Practice. The result of the interaction between knowledge management activities and Best Practises transfer and adaptation could be a map which shows the different Best Practices in their different context.

ICED01-C586/488

289

4.2 Best Practices to support knowledge management activities Knowledge management activities consist of a variety of methods, processes and technologies [12], [13]. Among these processes and technologies it might be possible to identify several repetitive processes or sub-processes. These processes could be supported be implementing Best Practices: Best Practices could help to improve knowledge management activities. There exists differences between knowledge management systems and the method of implementing and transferring Best Practices: A knowledge management system tends to be more complex since it manages evolving knowledge whereas Best Practices only focus on static knowledge. A knowledge management system tries to support dynamic and static processes whereas Best Practices support morels static processes.

5

Best practices supporting design research activities

Best Practices could help to organise, to improve, and manage design research activities Implementing Best Practices could probably optimise processes and sub-processes used for daily research activities. An example could be the constitution of a research report with Best Practices including propositions like how to structure, format, distribute, etc. a report. Moreover, we think that TRIZ methodology [14] could be useful to standardize design research activities. TRIZ methodology could be described through four main steps: 1. Once you have detected a real existing research problem you try to reformulate this problem in a way that you get a more abstract formulation of this problem. 2. You compare your abstract problem with similar problems. 3. You collect the abstract solutions for the similar problems and try to adapt them to your abstract problem. 4. You try to transform your abstract problem and the abstract solutions in your real problem with a real solution. This methodology shows, by formulating a method how to solve specific problems, that it is possible to introduce Best Practices for research activities and to help to find an efficient way of problem solving. Considering the TRIZ methodology a Best Practice a knowledge management method and technology might help to show, how, why and for which problems TRIZ is used by introducing the relevant context of each problem case where TRIZ is used. This allows actors to generate a map of different use cases of TRIZ with their relevant context, which can help to optimise the use of the TRIZ methodology for different but similar research cases. Another example of a method which could be defined as a Best Practice for design research activities is the functional analyse method. Once industrial requirements for design research activities are defined, it is very often difficult to identify the way of solving the problems and how new concepts and technologies could look like. We propose the functional analyse as a Best Practice in order to find efficiently new solutions, concepts and technologies for given design research problems. The functional analyse could be described through the following main steps: specification of the industrial needs and requirements; description of the context of the following research program (answering the three questions: for who, on what it has effects, what are the objectives); definition of the risks of the research program; description of the context of the system and characterisation of the solution which has to be developed; definition of the different objects, people, environments which could be in relationship with

290

ICED01-C586/488

the system and with the requirements; definition of the functions which need to be integrated in the system or solution in order to connect the different objects and to respond to the requirements; characterisation and description of the different functions. A further example for a Best Practice could be the MICA approach. Design research activities are often project-oriented activities defined through the specific project oriented industrial requirements. The MICA approach could be used by design researchers in order to support the definition and development of new design technologies and concepts in a project-oriented research environment. However, it is essential to keep in mind that Best Practices are based on static and standard rules whereas researchers need a flexible environment. Not every research activity can be optimised by introducing a Best Practice. People and culture are the key to transfer and create knowledge about Best Practices. A company needs a pro-sharing culture in order to be able to motivate the exchange of Best Practices. Elements of a pro-sharing culture are: Personal relationships, common areas of interest and expertise, continuous exchange and creation of new knowledge, learning through teaching and sharing, etc. Organisational and technical support should join the cultural support in order to guarantee an optimal exchange of information. An organisational support could be a monthly meeting of a Best Practices discussion group, a monthly update of company members about new Best Practices, etc. Technical support includes intranet technologies, technologies supporting the exchange of information, etc.

6

Conclusion

We consider the identification and transfer of Best Practices to be one of the possible tangible manifestations of knowledge management - the process of identifying, capturing, and leveraging knowledge to help organisations to improve their daily work processes and to compete with other organisations. Surrounding the process of identification and transfer, and helping it, are what one could call the enablers: technology, culture, leadership, and measures. These aspects of an organisation's environment and infrastructure must be addressed in order that the transfer process has a chance to work. Nevertheless, every organisation has to find its own enablers. After the identification of a Best Practice could follow the transfer and adaptation of this Best Practice in order to solve the problem related to a process. Moreover, the identification of a Best Practice could lead to process reengineering activities, involving people's competence and organisation form and habits, with the objective to achieve a better performance for this process. Further more, Best Practice development has to keep in mind the human factor. Our approach tends to give "meat - guidelines" in order to realize the transfer of Best Practices and has interfaces with knowledge management methods. However, this approach needs to be experienced in order to detail the different phases and activities. References [1]

Kochar, A.K., Davies, A.J. and Kennerley, M.P., Performace indicators and benchmarking in manufacturing planning and control system", in OE/IFIP/IEEE International Conference on Integrated and Sustainable Production — Re-engineering for

ICED01-C586/488

291

Sustainable Industrial Production, Proceedings of the conference held at Lisbon, Portugal, pp. 487-94, May 1997 [2]

Lynn, B.B., Schroeder, R.G. and Sakakibara, S., The impact of quality management practices on performance and competitive advantage, Decision Sciences, Vol. 26 No. 5, pp. 659-84, September/October 1995

[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 in Concurrent Engineering Environments", 3rd International Conference on Engineering Design and Automation, EDA'99, Vancouver, B.C., Canada, August 1-4, 1999

[5]

Gzara, L., Rieu, D., Tollenaere, M., "Product Information Systems Engineering: an approach by reuse of patterns", Proceedings of The Product Data Technology conference PDT Europe 2K., Noordwijk, The Netherlands, May 2-5, 2000

[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 Concurrent Engineering Environments", 7th ISPE International Conference on Concurrent Engineering, CE'2000, Lyon, France, July 17-20, 2000

[8]

Harzallah, M., "Modelisation des aspects organisationnels et des competences pour la reorganisation d'entreprises industrielles », PhD thesis, University of Metz, France, 2000

[9]

Voss, C., Blackmon, K., Hanson, P. and Oak, B., "The competitiveness of European manufacturing - a four-country study", Business Strategy Review, Vol. 6 No. 1, pp. 125, Spring, 1995

[10] Barthes, J.P., Grundstein, M., "Discussion Summary", 3rd International Symposium on the Management of Information and Corporate Knowledge (ISMICK'95), Institut International pour 1'Intelligence Artificielle, Compiegne, France, October 23-24, 1995 [11] Davies, A.J., Kochar, A.K., "A framework for the selection of best practices", International Journal of Operations & Production Management, Vol. 20, No. 10, 2000, pp.1203-1217 [12] Liebowitz, J., "Knowledge Management Handbook", Boca Raton: CRC Press, 1999 [13] Nonaka,I., Takeuchi, H. "The Knowledge Creating Company. How Japanese Companies Create the Dynamics of Innovation", Oxford University Press, 1995 [14] Cavallucci, D., Beyond the TRIZ limits, The TRIZ Journal, march 1998 Dr Mickael GARDONI GILCO laboratory, ENSGI, 46 avenue Felix Viallet, 38031 Grenoble Cedexl, France, Tel: (33) (0)4 76 57 43 33, Fax : (33) (0)4 76 57 46 95, mail: [email protected] Christian FRANK EADS CCR, DCR/IT, 12 rue Pasteur BP76, 92152 Suresnes Cedex, France, Tel: (33) (0) 1 46 97 37 02, Fax: (33) (0) 1 46 97 32 59, E-mail: [email protected] ©IMechE2001

292

ICED01-C586/488

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

LATE POINT DIFFERENTIATION ANALYSIS FOR CONFIGURABLE PRODUCTS T A Lehtonen, A O Riitahuhta, and J M Malvisalo Keywords: Configuration modelling, product methodology, design-for-X.

1

architecture, planning

and

workflow

Introduction

Late Point Differentiation is an important topic in variant production. This means standardisation early in the manufacturing process and differentiation at the end of the process. It is a cost-effective way of work and it is regarded as universally good principle in designing configurable products. However, reducing the cost of variety is not the only objective driving to use of late point differentiation. In this paper we focus on make-to-order products in a business environment, where delivery time is critical. We present an analysis method, which relates product architecture to the delivery time. Usually the purpose is to minimise the delivery time, by making changes to product architecture. The analysis points out modules, which are critical for the delivery time. This analysis provides information for contemplation, whether product design or production sequence should be altered. In the analysis the relations between sales properties and deliverable features are examined. This is done with a matrix where configuring decisions are related to assembled modules are presented in sequences of sales process and production/assembly process. Critical time line of the delivery is then drawn across the matrix. The relations on the left side of the line indicate acceptable design solution/production sequence, but the relations on the right side are likely to cause problems like re-work in assembly line.

2

Late Point Differentiation in time critical deliveries

Late point differentiation is often regarded as a tool for manufacturing engineering. However the manufacturing and assembly sequence is only secondary mean to achieve late point differentiation. Product architecture affect as a dispositional mechanism, which allows late point differentiation or ultimately makes is impossible. Applying late point differentiation requires: •

Product architecture is modular and modular decomposition corresponds to the needed variation. [1]

•

Production sequence is made according to add-on -principle. This means that base units common to all variants could be assembled first and variable parts could be added in later phase of the production. [2]

ICED01-C586/139

293

In this paper we focus on time critical deliveries. In these deliveries there are two more requirements: •

Production sequences should be optimised for sales-process.

•

In order to be able to optimise the product sequence also the product architecture should be refined (and adapted to requirements of sales sequence).

The late point differentiation analysis is a tool for this. The relations between product architecture and sales-delivery decisions are examined and the result is compared against production sequence. The main idea is shown in figure 1. The relations onwards (descending from top to down) are not a problem, because needed sales decisions are already made when production specification should be frozen. The relations backward (ascending from down to top) are problems, because the production/assembly should start before the specification is ready.

Figure 1. The main idea of Late Point Differentiation Analysis

On the left side of the figure above the decision that are made late in the sales process have relations to modules, which are needed early in the manufacturing process. On the right, there are no such feedback relations and manufacturing can be started simultaneously with sales process. The patterns beside each of the figures show the relational attachment of sales and manufacturing process in function of time.

294

ICED01-C586/139

3

Starting point of the analysis

The analysis requires a list of modules that are used in a configurable product family. Then modules should be arranged in sequence of production or assembly. The sequence could be also arranged according the lead times, if they are critical. Customer requirements are considered in this analysis as a form of sales (configuration) decisions. These decisions should be arranged in timeline according the sales-process. This is often a difficult task. According our experience, the sales process is seldom defined very accurately. The actual sequence of decisions in sales process is not readily obtainable, while it is critical for the analysis. Therefore, every effort should be given in order to get this information. There should be only one relation between a sales decision and a corresponding module, if the product is engineered according to strict functional module structure. However, this is hardly ever the case. In usual cases there are multiple relations between requirements and modules. The sales decisions are not always selections between pure functional properties and technical solutions often rule out the functional module structure.

4

Progress of the analysis

The analysis tool is based on asymmetric matrix. The modules of the product are being expressed in rows. The rows are arranged so that they are approximately similar to the production sequence. The first modules are needed in first production sequences. They are represented in first rows of the matrix. Similarly, the last modules, which are assembled last, are in the last rows. This is represented in the figure 2. If the lead times are taken in account, then those modules with longest lead times are in the first rows. The sales decisions are being expressed with columns. The columns are also arranged so that the first decisions made in sales process are in the first columns and the last decisions are in the last columns.

Figure 2. Setting the modules and sales decisions on the matrix.

ICED01-C586/139

295

Every sales decision is being examined and it's effect on modules are pointed out. The strength of the relation is also examined. If a sales decision has an very strong influence on to a module, the value of the relation is set to 9. The value is 3, if the relation is moderate. If there is only minor interaction or correspondence between a sales decision and a module selection, the value is represented with 1. This 9-3-1 division stresses the strong bonding and it is very similar than those used in QFD-method [3]. Analysis can be drawn, when all relations are marked in the matrix. To be able to do this, acceptable time relation between sales and delivery -processes should be drawn across the matrix. Simple diagonal could be used, if delivery and sales-processes would be both linear and synchronous. In that case all relations at the lower left corner of the matrix are forwardtype and will not cause problems. The relations above the diagonal are backward-type and they indicate problems in sales-delivery process. However delivery and sales-processes are seldom, if never, linear and synchronous. Instead there are decisions and tasks that are being made and done simultaneously. The progress is everything but linear. Therefore, instead of simple diagonal a better estimation is needed. In our case, we used workflow diagram as starting point. Suitable workflow diagram is a simple Gantt chart as shown in figure 3.

Figure 3. Gantt chart work-flow diagram.

In figure 3, the tasks are on the rows and the calendar time is running from left to right. The bars show the duration's of individual tasks. Ideally, there would be a one-to-one relation between the tasks and the modules. This means that one task includes manufacturing and assembling one module. In reality this is usually not the case, but tasks are manufacturing stages that are related to many modules. The chart may be converted to show modules by marking the modules to the task where a module is first needed in manufacturing process (or where it's lead time is encountered). The timeline, which would guarantee progress without iteration, is estimated according to this diagram. The example of a result can be seen in figure 4. The fraction line across the matrix shows a similar shape than the workflow diagram. In this case there was one task, which took very much time and is related to many modules. This causes the bulge to the right in the fraction line. In the figure 4 the fraction line shows, which relations between sales decisions and modules are suitable for current sales and manufacturing process. The relations left of line would cause no problem, but relations right from the line would cause iterations in the manufacturing process. The bulge to the right in the fraction line is caused by one task, which takes long time

296

1CED01-C586/139

to perform and requires many modules. The tasks of this kind are problematic for the analysis because it would be critical to know if a module is specified, selected or even needed at the start of the task.

Figure 4. Example of Late Point Differentiation matrix.

5

Results of the test case

A test case with the proposed tool was conducted in a company delivering heavy mobile machinery. The objective of the company is to deliver configured products instead of earlier project oriented way of work. This will require modular engineering in product development, which should thrive for assemble-to-order approach in production. In this case, only streamlining assembly was examined and lead times were not considered. The product was a revised version of an old product in the test case. As this was a case of revised product, many known problems were already corrected. The result of the analysis showed that product was quite satisfactorily adapted to current production/sales processes. However, many problems were pointed out. It is noteworthy that almost all causes to them were new features in the product. It seems that the aspect of variation is not very much considered, when new features are being designed. In the case of

ICED01-C586/139

297

old features, problems in assembly had been encountered and they were ironed out by gradual product improvements. The need for this kind of analysis at product development stage was acknowledged in the company. The result was verified also by making survey amongst the product experts. The answers had good relevance to results of the analysis. One general notation was that all experts underestimated problems that were in their own responsibility area.

6

Conclusions

The paper presents a method where late-point-differentiation is analysed using Design Structure Matrix (DSM) type approach [4]. This method does add time element to the relation matrix in the form of critical time line. This is required when analysing Late Point Differentiation and it is a novel approach. Proposed method will also enlarge the focus of late point differentiation thinking. Not only the assembly order is regarded, but also lead times could be taken into account. Late point differentiation analysis is a usable tool for industry with firm methodical background. It provides effective ways for guiding the design and discovering problems in advance. It requires thorough co-operation between sales, design and production people and so encourage applying integrated product development [5]. ACKNOWLEDGEMENTS The authors would like to thank the personnel in the case company for their efforts. We also acknowledge National Technology Development Centre of Finland (TEKES) and the case company for funding the research presented here. References [1]

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 and Productivity International Conf., Honolulu, Hawaii, 1991

[4]

McCord, K.R., Eppinger, S.D. "Managing the Integration Problem in Concurrent Engineering", Working Paper no.3594, M.I.T. Sloan School of Management, Cambridge, MA, 1993

[5]

Andreasen, M.M., Hein, L. "Integrated Product Development", Institute of Product Development, Copenhagen 2000

Time Lehtonen, Asko Riitahuhta Tampere University of Technology, Machine Design, Box 589, 33101 Tampere, Finland Tel: +358 3 365 2627, Fax: +358 3 365 2307, E-mail [email protected]. aor(ajme.tut.fi Jani Malvisalo Fastems Oy, Tuotekatu 4, 33840 Tampere, Finland, E-mail Jani.Malvisalo(5),fastems.com ©IMechE2001

298

1CED01-C586/139

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

ON THE DESIGN OF SERVICES R Andrade

Keywords: Service design, design strategy.

1 Introduction Developed and emerging countries have in the service sector the main contributor to their economic activities. Multitude of services have been and are being created and operated in very diverse environments. Those services are designed somehow. Be it by highly systematic approaches, by pure trial-and-error, or by some combination of these design strategies. Nevertheless, those involved with the creation or operation of services and interested in achieving competitiveness and efficiency may be frustrated with the meagreness of references on services design. Despite the interest raised by the matter in the academy, books dealing with the fundamentals of the subject are few, as may be verified by searching booksellers through the world-wide-web. Two books where the authors apply engineering design methods to the design of services stand alone [1,2]. What is found, on the whole, is the occasional chapter in books on service management and operations [e.g. 3, 4] presenting generic ideas about service design. On the other hand, there is a great deal of information and activity on approaches to engineering design, as epitomised by the ICED series. Remarkably, the word service was nowhere found in the theme, topics, or keyword list sections of the call for papers for the Conference in 2001. Why is there this void? Is it because engineers have nothing to do with services? But they do! Levitt [5 Ch. 3], a keen thinker and renowned author on marketing and management, wrote that in industrialised countries services can be industrialised in three ways: via hard, soft and hybrid technologies and gave a list of examples that would delight any engineer. Hewlett Packard, recognised for its excellence in engineering development, presents in a page related to products & services in its site at the world-wide-web the following topic of its strategic priorities [6], with my highlights: "Create e-services ecosystems that place HP at the center - With its multi-pronged strategy focused both on present needs and on creating a roadmap for the future, HP's printing e-services strategy will drive the development of inventive Internet printing appliances, services and infrastructures that will make printing and imaging as integral to the Internet experience as is e-mail today." Aiming at the creation of ecosystems the company indicates that those appliances, services and infrastructures have to be integrated and interdependent. The development of integrated products and services is the challenge posed to industry these days.

ICED01-C586/480

299

Fundamental approaches to design are reviewed in this paper in order to address services as a solution for satisfying customer needs through a combination of objects, procedures and people. It is proposed that design of services ought to be approached as design of systems where those elements comprising the design solution will come into the system as a result of how design specifications are satisfied rather than induced at the onset of the process. The problem of integrating people as an active thinking part of the solution is discussed.

2 Services versus Products Designing is basically a process of engendering solutions for satisfying a set of needs. These are organised as design specifications, DS, which is a kind of genetic code of the engendered solution. A complete DS also describe conditions and requirements to be complied by the solution along its stages of development, use and disposal [7]. The most adequate result of this engendering process will be the solution that best satisfies the DS. However, a fascinating characteristic of the process is the possibility of generating several alternative solutions for the same design specifications. Mainly because: i) specifications are not satisfied in exactly the same manner; ii) there are many attributes that are specified in ranges of tolerance; iii) information to elaborate the specifications is imprecise and incomplete. All these allow enough degrees of freedom for the solutions to be varied and yet adhere to the design specifications. A solution may take two fundamental forms. It can be a physical structure, an object such as a cloth pressing iron. It can be a procedure such as a computer programme or a package delivery scheme. Rather than being a natural result of the design process the form of the solution may be induced at the process onset. At this point, asking for the design of a cloth pressing iron will induce rather different results than asking for a mean to keep the cloth without wrinkles. Broader specifications are formulated if hidden assumptions are surfaced and altered when the set of needs is considered. That will facilitate the widening of the field of solutions. Stuart Pugh, always pugnacious about the paramount importance of design specifications as the sole reference for the design activity, proposed the static-dynamic product status as a framework of thought [8, Ch. 19] for broadening up the design specifications when formulated. Broader specifications open up opportunities for innovative solutions that break away from static concepts commonplace. The static-dynamic product status is a necessary consideration in service design. Differentiation between service and product is one of the issues related to service design and management. Package delivery would be immediately recognised as a service and a laptop computer as a product. A major difference between a product and a service, as both are largely perceived, is how people are made part of the design solution. For products, the buyer is solely responsible for its use and operation, like with the laptop computer. The manufacturing company transfers that responsibility to him. Services are processes in which some or all actions required to run them may be done by the service company personnel. The buyer may be passive as when he orders a package to be delivered.

300

ICED 01-C586/480

However, categorising what is a service or what is a product do not help the design process much. Such categorisation is illusive, constrains the conceptual phase of the process and increases complexity. When we look at an automated teller machine, ATM, are we looking at a service or a product? When we use an ATM are we using a product or a service? How relevant is this for the user whose interest is to do her banking transactions? In fact, the ATM is part of a solution system comprising objects, procedures such as software or rules of operations, and people that work together to execute bank transactions satisfying the customer and the service company. What about package delivering? What the customer cares is to have her package safely delivered on time to the right hands at a reasonable cost. What would be the solution to satisfy her needs? Surely it depends on the package itself and how fast and how far the customer wishes it delivered. One person of the package delivery company may easily take an envelope with documents sent to another office a couple of kilometres away on the same road. He may go through very simple procedures for collecting and delivering, may travel on foot, and require no particular object to perform his actions. On the other hand, to take live fish from fish farms to sophisticated restaurants that serve fresh food could require special procedures, specific objects, and involve several service people. When a designer is briefed to provide a solution for the restaurants needs she will be faced with devising objects and procedures to do the job. If these are not fully automatic, the designer will have to employ people to run them. What and how many objects, procedures and people are going to be involved will depend on the conditions constraining the solution and on the adopted design strategy. Instead of being concerned with categorising the solution as a service or as a product, designers ought to be looking for the best solution for the problem posed, obtaining different ones by varying the combination of objects, procedures and people into the solution system. How the elements of the solution system are combined is a design decision based on the business strategies of the service company. The solution system provided by a hammer manufacturer might be restricted to the object hammer. The people to operate it and the operating procedures will be decisions transferred to the customer. A taxi company, in its service, could provide the object car, the personnel to operate it, and leave in the hands of the customer the procedures for going from the origin to the destination. In the service in a surgery ward at a hospital, the objects, the operating personnel, and the procedures are very much within the control of the organisation providing the service. The customer is passive.

3 Designing Services Most design practitioners will agree that design of services may be approached as design of products as shown in the two books referred at the Introduction. Hollins&Hollins [1] paved the way and brought along some of Stuart Pugh's teachings on total design [9] with whom Bill Hollins had an academic association. Ramaswamy [2] came a few years later under the influence of Clausing's total quality development methodology [10]. These books teach how to structure the service design process and to apply valuable supporting methods and techniques to service development.

ICED01-C586/480

301

Nevertheless, why is it that the word service is not even mentioned in the whole call for papers of an important design conference such as ICED? The hypothesis is that this is due to the presence of people as an integral element of the service process Traditionally, service development and operation rely on human abilities, of both the servicing personnel and the customer, to cope with unpredicted situations and to negotiate ways to have the service process completed. Humans have the marvellous faculty of adjusting to non-conformities or to unforeseen situations in processes. When discussing how services are approached Levitt [5, Ch. 3] wrote that for historical reasons "service took the form of one person's labour for the benefit of another....performing one-on-one highly personalised service....just right to the exact specifications of each familiar customer in the shop....[creating] a presumption that service literally means, and will be best, when one person directly and personally attends another..." Such approach to services may bring flexibility to the service company but may also create undesirable situations. Customers are insatiable. When faced with a serving person that apparently has some power to decide and act upon service processes, a customer may relentlessly pursue the opportunity to have things done his way. In some cases the service company yields to the customers' unexpected demands. A couple of hours at a check-in counter in the airport will reveal several of these. However, fulfilling those demands is not always reasonable, feasible, or desirable to the company. Denying their satisfaction may create insurmountable conflict at the interface between the serving people and the customer to the point of disrupting forever any business with that customer. Person-to-person relationship induced service development and operation to be largely done as an ongoing trial-and-error process of adjustment, thus creating the impression that it is not feasible to project services operating with repeatability, reliability, and robustness by design. Yet, there are several evidences around showing that this is doable. Air travelling is a clear example. Efficient services may be systematically designed and variation in behaviour and mistakes that people are bound to make may be prevented by adequate training, fail-safe procedures, and redundancy of people like a pilot and a co-pilot. The notion that services are basically exchanges between a serving person and the customer shies engineers away from service design since they usually feel ill equipped to deal with human-to-human interactions. On the other hand, non-engineers involved with design of services are also prevented from taking advantage of the immense technological advances available today due to a lack of technology awareness and the perception that only humans can provide what the customer wants. The latter is true for a number of circumstances where human warmth and emotional presence are important. However, in many cases the serving person is only there because long ago the provision for the customer needs was set that way and the reasons for that were never challenged. The banking transaction system supported by ATMs is a case-in-point of successful challenge and change of the traditional clerk-at-thecounter service. Now we may take months without need for seeing or talking to any person in the banking organisation. Concern with human factors in design has increased dramatically in the second half of last century. Largely with greater focus on the customer and lesser on the serving people. The rise of ecological awareness and of enforcement of product liabilities also drew attention to

302

ICED01-C586/480

consequences brought onto the public in general by products or services. Nonetheless, what is understood by design with people in mind, broadly speaking, is the avoidance of circumstances that are uncomfortable, ambiguous, risky, or demand unduly physical or mental effort. On the whole, people are being cared for but they are still passive pieces in the solution system. What is lacking is how, by design, to take advantage to greater extent of human faculties. Designers ought to make an effort to integrate people to the solution system with freedom to apply their intellectual and emotional abilities to run the service process successfully. The intent of this paper was to speculate on the design of services in an attempt to clarify why methods for systematic service design are so rare. I believe that the main reason is the inability to deal with people as an active and thinking element of the solution. Services are processes and service design ought to be approached as a quest for solutions to satisfy customer and company needs through systems that integrates objects, procedures, and people operating in coordination. The problems of designing services are: • To devise the service system and define its elements: objects, procedures and people. • To engender the objects • To develop the procedures • To incorporate people regarding their human faculties • To integrate the system elements to work in coordination. Designing such systems has to be a multidisciplinary team task involving the fields of engineering and human sciences. A service design team should comprise, or at least involve, engineers, marketers, psychologists, sociologists, anthropologists, and professionals that work as interface between the service company and the public such as sales and help desk people. Such a team, working together from the formulation of the design specifications, will have good conditions to create innovative and efficient services that benefit from technological advances and constructive people behaviour. Some basic steps at the start of the design process are recommended: 1. When gathering information about what is needed and formulating the design specifications, challenge the requirements and constraints in order to surface hidden assumptions that may preclude the generation of innovative solution concepts. The challenge is simply done by asking why or why not are those requirements or constraints there. 2. Look for the solution in terms of an integrated system of objects, procedures and thinking people. Not as product or service. 3. Establish required and desired relationships and interactions between objects, procedures and people in order to integrate the system. 4. Consider the service system as a process in which its parts have to work in coordination in order to satisfy the customer and the company. As for the methods for service design, those that are used in engineering design and are technology independent [8] are just as adequate for structuring and taking the design process to the stage where concepts have to be made real, a transition often called embodiment by engineers. From this point on, specific technical knowledge is required and the methods used in the different fields of study come to play.

ICED 01 -C586/480

303

4 Conclusions The great difficulty in designing services is how to design people into the solution coping with and using effectively the human behaviour. Such problem remains hidden and unresolved in systematic service design. Yet, design of services might not be as complicated or difficult, as it may seem to engineers. The obstacle posed by the necessity of understanding people behaviour is overcome by multidisciplinary teamwork. However, it is not compulsory to have serving people in services. They should be there as the best alternative to provide customer and company satisfaction. Technology must be applied to provide solutions that prevent people from working in tedious and intellectually undemanding processes. Creative application of technology will generate solutions that will put people in tasks more consonants with their human faculties. Service design is an open and barren area for design engineers. The methods of engineering design coupled with the vast knowledge on human behaviour are powerful tools for the creation of innovative alternatives in services. References [1] Hollins, Gillian and Bill Hollins. Total Design: managing the design process in the service sector. Pitman Publishing, 1991. [2] Ramaswamy, Rohit. Design and Management of Service Processes: keeping customers for life. Addison-Wesley, 1996 [3] Lovelock Christopher H. and Lauren Wright. Principles of Services Marketing and Management. Prentice-Hall, 1999. [4] Hasksever, Cengiz et al. Service Management and Operation. Prentice Hall, 2000. [5] Levitt, Theodore. The Marketing Imagination. The Free Press, 1986. [6] http://e-services.hp.com/infolibrary/white_papers/eserv_print_rev.html accessed in 28/01/2001. [7] Andrade, Ronaldo. "Preliminary Evaluation of Needs in the Design Process", Proceedings of the ICED 91, Zurich, August 1991. [8] Pugh, Stuart. Creating Innovative Products Using Total Design, Addison-Wesley, 1996. [9] Pugh, Stuart. Total Design, Addison-Wesley, 1990. [10] Clausing, Don. Total Quality Development, ASME Press, 1994.

Professor Ronaldo Andrade Departamento de Engenharia Industrial, Universidade Federal do Rio de Janeiro, caixa postal 68507, Rio de Janeiro, RJ 21945-970, Brasil, Tel: + 55 21 562 8562, Fax: + 55 21 290 6626, E-mail: ronaldo.andradetgjufri .br ©IMechE2001

304

ICED 01 -C5 86/480

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

FUNCTIONAL PRODUCTS CREATE NEW DEMANDS ON PRODUCT DEVELOPMENT ORGANIZATIONS O Brannstrom, B-O Elstrom, and G Thompson

Keywords: Functional Products, Integrated Product Development, Service Design, Service Management, Competitiveness, Whole Life Cost

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 or control systems, increasing the complexity of product development work. The products themselves also require significant services to support them, many critical for their use and hence their value. Accordingly, Normann & Ramirez [1] argue that it is no longer possible to draw a distinct border between products and services, as all products include services vital for their value. Today, in professional Business-to-Business relations, we believe that the customer is not only judging the value of the hardware, but rather the value of a total offer. This phenomenon is not only a market pressure, but is also a driving force in order to offer the market a unique product through product differentiation. According to Nordstrom & Ridderstrale [2], product differentiation will no longer be about the hardware, but rather through a unique total offer including both tangible and intangible assets, such as knowledge, financial offer, service deals, etc. In our view, this results in a need to further widen the scope of product development work into a "total offer". Although the authors all have their professional backgrounds within the engineering field, we belief that this is a subject that requires an open minded use of knowledge from a number of areas. The objectives of this paper are to describe how a new market situation put new demands on product development organisations. Also, we will propose a structured product (total offer) lifecycle model that integrates all value adding activities within a company. Especially, we aim to determine what demands this new scenario puts on the engineering design activities within a company.

ICED01-C586/606

305

2

Background

In respect to previous research, the development of a total offer overlaps a number of research areas, including integrated product development (IPD) of goods, service management and development and industrial organisation. In the following sections a brief outline of the salient theory from each area is given.

2.1 Integrated Product Development (IPD) The areas of IPD and Design Science have produced a lot of research results concerning how to best develop physical products. Results from e.g. the WDK School can be found from the early eighties, and early work done by Hubka [3] is still used as reference for researchers concerned with structured product development models and processes. Other well known example are Pahl & Beitz [4] and Pugh [5] who all present structured frameworks, or models, describing the process of product design. We find the area of design science and IPD being both mature and vital. Still, research in the area have been focusing on physical products, and in line with our objectives we will try to use knowledge from the area as a step stone to a development model in a wider sense. One might argue that the integration in IPD aims to cover development in a wider sense than engineering. This is true to some extent, e.g. Andreasen & Hein [6] include activities apart from engineering in their IPD model, however they do not include services a mainstream item. Although taking into account other aspects apart from engineering, we still find it aimed at marketing, developing and producing a physical product. The generic development process presented by Ulrich & Eppinger [7] includes different types of activities, mainly marketing, design, and manufacturing, but also other activities, such as finance, legal and service. But once again, we find that the development process deals with physical products. There is no process for developing or verifying services. What we like to bring forward with these references is not that they are insufficient to our purpose, but rather that they provide an important framework in the work of developing total offers. Important reasons to adopt a well-defined process in product development are: quality assurance, co-ordination, planning, management and improvement [7]. For a company trying to integrate its value adding activities, these are vital reasons to choose a product development like approach to develop a total offer.

2.2 Changes in the marketplace Maintaining our view of IPD as a mature and vital area of research, and practice, we still claim that it is no longer holistic enough to cover the needs of every modern company. To understand this we have to understand that the area of IPD has its roots in the paradigm of scientific management, starting with Adam Smith and his pin-fabric that he made famous in late eighteen century England. According to Gronroos [8] most of today's management principles are based on a scientific management perspective, a perspective that focuses economy of scale and mass production [9], Generating customer value within the mass production and mass consumption economy was, and still is, done through selling the customer single products or services. But the means for competition have changed, and the markets are undergoing major structural changes [10]. Gronroos [11] points out maturing markets, an increasing global competition and customers demanding individual offers and treatment as part of the emergence of the post-industrial society. Or in a few words, companies of today are facing increased competition and more demanding customers. In this situation, competition through single products becomes hard, if possible at all, and competitive advantage often has to be found elsewhere. Accordingly, product differentiation

306

ICED01-C586/606

will not only be about the hardware, but rather through a unique total offer including both tangible and intangible assets, such as knowledge, financial offer, service deals, etc. [1]. But as focus is shifted from transactions and products, new demands on how solutions to customer problems are to be developed emerge. Grb'nroos [11] argues that a total service offer must be designed, and that this requires the firm to manage resources such as people, technology, know-how and the customer together with the product.

2.3 Service management and development According to Gronroos [8] service management is a perspective of a number of disciplines, including operations, total quality management (TQM), organizational theory and human resource management. It includes some general shifts in the focus of management: 1. From the product-based utility to total utility in the customer relationship. 2. From short-term transactions to long-term relationships. 3. From core product (goods or services) quality or the mere technical quality of the outcome to total customer-perceived quality in enduring customer relationsships. 4. From production of the technical quality of products (goods or services) as the key process in the organization to developing and managing total utility as the key process. In a company applying a service management perspective, a traditional product development approach within a specific product development department is not enough as the development of services integrates activities from a number of departments in the company to develop all parts in the service system [12]. According to Edvardsson [10] there are three main components that build up the service offer: The service concept, the service system and the service process. The service system defined by Figure 1 represents the resources required for the service and is important in this context as it implicates vital differences in designing services compared to physical goods. The service system can be divided into two parts, the interactive part (front office) and the support part (back office). It is the interactive part that is visible to the customer.

Figure 1. The Service System (Edvardsson [10])

We will not describe the different parts of the service system in detail, but we would like to emphasise some important points. In the service system the customer has a role as a coproducer and user, while the customer traditionally in the case with physical goods normally have the user role only. When designing a service system we have to keep in mind that although the word "system" is used in this context, it is not a system of natural science, but a

ICED01-C586/606

307

socio-economic system, formed by its cultural and political context. The service system is what Chekland [13] refers to as a "soft system", meaning that it will not have the repeatable and logically predictable behaviour of a technical system. Accordingly, all models of a soft system, e.g. the service system, will not be representations of it, but merely intellectual devices being used to explore them [14]. According to Norling [15], the most significant difference between a manufacturing and a service company is in fact that the service consists of sets of activities that may not be standardised and quality controlled in the same way as with physical products. Also, the interfunctional dependency between e.g. marketing, finance, production and administration are higher in services as they all contribute simultaneously in the service interaction with the customer [16].

3

Industry survey

An interview study was carried out within Swedish industry to explore industrial perceptions of, and beliefs about, 'total offer' products. As our aim was explorative, a survey approach was selected [17], and interviews were carried out in a semi-structured form with a total of thirteen executives at eight different companies. The interviewees were selected due to their holistic view of the company and typically the persons interviewed where Chief Executive Officer (CEO), marketing directors or, in the larger companies, persons responsible for company strategy or future product concept development. Unfortunately, all companies demanded to be anonymous in all external publications as a condition for their participation due to the sensitive information they shared with us on a strategic level. The companies selected represent different types of companies, ranging from large hardware manufacturers to consultant companies. All of the companies have mainly a business-tobusiness focus although some of their products end up at consumers. Even if all of the companies in the study were Swedish, they all act on an international market, some in Europe and some worldwide. To verify the results of the interviews all interviews where recorded and the participants received a written copy. In some cases the interview results was discussed with the interviewees, but in most cases we just received a positive answer that the result was correct. A text analysis was performed, and being an inductive study we searched the material without prejudiced to find categories to structure the material.

4

Results

In this section we give a brief presentation of the results from the survey. Two aspects will be addressed, each company's view on how to generate customer value in the future and how that view will affect their development operations. Instead of selling only isolated products or services, the companies want to sell integrated solutions or concepts with responsibility for performance and reliability. This means taking over non-core business from the customer to reach economy of scale and co-ordination spinoffs. Some of the companies emphasised that they wanted to take the knowledge heavy position in the value chain, thus integrating several sub-contractors into a joint offer. Figure 2 below summarizes the answers on how to generate customer value.

308

ICED01-C586/606

Figure 2. Generating customer value categories

The importance of being more closely connected to the customer compared with today was strongly emphasised, and to be integrated in his work processes to understand the true customer needs. Three of the companies expressed that they had to be able to understand the customer situation in order to improve not only their own processes, but also the customer processes. A number of companies brought forward a change in customer and sub-contractor relations. They claim to move away from the traditional buy-sell transactional relationship except for low price large volume goods. Instead they are moving into a more integrated relationship where the boundary between the different companies becomes more diffuse. Company 1 expressed that it was sometimes difficult to even know who to charge or who would get paid, as the integration was so close. All the hardware vendors in this study expressed that they had quite mature hardware processes and only one of them expressed the need for enhancing them further. With that we are not saying that those process are completed or beyond further development work, but it is an indication of where these companies will have to put in their effort in the future. More than anything else it is pointed on the need for service processes. Especially one of the companies (Company 1) is concerned about the performance measurement of services and proposes a hardware-like approach for dealing with services. Also, they claim that only well established work processes could result in services being uniform and scalable. Generally, an important part of future development work will be to develop work processes and procedures for service production. Three of the companies express worries about how to manage the integrated development work of total solutions, especially the integration of hardware with services.

5

Analysis and discussion

The results from the interview study support our initial assumptions, i.e. the companies in the study want to sell the customers complete solutions with an increased responsibility for function, performance, reliability, etc. But the companies also emphasised a new relation to the customer. A relation where the traditional buy sell relationship was abandoned for collaboration and the achievement of common goals. Generating customer value in the future is to provide the customer with complete solutions to maximise his profit through cooperation. Instead of just selling the customer single products or services, the companies have

ICED01-C586/606

309

to be able to understand and support the customers' value adding activities, or in other words, help the customer in building his value-chain. We propose a model that combines the lifecycle processes of hardware, software and services (Figure 3), which build up the functional product.

Figure 3. Lifecycle model for functional products

Illustrated in this model is the presence of three parallel development processes, each contributing in a combined effort to provide the customer with the desired function. It is important to note that although the processes are pictured as separate, there is obviously a need for a high degree of interaction between the processes. This is especially true in the concept phase where there is a high degree of creativity. The processes steps should not be seen as a strict sequence, rather they tend to overlap each other in practice. It is also important to realise the difference in life-cycle length between the different product components. While the lifecycle for a jet engine hardware, from initial idea to last engine scrapped, is in the order of 30 to 50 years, the embedded software control system might have a life span of ten years and the service might be replaced every year. The concept of functional products that include hardware, software and services has significant implications for engineering designers who have been concerned principally with hardware. It has long been recognised that, under many circumstances, maintenance and failure costs can be as significant as the initial product cost. However, it continues to be a difficult argument to persuade clients to pay high initial costs in the expectation of future savings when selling just hardware. In the case of functional provision, such arguments are redundant. There is no requirement to convince anyone of the need to invest now for future savings when the functional provider decides the optimum balance between initial cost, maintenance and failure costs. The designer then discovers previously unrealised freedoms and has many opportunities for creative thought. A decision may be made to increase initial cost and to spread the cost throughout the expected life of the equipment. Or, initially low cost hardware may be designed that can be supported cost effectively in the field. Alternatively a high value 'core' may be designed for the hardware that forms the basis of periodic remanufacturing. Altogether, there are now opportunities to apply all the life-cycle

310

ICED01-C586/606

cost and design researches that have been carried out under the banner of Terotechnology in recent decades. The difference in nature between the service system and the technical system implies challenges for the development organisation. Being able to handle traditional engineering activities will no longer suffice. In some cases the single employee is to the customer synonymous with the organisation, and it will be his/hers motivation, training and access to resources that will decide the functional products availability. What we must do is to design attractive jobs and a stimulating environment that promotes employees with the right motivation, experience, motivation and enjoyment [10]. It requires integration of all activities in a company, and departments usually without a product development focus, e.g. human resources and after market, will find them selfs being part of a functional product development effort. The time is past when some people in a company developed a product, now everyone in a company will find them self being part-time developers. Managing all these part time developers will certainly require a well-structured development effort. As a service system due to its 'soft' nature is formed and affected by its cultural context, the behaviour of the system will not be obviously transferable between different customers, branches or countries.

6

Implications

Industries competing in today's changing market will have to carefully consider how to approach the problem of functional product development. Especially, the after-market activities must be considered as an integrated part of the product and accordingly developed. Research in the area of development of functional products overlaps different areas in the research society. Future research must fill out the gap between the long research traditions within service management and integrated product development, the former traditionally a business school subject and the latter traditionally an engineering school subject

7

Conclusions

The literature survey indicates that there are changes in the marketplace that makes it hard to achieve product differentiation, i.e. a competitive market situation, through hardware products only. Instead, competing effectively in the market place will require a broader perspective on value creation. Companies have to combine all their value adding activities into complete offers, or functional products. The function provider takes an extended responsibility for the product through its lifecycle. Our survey in industry supports these findings and expresses a need for integrating the development of hardware, software and services into complete offers. Although making valuable contributions, we belief that the literature on IPD and design science does not cover these needs. Therefore this paper has propose a model that combines the lifecycle processes of hardware, software and services, which build up the functional product. Further work will have to examine carefully the interactions between the different processes, especially how to handle concept development when the different life cycles of the functional product components differ greatly.

ICED01-C586/606

311

References [I]

Normann, R. and Ramirez, R., "Designing Interactive Strategy. From Value Chain to Value 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 Management Perspective for the Age of Service Competition", International Journal of Service Industry 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 Service Development and Innovation in the New Economy". Studentliteratur, Lund, Sweden, 2000. [II] Gronroos, C., "Relationship Marketing: Challenges for the organisation", Journal of Business Research. No. 46, 1999, pp.327-335. [12] Gronroos, C., "Marketing sevices: the case of a missing product", Journal of Business & Industrial Marketing. Vol. 13, No. 4/5, 1998, pp.322-338. [13] Chekland, P., "Soft Systems: a 30-year retrospective". John Wiley & Sons LTD., U.K., 1999. [14] Kemmis, S. and McTaggart, R., "Participatory Action Research", Handbook of Qualitative Research. Sage Publications Inc., U.S.A., 2000. [15] Norling, P., "Tjanstekonstruktion" (Service Design). PhD dissertation, Stockholm University, Stockholm, Sweden, 1993. [16] Gummesson, E. "Truths and myths in service quality", Journal of Quality & Participation. Vol. 18, No. 6, 1995. [17] Yin, R. K., "Case Study Research. Design and Methods". Sage Publications, U.S.A., 1994. Oskar Brannstrom Lulea University of Technology, Division of Computer Aided Design, Polhem Laboratory, 971 87 Lulea, SWEDEN, Tel: +46 (0)520 93685, Fax: +46 (0)520 98553, E-mail: [email protected], www.luth.se © IMechE2001

312

ICED01-C586/606

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

HOW MISSIONS DETERMINE THE CHARACTERISTICS OF PRODUCT DEVELOPMENT METHODOLOGIES B Bender, B Bender, and L T M Blessing Keywords: prescriptive models of the design process, process modeling, systematic product development, change processes, mission in product development

1

Introduction

The aim of this paper is to examine the suitability of design methodology to meet today's challenges of product development by looking at the mission behind the evolution of these methodologies. In change management as well as in work psychology having a mission ('Leitbild' in German) is known to be crucial to any change process or work organisation and structuring process. "Mission" will be understood as the idea of a desired, ideal state and the boundary conditions to be considered. The mission determines not only the desired state, the "To-Be" state, but also the view on the current state, the "As-Is" state, and the selected way to get from "As-Is" to "To-Be". This means that to be able to judge the appropriateness of a design methodology for solving particular problems, it is necessary to know the mission underlying this methodology. Furthermore, a reorientation of design methodology to meet today's challenges requires rethinking of the mission of product development rather than trying to adapt existing strategies to today's specific boundary conditions. This paper is of the 'speculation' category, evolving an idea, not reporting scientific results. It therefore focuses on the introduction of a new approach without strong empirical evidence and shall be seen as a contribution to a hopefully extensive discussion.

2

Challenges of Product Development and the History of Design Methodology

As early as 1972, Beitz listed the following challenges in product development to point out the need for a design methodology ([1], S. 6): •

increased complexity of products to meet increasing requirements regarding technical performance and quality;

•

tighter market requirements concerning development time and manufacturing costs;

•

shorter innovation time due to rapidly changing technologies;

•

increased accountability in product development regarding schedule and cost of the product;

•

limited rationalisation in product development compared to other departments;

ICED01-C586/489

313

•

required integration of development with manufacturing;

•

increased deployment of computers, also in product development;

•

shortage of designers.

At first glance little seems to have changed. Due to globalisation and the increasing integration of the customer's viewpoint, some of the issues have become even more challenging and none of these has yet been solved satisfactory. Reality in engineering design departments has changed, but this had had little impact on the formulation of design methodologies. The following paragraphs apply to a variety of common design methodologies, but refer mainly to the design methodology according to Pahl and Beitz [2], which is very similar to the German guideline VDI 2221 [3]. The haydays of German design methodology can be set around the 1970s. The early approaches mainly aimed at supporting design teaching [4], Designing was regarded as a process of problem solving during which complex and contradictory requirements had to be met. Psychological findings on problem solving were combined with strategies from systems engineering. These were adapted to the (former) conditions of product development and resulted in a guideline consisting of working steps to be carried out sequentially to obtain certain specified results. Design methodology today has not changed much since the 1970s. Numerous research projects (some of them can be found for example in [5]) showed that, in general, guideline VDI 2221 is useful for individual design processes, provided it is applied flexibly. Still, in industry design methodology is not widely considered to be helpful in meeting the requirements of product development and often regarded as too time-consuming. What are the reasons for this obvious lack of practicability of design methodology, even though it is proven to enhance designers' capabilities to find appropriate solutions to design problems?

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". Problem solving involves finding a way to get to the "To-Be" state [6]. Design methodologists applied the concept of problem solving to both the design problem and the design process. The psychological concept of "problem solving" has been transferred directly into a practical guideline for solving design problems. In doing so, the fact that the assessment of the "As-Is" state as well as the estimation of the "To-Be " state are highly subjective, has been neglected. Factors that influence problem understanding are ([7], S. Ill): •

insight in the problem space and its boundary conditions;

•

familiarity with the solution space and its boundary conditions;

•

mission behind the "As-Is" analysis.

314

ICED01-C586/489

Particularly the latter has not been considered sufficiently and explicitly in product development methodologies. Problem solutions can be of a completely different nature depending on the discrepancy between the ideal state and the anticipated problems or solutions. For example in the 1980s the very same market situation lead to two opposite concepts for industrial work organisation: •

humanisation of labour through semi-autonomous teams e.g. [8].

•

Computer Integrated Manufacturing (CIM) and the unmanned factory e.g. [9].

Applied to design methodologies two important statements can be derived: •

The mission from the 1970s, representing the image of the ideal design process and the problems to be solved, has to be clarified. A mission for today's product development processes has to be formulated. These missions must then be compared to find elements of design methodology that are still relevant and those that might have become redundant.

•

To be of practical use, a design methodology must reveal its underlying mission to enable potential users to judge the suitability of the mission, and thereby the particular methodology, for their specific problem.

3.1 Optimisation of Product Development in the 1970s and Today The aim of rationalisation in product development in the 1970s was the "taylorisation" of the process through standardisation and optimisation, analogous to the strategies in manufacturing. With this aim in mind the overall task of product development was divided in partial tasks to be executed by single persons or within particular departments within the company. The use of computers aimed mainly at the automation and substitution of human workforce rather then its support. The integration of the results of partial tasks took place higher up the hierarchy, requiring equally specialised knowledge in these positions. Planning and control was based on the elaboration of rather detailed results at long term and also took place in higher levels of hierarchy. Due to the kind of problems to be solved as well as the corporate structures in the 1970s, product development could mainly take place within one single unit of organisation or domain. The number of disciplines and groups involved was low compared to today. The integration of product development activities in the company's organisation structure and workflow usually resulted in clear areas of (managerial) authorities for everybody involved in the product development process. The strategies of design methodology match the boundary conditions from the 1970s named above. To be able to estimate the use of these strategies to meet today's challenges the former boundary conditions have to be examined and compared to today's aims and strategies. Due to the current market situation, globalisation as well as the need for multidisciplinary problem solutions and the parallelisation of product development processes today's aims and strategies are integration, cooperation and coordination of various disciplines and institutions in product development projects. The importance of information exchange as well as effective and efficient communication and cooperation processes within and between (units of) organisations increases strongly. Today, self-organisation, self-management, short feed back circles and flexible target planning replace detailed top-down planning of working steps and the resulting long iteration loops.

ICED01-C586/489

315

What conclusions have so far been drawn from these changes to find approaches to optimise product development processes? Current efforts can be distinguished in two main lines: technology oriented or human oriented strategies. Technology oriented optimisation of product development The availability of information and the consistent and general management of data are considered to be the main problems to be solved throughout the product development process, which leads to the development of specialized hard- and software to support designers in fulfilling their tasks. The aim is to store and process the designers' expert knowledge in information systems and in the long run to increase automation of (partial) product development tasks. Human oriented optimisation of product development Coordination and cooperation processes are considered crucial for the success of product development, which leads to new concepts for management processes that are based on motivation, goal analysis and review. Therefore not only domain-specific competencies but, methodical as well as social competencies of designers play an increasingly important role. The acquisition of these competencies takes place in an organisational and personal learning process which has to be integrated into corporate structures. Table 1. Technology and human oriented strategies for the optimisation of product development processes

technology oriented goals

• • •

management model and principles

•

organisation structure and workflow

•

managerial authority

•

• • • •

feedback, iteration loops information flow

• • •

subdivision of the overall process in partial processes automation of as many partial processes as possible high availability of information through universal data concepts (process chain) management process partially automated by supporting software workflow determined by software determination according to supporting software cross functional parallel-hierarchical approach overlapping authorities in matrix structures clear authorities required for data management in process chains depend on the use of supporting software independent from the individual individual is responsible for collecting relevant information

human oriented • • •

• • • • • • •

• • •

optimisation of cooperation and coordination performance motivation and integration of the collaborators high availability of information through organisational integration (shallow organisation) target planning delegation of management functions to lower levels of hierarchy self management in teams determination by all collaborators via targets cross functional integrated approach overlapping authorities in matrix structures

short loops because of regular information exchange in teams related to the individual individual is responsible for providing and requesting information

In table 1, characteristics of technology oriented and human oriented strategies to optimise product development processes are compared. To discover the mission behind each approach

316

ICED01-C586/489

ideal types are described what means that each strategy focuses on the elements listed above but does of course not totally neglect elements of the opposite strategy. In reality elements of both strategies often occur as a mix, but mostly with an emphasize on one of the approaches mentioned above.

3.2 Missions related to these Strategies The comparison of the technology oriented and human oriented strategy shows that these are based on fundamentally different missions about aims and problems in product development processes.

Figure 1. Different solutions to the same problem depending on the underlying mission of product development

The technology oriented mission says that •

In theory the process of product development can be fully automated, in practice this is hindered by problems resulting from the transfer from knowledge of designers to computer data and the performance of current hard- and software.

•

Available information will be searched and retrieved by designers and interpreted correctly according to the actual problem to be solved. Therefore large amounts of data have to be made accessible for as many collaborators as possible.

The human oriented mission says that •

The key factor for the success of product development is the human being. Therefore appropriate strategies have to be found to identify and clarify the aims of product development from the viewpoints of the collaborators. Simultaneously the integration of individual and organisational goals has to be aimed for.

•

Information does not make sense by itself but becomes useful within a particular situation or context of cooperation and communication. Therefore in product development (cooperation) situations have to be created that enhance the effective and efficient exchange of information of the collaborators. Information technology is needed to support - as opposed to replace - human design activity.

When examining current approaches for optimising product development it becomes clear that these are based, to varying degrees, depending on the particular approach, on one of the missions (or parts of these) described above. The missions behind the approaches are rarely made explicit: looking at their specific characteristics facilitates only an implicit conclusion on the underlying mission. Knowing this, it is easy to explain why there is no such thing as the "right" design methodology. Different strategies can be valid in different coordinate systems, analogous to mechanics. But revealing the mission - the coordinate system - enables on

ICED01-C586/489

317

the one hand the transfer of universal elements into other applications. On the other hand this allows a focused discussion on missions in product development, without getting lost in argumentations about details of characteristics of specific approaches.

3.3 A new Design Methodology based on Human Oriented Strategies In this paragraph a new approach to design methodology will be presented. Starting point is the design methodology according to Pahl and Beitz [2]. This methodology was chosen because numerous research projects over the last decade in Germany dealt with its suitability to enhance effective and efficient product development processes. In addition, the authors of this paper have experience with the application of this design methodology in teaching and practice. The mission of the following strategy is human oriented and says in particular that: •

Cooperation is a key factor for successful product development. The increasing need for multidisciplinary problem solutions, increasing complexity of products to be developed, and the globalisation of markets, lead to problems that cannot be solved by single designers or within single domains. Therefore engineering design management must match these conditions and is of increasing importance.

•

The quality of cooperation processes depends not only on social skills of the individual but also on other boundary conditions. The individual designer cannot be the only party to be held responsible for successful cooperation. For example corporate culture, organisation structures, workflow, the leadership attitude, or the kind of task to be fulfilled equally influence the quality of cooperation processes.

•

Managing effective and efficient cooperation processes can be learnt and must be learnt. Cooperation and communication can be enhanced by specific boundary conditions and supported by specific methods. Therefore an appropriate training and the reflection of cooperation situations within the design process improve cooperation performance. Finally, the success of this process of 'life-long-learning' very much depends on the formulation of an explicit mission.

The proposed strategy aims at the optimisation of product development through implementing a corporate culture of individual and organisational learning and the optimisation of cooperation and communication processes. A detailed description of the strategy, called Goal Oriented Cooperation Management in Product Development, can be found in [10]. Basic elements of this strategy are (see figure 2): •

A model of analysis providing parameters that determine cooperation processes. These apply to entire product development projects as well as to single team meetings. The parameters are: personal boundary conditions, institutional boundary conditions, goals/objectives, contents/subject, methods applied, and the media used [11].

•

A process model for product development focusing on the integration of management functions into the product development process. The model consists of elements of design methodology according to VDI 2221 (workflow and design methods), elements of Project Management (management and phase concept), and the management attitude as well as cooperation methods, e.g. the concept of semi-autonomous teams well known from manufacturing.

318

ICED 01 -C586/489

•

A strategy for the implementation of Goal Oriented Cooperation Management in Product Development in practice. The implementation strategy consists of a combination of elements from organisational development and experiential learning (the latter according to Kolb [12]). The reasons are that the workflow in product development has to be changed, and the collaborators have to learn how to manage efficient and effective cooperation processes based on the above described model.

Figure 2. Characteristics of Goal Oriented Cooperation Management in Product Development

4

Conclusion

This paper highlighted the importance of the underlying mission for understanding characteristics of strategies for the optimisation of product development processes in general and design methodologies in particular. Based on theoretical findings on factors influencing the idea of a current state and the desired state, we showed that completely different ways of dealing with the very same problems can be found. To clarify this, two different views about the current problems in product development were presented: the technology oriented and the human oriented approach. It is obvious that the fundamental differences between the underlying missions prevent the development of a universal design methodology. Still, there is a need for new strategies in product development since the boundary conditions and thus the missions fundamentally changed since the 1970s. So far, attempts to adapt the VDI 2221 design methodology only went as far as changing isolated details (for example its flexible application in iteration loops as opposed to sequential workflow, or computer support for particular design tasks). As long as there is no common understanding about missions in product development, a discussion about a universal design methodology is not fruitful. We have tried to start this discussion by introducing our human oriented mission and the core elements of an approach to a new - in the sense of adapted to today's challenges - design methodology that were derived from this mission.

ICED01-C586/489

319

References [I]

Beitz, W., Systemtechnik in der Konstruktion, in: Rau, J. (Ed.), Vortrage und Diskussionen in der Sitzung der Arbeitsgruppe Forschung und Technik der Arbeitsgemeinschaft fur Rationalisierung des Landes NRW am 8. Marz 1972. Verkehrs- und Wirtschaftsverlag, Dortmund 1972, p. 6-21

[2]

Pahl, G., Beitz, W., Engineering Design: A Systematic Approach. Springer, London 1996

[3]

VDI 2221: Verein Deutscher Ingenieure (Ed.), Methodik zum Entwickeln technischer Systeme und Produkte, in: VDI-Richtlinien. VDI-Verlag, Dusseldorf 1993

[4]

Miiller, J., Arbeitsmethoden der Technikwissenschaften: Systematik. Heuristik. Kreativitat. 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 of Practice and Science. Proceedings of the 12th International Conference on Engineering Design. Schriftenreihe WDK 26, Technische Universitat Munchen 1999, p. 721-726

[6]

Hacker, W., Allgemeine Arbeitspsychologie: psychische Regulation von Arbettstatigkeitea 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 der Wissenschaften zu Berlin (Ed), Forschungsbericht Bd. 6. de Gruyter, Berlin 1993

[9]

Brodner, P., Pekuhl, U., Ruckkehr der Arbeit in die Fabrik. Wertbewerbsfahigkeit durch menschenzentrierte Erneuerung kundenorientierter Produktion. Insitut fur Arbeit und Technik - Wissenschaftszentrum Nordrhein Westfahlen 1991

[10] Bender, B., Zielorientiertes Kooperationsmanagement in der Produktentwicklung. Diss. TU Munchen 2001, http://tumbl.biblio.tu-muenchen.de/pubVdiss/mw/2001/bender.html [II] Bender, B., Kiesler, M., Beitz, W., A Model of Analysis to Improve Teamwork Perfomance, in: Lindemann, U., Birkhofer, H., Meerkamm, H., Vajna, S. (Ed.), Communication and Cooperation of Practice and Science. Proceedings of the 12th International Conference on Engineering Design. Schriftenreihe WDK 26, Technische Universitat Munchen 1999, p. 177-183 [12] Kolb, D. A., Experiential Learning - Experience as the Source of Learning and Development. Prentice Hall, New Jersey 1984 Dr.-Ing. Beate Bender Bombardier Transportation, Advance Engineering, Kablower Weg 89, D-12526 Berlin, Germany, Tel.: ++4930 6793-2554, Fax: ++4930 6793-2237, E-Mail: [email protected] Dipl.-Ing. Bernd Bender, Prof. Dr. Ir. Lucienne Blessing Technical University of Berlin, Dept. of Mechanical Engineering and Transport Systems, Engineering Design and Methodology, Sekr. H 10, Strasse des 17. Juni 135, D—10623 Berlin, Germany, Tel: ++4930 314-24309, Fax: ++4930 314-26481 E-mail: [email protected] ©IMechE2001

320

ICED01-C586/489

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

VISUALIZATION TECHNIQUES TO ASSIST DESIGN PROCESS PLANNING P J Clarkson, A F Melo, and C M Eckert

Keywords: planning and workflow methodology, risk analysis and management

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 market success (or failure) of a new product [1], Indeed, for every new product there will be a best possible design process that achieves an 'ideal' balance between the technical requirements of the product and the commercial aspirations of the company. A successful planner needs to be aware of constraints imposed on the planning process not only by resources but also by the process itself. However, in design the process is difficult to define before its has began. In addition, requirements change as design processes and the planned activities are not guarantied to be successful. Hence, any support for planning must cope with this dynamic nature of design. The aim of this research is to improve the effectiveness of design process planning by defining novel ways to generate and visualise alternative plans.

2

Approach

The requirement for improved visualisation of alternative plans emerged from earlier work on the capture and analysis of task-based design processes [2]. In particular, there was a need to investigate a wider range of alternative plans and provide some indication of their relative merits. A review of existing planning models was undertaken with reference to a number of specific case studies. Their relative strengths and weaknesses were assessed and requirements derived for a new approach that would improve visualisation of the underlying process characteristics. A number of alternative models were investigated and adapted to meet these requirements. The preferred approach was then evaluated with further case studies taken from a wide range of design processes.

3

Design process planning

As in chess, in design planning good moves can lead to early victory, resulting in a cost effective design and a good product. So what defines good design process planning? In order to answer this question it is necessary to know something of the number and characteristics of all possible design routes. Then, when presented with a choice of tasks, the most appropriate task may be chosen in the light of its associated downstream process. Process planning is therefore dependent upon identifying key attributes that characterise the process.

ICED 01 -C5 86/065

321

These attributes include: •

tasks which may be performed in parallel or must be performed sequentially;

•

task clusters which may be grouped to form larger coordinated activities;

•

potential bottlenecks in the design process;

•

process routes which incur the lowest risk of overrun.

There is increasingly a need for effective planning techniques that address these issues, balancing the process characteristics with the available resources to choose the best design route. The following sections discuss a number of process representations and risk assessment techniques with reference to a simple twelve-task model of mechanical component design.

3.1 Visualising the design process A number of visualisation methods commonly used in design process planning have been investigated (Figure 1). Gantt and PERT charts are traditionally used to aid visualisation of complex processes and to assist in resource allocation [3]. A combination of these charts, coupled with resource planning and critical path analysis, remains a simple and often effective means of process planning. However, whilst the first and last tasks are clear, the ordering of the intermediate tasks and alternative design routes are not.

Figure 1. Typical design process representations

Alternatively, a design process may be represented by a Design Structure Matrix (DSM) [4, 5] using knowledge of task precedence (Figure 2). The DSM identifies specific tasks (columns) which must be performed before other tasks (rows). A reordering of the DSM can then reveal serial, parallel and interdependent task clusters, where the latter may then be grouped to form larger coordinated activities. Although the DSM reveals task interdependence, it says little about the potential bottlenecks and the risk associated with of the resultant design process. There remains a need for a method to aid visualisation of the individual design routes as part of the process of task evaluation and selection. A task sequence diagram (Figure 3), which makes all routes and decision points explicit, is useful in this respect. This is an expansion of the PERT diagram that allows multiple instances of each task, therefore enabling tasks sequences as well as task precedence to be shown.

322

ICED01-C586/065

Figure 2. The Design Structure Matrix

The links between the tasks in Figure 3 represent explicit design states. An alternative is the design state network (Figure 4), where design states, defining particular states of completion of the design, are linked by the design tasks.

Figure 3. Task sequence diagram

The task sequence diagram uses the tasks as nodes in a network linked by parameter states, defining particular states of the design parameters. The design state network removes some redundancy by using the parameter states as nodes linked by the tasks. As a result it is always simpler in form. It relies on the assumption that a given design state can be reached by a number of different routes and can be derived directly from the task sequence diagram. This is consistent with observations of a number of design processes made by the authors [2], though its general validity requires further investigation.

Figure 4. Design state network

ICED 01 -C5 86/065

323

In summary, the design structure matrix and PERT chart are very useful for capturing task dependencies, but limited in their ability to assist visualisation of possible design routes. Similarly, the Gantt chart is useful for identifying the time available for task execution, but misleading in its suggestion of a potential process. Conversely, the task sequence diagram shows all possible routes, but appears too complex. Finally, the design state network also identifies all possible routes, but with much reduced complexity when compared to the task sequence diagram. Therefore, it is proposed that the design state network, with its combination of simplicity and completeness, is used as a basis for visualising possible design process routes and identifying the lowest risk routes. The following section discusses possible methods of constructing design state networks and the provision of addition information to assist design process planning. A particular focus here is on the identification of individual tasks within the network.

3.2 Visualising the design state network There are a number of network construction methods, based on knowledge of possible design states and their associated linking tasks, which can provide adequate separation of the network nodes. The design state network may be drawn manually (Figure 5). Here the separation of states is easily achievable, but the unique identification of tasks is difficult to achieve and a more methodical approach to network construction is required.

Figure5. A manually drawn network

An alternative is the tangent method, an easily automated process that can be used to draw the design state network. It allocates specific line gradients to individual tasks, attempting to maximise the separation of states. It achieves this by allocating gradients with the greatest possible angular separation to tasks emanating from states that exhibit the greatest process divergence (Figure 6). For example, the three tasks emanating from state 27 in Figure 4 are represented by lines of high angular separation in Figure 6. Those states with the largest number of tasks are draw first to ensure that adequate angular separation is achieved. Hence, the tangent method produces a network with well separated states and uniquely identified tasks. In addition, prismatic structures emerge in the network that identify groups of tasks (for example, between steps 2 and 5) which may be done in any order or in parallel.

324

ICED01-C586/065

Figure 6. A tangent network

The tangent method, in particular, produces a useful diagram, which enables identification of tasks by the gradient of the network links. A further benefit is the identification of serial and parallel task groups. A number of other representations have been explored [6], but none provide quite the clarity of the tangent diagram. This is further illustrated by Figure 7, a plot for a 27-task model of mechanical design. The extended mechanical design process is characterised by an initial serial sequence (a) followed by a short parallel sequence (b). This is then followed by two large task clusters (c and e), separated by a bottleneck (d), and concluded by a final short parallel sequence (f). These characteristics have major implications for the success of the process. In particular, it is important to understand the nature of the bottleneck and whether it represents a particular risk to the project. The task clusters also highlight potential for extensive parallel working and the need for resources to be available concurrently.

Figure 7. A tangent network for a 27-task model of mechanical component design

4

Risk management and design process planning

Despite the benefits of the tangent diagram in characterising a design process, there is as yet there no indication as to which design process route provides the best balance between

ICED 01 -C5 86/065

325

technical and commercial risk. To meet this need, a method that is often used to assess possible design process problems has been adopted. It uses a likelihood / impact graph (Figure 8) to represent possible technical and non-technical risks, where each risk is assessed qualitatively for its likelihood of occurrence and impact on the design process [7]. Risk management procedures are then implemented to reduce unacceptable risks.

Figure 8. The likelihood / impact graph

The impact in this context may be chosen to be, for example, cost of development or time to product launch. The usefulness of such a method is then critically dependent upon the completeness of the assessment and availability of heuristic knowledge of the product and design process. The principle of the likelihood / impact analysis can be applied to the assessment of alternative design routes. If the likelihood and impact of task failure can be estimated for each task on each proposed route, then the route with the lowest predicted cost may be identified. Alternatively the impact may refer to a number of other interdependent measures, for example, a delay in design completion resulting in lost sales opportunities [8]. One method to estimate the cost of failure, Ci, associated with each design route z, is to sum the products of likelihood and impact for each task in the design process:

where d is the total cost of failure and p(n(s>) is the probability of failure of task n(s) on step s of route ; and c(r(s>) is the impact or cost of the task failure. It is important to note that this impact or cost is dependent upon the design route taken to arrive at task n(s) on step s, where:

The lowest cost route may be found by searching for the route with lowest Ci. Values for p(n) can be derived heuristically by observation of the design process. Values for c(r) can be derived by calculating the difference in cost between completion of the original design route

326

ICED01-C586/065

and the design route following failure, where the latter represents the lowest cost option to complete the design. Again there a number of possibilities for representing risk. Figure 9 shows the probable cost overrun for all the routes shown in Figure 6. Note that the risk reduces as the process advances, with zero risk of overrun when the process is complete.

Figure 9. Absolute risk representations

Whilst this clearly shows the range of risks, it does not assist the identification of individual routes. An alternative representation may be derived from the tangent diagram where the line thickness now represents a measure of risk (Figure 10). Preferred routes may be shown by thicker lines. Whilst it is now more difficult to ascertain a direct measure of risk, it is much easier to identify the lowest risk routes starting from a particular design state.

Figure 10. Lowest risk routes

Tangent vector diagrams have been constructed for a number of design processes. In all cases it has been possible to clearly identify tasks which must be performed sequentially or in parallel and task clusters which may be grouped to form larger coordinated activities. In addition, potential bottlenecks in the design process and processes which incur the lowest risk of overrun can be identified.

ICED 01 -C5 86/065

327

5

Conclusion

Effective process planning is dependent upon identifying the key attributes that characterise a particular process. These include natural process constraints, such as bottlenecks, and networks of alternate process routes. It has been demonstrated that it is possible to improve on current planning tools to assist with this characterisation. In particular, simple graphical representations can be employed to highlight the lowest risk routes through a given process. The tangent diagram, which is a form of design state network, would appear to show the most potential as a visualisation tool. Further work in under way to develop software which will allow the interactive development of process plans, supported by the use of design state diagrams incorporating process risk analysis. References [1]

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-based model 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 Planning Analysis: Methods and Models. John Wiley, pp231-255.

[4]

Steward, D V (1981), "The Design Structure System: A method for managing the design of complex systems," IEEE Transactions on Engineering Management. 28(3): pp71-74.

[5]

Eppinger, S D , Whitney, D E, Smith, R P and Gebala, D A (1994), "A Model-Based Method for Organizing Tasks in Product Development," Research in Engineering Design, 6: ppl-13.

[6]

Clarkson, P J, Melo, A F and Eckert, C M (2000), "Visualization of routes in design process planning," in International Conference on Information Visualisation (IV2000), London, UK, 19-21 July, pp 155-164.

[7]

Coppendale, J (1995), "Manage risk in product and process development and avoid unpleasant surprises," Engineering Management Journal. February 1995, pp35-38.

[8]

Clarkson, P J, Melo, A F and Connor, A M (2000), "Signposting for design process improvement, a dynamic approach to design process planning," in Artificial Intelligence in Design. Worcester, USA, 26-29 June, pp333-354.

Dr P John Clarkson Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0)1223 332 742 Fax: +44(0)1223332662 E-mail: [email protected] © Cambridge Engineering Design Centre 2001

328

ICED01-C586/065

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

A PRODUCT AND PROCESS MODEL SUPPORTING MAIN AND SUBSUPPLIER COLLABORATION B Fagerstrom and H Johannesson

Keywords: Product modelling, collaborative design tools, SMEs, industrial case study.

1

Introduction

Many main suppliers are streamlining their operations, moving towards more external contracting of their sub-systems. The co-operative aspects of product development are thereby increasing, and therefore the need to manage different types of relationships, and to exchange information and knowledge. The main supplier is reliant upon the sub-supplier's knowledge within certain areas. Thus, it is obvious that the customer-supplier interface now plays a key role, and the product and process model is an important part of the design and development of new products. The point in time for involving sub-suppliers and the ability to quickly put together a team with distributed actors is an important factor for success. Sub-suppliers become more important as they develop and produce an increasing amount of the components needed for the final product. As a result, the main supplier's ability to use sub-supplier's knowledge is a strategic factor for the future. The collaboration between main and sub-suppliers is dependent on the ability to manage the information exchange between interfaces for upstream and downstream tasks, different sub-systems and different organisational functions [1]. Organising and running a development project is a dynamic and complex process, partly due to the fact that knowledge is added as the project progresses. As a result, earlier decisions can be considered unreasonable at a later stage. It is therefore important, that the process continuously supports the exchange of design information and knowledge. When preliminary upstream information is utilised too early by the downstream activity, future changes have to be incorporated in time-consuming subsequent iterations. Overlapping tasks could be better managed through a proper understanding of the properties of the exchanged information. Subsupplier's ability to work with preliminary specifications, to manage overlapping and dependent tasks, and to support the main supplier with essential information is crucial [2]. Products are often built up in a top-down manner, where the main supplier carries out the requirement specification and the product structure, including descriptions for what is to be achieved [3]. When doing this, consideration of downstream processes is very important: subsupplier knowledge must be taken into consideration in a more bottom-up manner in order to avoid sub-optimal requirement specifications and product structures. Functional decomposition of the product is an important step when selecting the product structure and for reducing the complexity. The decomposition makes it possible for sub-suppliers to design sub-systems in parallel, even though the interaction between sub-systems must be taken into consideration [4]. A thorough understanding of the product structure and the tasks to develop

ICED01-C586/076

329

is central in the collaborative product development between main and sub-suppliers [1], where the formal procedure for information and knowledge exchange is often pending.

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 and taking advantage of opportunities. Knowledge is often described as a result of data and information. Information is about placing data in a meaningful context, and a common language for communication is crucial for efficient information exchange. A lot of information about the physical product model is often available, but aspects like decisionmaking, packaging, suppliers, transports, etc are often pending. As the products become more complex, the amount of information to be stored and distributed increases. The need for efficient computer-based tools increases as well. Therefore, digital product models must support the product development process. The models contain product related information needed by different actors and tools in the process. The product information framework in the present study is an object oriented product model based on the so-called function-means tree [3,5], which has been implemented using the commercial software Metis Software. One of the aims of the study is to extend the model to incorporate sub-supplier process information. It is argued that the extended model is a powerful aid for supporting main and sub-supplier collaboration. Many delays in product development projects are related to inadequate specifications. This causes even more difficult problems when sub-suppliers are involved. In order to improve handling of these issues, a more adequate, dynamic approach for the specifications is required [6]. Such an approach must enable learning from experience gained in ongoing projects, allow consideration of alternative new concepts and technology and consider different stakeholders' views. By incorporating the product specification into the product and process model as an integrated part, these issues become easier to manage. There are some shortcomings in information models as well. A lot of the designer's time is spent on process and product-related information acquisition. When the information is found, there are still doubts as whether one may trust it, where a common understanding often is lacking and further discussions with persons provided [7], Designers often look for expertise: an expert to discuss a certain problem with. That expert often possesses a combination of tacit and explicit knowledge not available in the computer-based models.

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 the other. The life phases and aspects are not fixed, and should be determined according to the specific situation, depending on industry-, organisation- and product type, etc. The main objective with the model is to put the needed product-related information into a product model context, supported with information from supplier processes and life phases.

330

ICED 01 -C586/076

Figure 1. Enhanced F-M tree [3,5] and Olsson table [9]

3.1 Product model The product model contains information about wanted functional behaviour, constraining factors and design solutions, fulfilling the wanted behaviour while meeting the constraints. Its basic structure, shown in figure 1, is an object-oriented, hierarchical representation of different design solutions (assemblies, sub-assemblies, parts and features) and their governing criteria (functional requirements and constraints). The solutions and their criteria constitute a complex product. Both solutions and criteria are modelled as objects. The objects used in the model are Functional requirements (FRs), Design parameters (DPs) (means= systems, organs and components) and Constraints (Cs). Descriptions such as function performance attributes, constraining limit values or design parameter characteristics can be linked to the objects. It is also possible to link describing documents and other models to the different objects. A DP represents the design solution, a FR is a solution driver and a C is a solution restraint. The six different relations used are defined and shown in figure 1. The design solutions (DPs) at lowest level will be linked to part lists in ongoing work. To identify all objects and related information regarding the product life cycle, the Olsson table, with so called "context interaction maps," is used. It is also used as a supporting checklist (fig. 1). Each object triplet (FR-DP-C) in a completed F-M tree has its own Olsson table linked to it, and each relevant table cell contains complementary information, such as company preferences, company standards, process descriptions, operations lists, lessons learned documents and so on. Furthermore, sub-supplier information is in this paper linked via the Olsson table to the main supplier's product model.

3.2 Process model This paper uses a task-based Design Structure Matrix (DSM) [4] for dealing with upstream and downstream information exchange, which is sufficient for the purposes of this paper. This is shown in figure 2. The DSM is used as an interaction map to describe relevant sub-supplier involvement and processes. Design tasks to be performed are identically labelled in both rows and columns in the matrix. Each marked cell (+) shows a task dependency. Rows indicate information providers, while columns indicate information dependants. There are three types of task dependencies (fig. 2). Independent tasks can be performed in parallel, dependent tasks must be performed in series, and interdependent tasks are coupled, requiring multiple iteration [8]. A lower triangular matrix is optimal, but that rarely occurs in practise [4,8].

ICED01-C586/076

331

Figure 2. The DSM (Design Structure Matrix) principle [4,8]

Different measures can be used to describe the dependency, instead of just a simple (+), e.g. the degree of dependency or the volume of information to be transferred. This increases the advantage of the DSM. The DSM can also be used for other data besides tasks, e.g. parameters, components or teams [4]. This paper applies four different levels to quantify the dependency of information to each task (fig. 2). Furthermore, different actors, such as suppliers and customers, are shown in an additional column in the matrix. The DSM-principle has some shortcomings as well: it is difficult to predict all the tasks that have to be performed during an entire, new product development project. To deal with this problem; the proposed model could be a powerful aid, where the early product model (F-M tree) supports the modelling of primary tasks in the DSM and the involvement of suppliers.

3.3 Managing the model The modelling procedure starts with formulation of the overall functional requirement and the constraints on the highest hierarchical product level (fig. 1). These formulations are most likely derived from a type of project assignment. Relevant information describing these overall criteria is linked to the requirement and constraint objects, either as attributes, in attribute lists or as referenced documents and models in other software systems. Then, the overall design solution (DP) is selected. The DP, which fulfils the FR and meets the Cs, is modelled as a DP-object. It is connected to the FR and the Cs respectively, and, finally, is described by its attributes and references. The DSM modelling process is dependent on this preliminary concept and the description of the main functions. The early phases for modelling the primary tasks in the DSM, should therefore be modelled simultaneously with description of properties, preliminary concept, main functions, requirement specification, etc. This procedure is somewhat iterative and the DSM supports the process. Next, sub-requirements for the chosen DP are identified and modelled at the next lower hierarchical level in the model (fig. 1). A sub-solution must fulfil each sub-requirement, taking the sub-constraints into consideration. All objects are connected to other objects and linked to relevant information sources in the same manner as the first level objects. All the sub-tasks to be developed are modelled in a master DSM (fig. 2), provided by the main supplier. Available process information from sub-suppliers is linked to the model objects as interaction maps via relevant Olsson table cells. It is also recommended that sub-suppliers carry out their own DSM, with, for example, information about design tasks, prototypes, testing, verification, tooling, processes planning and production ramp up. The main supplier's master DSM covers information for the complete system, such as, different suppliers involved, testing, verification, validation, 0-serie and final assembly. The level of dependency between different tasks is also to be stated (fig. 2).

332

ICED 01 -C586/076

4

Product and process analysis

All aspects mentioned above, involving different objects and activities with relations to each other are very difficult to manage efficiently. The F-M DSM product information model is a useful tool in this instance. The F-M tree and the DSM show the functional couplings and task-dependencies. This makes it possible to show when, and which, suppliers are involved during different stages of the main suppliers' product development process. It also relates subsuppliers process information to its concerned sub-systems or parts in the main suppliers' product hierarchy and also to concerned product life phases.

4.1 Product coupling analysis A conflict called a functional coupling [10,11] can result when choosing a design solution to fulfil one of two or more functional requirements on a design solution on the previous higher structure. Graphic functional coupling degree analysis [12], based on the information captured in the F-M tree, can then be used. This technique is based on a graphic interpretation of the axiomatic design equation [10] for a group of parallel DPs and their governing FRs on an arbitrary level in the F-M structure model. The axiomatic design matrix elements then correspond to the z76-relations in the structure model (fig. 1). It is suggested that functional couplings are defined as interactions between incompatible parallel design solutions or between design solutions causing negative constitutive influences [11]. Incompatibility can be of many different types. The main areas of interest in mechanical design are geometry, time, system physics, driving effort and material. Constitutive influence can be described in terms of cause and effect, i.e. often with a constitutive relation. Just as solutions may be incompatible in order to fulfil governing functional requirements they may also be incompatible in order to meet design constraints. Incompatibility caused by constraints can be classified according to the same classification scheme as functional incompatibility. Design solutions incompatible due to geometrical constraints can be coupled in a way similar to incompatible solutions caused by functional requirements. These geometrical couplings can also be identified in the F-M structure model [13].

4.2 Process analysis When a sub-supplier has finalised the design of a sub-system, the output will normally have an influence on the input to a parallel sub-system. The DSM will support the process to determine in which order the sub-systems may be designed to avoid needless redesign, or at least control the necessary iterative loops that is provided to meet the requirements and to design a first-class product. As the project progresses, additional knowledge is obtained, and the DSM links new features [6] via the Olsson table to the product model. The DSM helps the main supplier to analyse each supplier's information need. The DSM (fig. 2) will indicate what type of information dependency that exists between sub-suppliers and the main supplier. When a certain sub-supplier have essential information, that could be linked via the Olsson table back to the product model (fig. 1). The DSM will also show which suppliers who can work in parallel, where no dependence exists. Furthermore, the DSM could be used to shorten lead times by restructuring the task sequence. That is normally done by striving for a lower triangular matrix (partitioned) [4,8], However, it could also be helpful to consider clustering of sub-suppliers to avoid unnecessary travelling or

ICED01-C586/076

333

rethinking the scope of supply for sub-suppliers if that, for instance, could lead to a decoupling of tasks. Coupled tasks must be decomposed into suitable blocks for iteration [4]. If the iterative loops are extensive and involving too many actors, it could also be possible to divide the loop into sub-loops. There the iteration drivers are essential for selecting sub-loops.

5

Case study

This paper is based both on theory and on empirical findings from a case study. The case could be defined as a strategic partnership between the customer and the main supplier Autoliv (first tier), for the development of a new complex product (inflatable curtain: a side impact airbag) within the automotive industry. The company Autoliv is a worldwide leader in automotive safety, and also the inventor of the inflatable curtain in this case study. The case study is shown in figure 3, where some of the most essential parts of the study are illustrated. In this case, the customer starts the design process with a description of the properties of the product (item 1). The main supplier (Ml=Autoliv) prepares the design specification and the preliminary concept (item 2) in collaboration with the customer (Cl). The Olsson table (item 3) is used both as a checklist for criteria and to link context interaction maps for the F-M tree. The top-level triplet (FR-DP-C) for the product/sub-system is defined by using information that is linked via the top-level Olsson table. The overall function (FR1) for the product, the overall design parameter (DPI), and the constraints (Cl) are shown as item 4 in figure 3. The Olsson table covers life-cycle phases and different aspects. The aspects could be divided in suitable sub-headings for the purposes of the project. The solution 'inflatable curtain' (DPI) requires three sub-functions at the next hierarchical level below (item 5: FR21-FR23). The top level of the Olsson table is decomposed into subtables simultaneously with the selection of sub-functions and solutions (item 6). The decomposition of the Olsson table is dependent on the selected solutions. As such, it cannot be decomposed in advance.

Figure3. Presentation of case study

334

ICED 01 -C586/076

The relations in the F-M tree are continuously added as the model is built, with an w-relation (interact_with) shown as item 7, an n'6-relation (is_influenced_by) in item 8 and, finally, an ipmb-relation (is_partly_met_by) as item 9. The different sub-systems to be designed and their information needs are illustrated in the DSM (item 10). This case illustrates task dependencies, where iteration is provided for the tasks in row 7-11. It is not efficient to have all four sub-suppliers working in parallel, so it was decided to use the opening mechanism (Supplier 1: SI) and the cells (Supplier 2: S2) as iteration drivers, row 7 and 8 (item 11). After this initial iteration, information could be linked back to the product model, via the Olsson table. The master DSM (item 12) is used for coordination of suppliers and the verification and validation of the entire system. Each supplier could also define each sub-system's in a sub-DSM (item 13). There, the information from the design and verification of the sub-system could be linked back to the product model (item 14). A part-list has to be linked to the lowest level means, which is illustrated as item 15 in figure 3 (DP23, DP3i and DP32). That will be further discussed in other ongoing work.

6

Discussions and conclusions

In a distributed product development environment, it is essential to determine in which order the sub-systems have to be designed and which actors are dependent on each other, during different stages of the project. A generic F-M DSM product information model has shown promising results. The model describes both the task and object dependencies. It is also helpful for purposes of analysis. Defining the product structure in the F-M tree is important in order to structure the design tasks and locate them in the DSM-matrix. The DSM addresses both task and supplier dependency, using the important design parameters in the product model for the decomposition of iterations into suitable blocks. Furthermore, the DSM illustrates the feedback loop of information from sub-systems/suppliers back to the main supplier's product model, via the Olsson table. The enhanced F-M tree puts the product related information in a product context. The obtained structural product knowledge is essential for selecting the sub-system interfaces. The product model supports the information needed for each sub-system (supplier). The master DSM puts the information into a process context. The model contains the procedural knowledge, which is a good starting point when setting up new projects. It is also helpful for understanding supplier involvement, both from the main and sub-supplier's perspective. It is suggested that the master DSM be performed at a general manageable level, with the detailed supplier information being described in the sub-DSM for each supplier. Therefore, it is argued that the model is not only a model for structuring large amount of information, but also partly a knowledge model for both structural (product) and procedural (process) knowledge in the project. As the main supplier often is dependent on knowledge from suppliers, it is recommended that the F-M DSM product information model be created with personnel from both the main and the sub-suppliers. In addition, at least one person from each supplier should be responsible. It is essential that this is a physical meeting, for two reasons. First, this type of modelling consists of both explicit and tacit knowledge. Second, vital discussions often take place. The case study has shown it possible to have a more flexible approach to both specifications and the product structure, as long as the design process is defined and supported by the information model. The case study results are encouraging. Indeed, the proposed information

ICED01-C586/076

335

model is used in new projects at the studied company. The company also saw advantages with using the model, as the model could be computer-based, which is partly done in this project.

7

Acknowledgement

The authors would like to thank Johan Stenquist at Autoliv Sverige AB, for valuable input and technical knowledge. Funding was provided by the Swedish Foundation for Strategic Research (ENDREA program). This support is gratefully acknowledged. References [I]

Fagerstrom, B. and Jackson, M., "Efficient collaboration between main and subsuppliers", Proceedings of the 4th conference SMESME'2001, Aalborg, 2001

[2]

Krishnan V., Eppinger S.D. and Whitney D.E., "A Model-Based Framework to Overlap Product Development Activities", Journal of Management Science, 4, 1997, p437-451

[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 Method for Organizing tasks in Product Development", Research in eng. Design, 6, 1994, pi-13

[5]

Andersson, F., Nilsson, P. and Johannesson, H. "Computer based requirement and concept modelling- Information gathering and classification", Proceedings of DETC'2000ASME, Baltimore, 2000

[6]

Akesson, A. and Bjarnemo, R., "Dynamic product design specification", Proceedings of ICED'99, Munich, 1999, pp.389-392

[7]

Blessing, L. and Wallace, K., "Supporting the knowledge life cycle", Proceedings of the KIC3 workshop, Tokyo, 1998

[8]

Steward D.V., "The Design Structure System: A Method for Managing the design of Complex Systems", IEEE Transactions on Engineering Management, 3, 1981, p71-74

[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 in Axiomatic Machine Design", Proceedings of DETC'1996 ASME, Irvine, 1996 [12] Johannesson, H.L., "Computer Aided analysis of Functional Couplings in Structural Axiomatic Design", Advances in Design Aut, Book NQ.H00998, ASME, Vol. 1, 1995 [13] Soderberg, R. and Johannesson, H.L., "Spatial Incompatibility - Part Interaction and Tolerance Allocation in Configuration design", Proc. DETC'1998 ASME, Atlanta, 1998 Fagerstrom, Bjorn IVF Industrial Research and Development, Argongatan 30, SE-431 53 MoTndal, Sweden, and Department of Machine and Vehicle Design, Chalmers University of Technology, Goteborg, Sweden. Phone: +46 031 706 61 57, Fax: +46 031 27 61 30 E-mail: [email protected] ©IMechE2001

336

ICED 01 -C586/076

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

IDENTIFYING AND ANALYSING CHANGES IN A DYNAMIC COMPANY S Suistoranta

Keywords: Industrial case study, competitive products, change management.

1 Introduction Changes in the environment lead easily to a proliferation of changes throughout the productfamily for a variety of reasons. A competitive delivery process is sensitive to disturbances. Even if the implementation of changes is well managed, it is practical to strive for as few changes as possible. This paper is based on an industrial case study conducted in a company, which designs, manufactures and sells diesel-powered solutions for marine and power producing applications [1]. The study was delimited to the annual production of an engine factory. Change orders, arguments, and explanatory information were collected at different points of the delivery process. A team of specialists with extensive experience in the field analysed the data in the performance of their daily tasks. The objective was to identify the sources of change to better control their impact on the delivery process. The focus was on changes induced by the company's own processes. The findings will be used in internal process development. There are two main reasons why we should strive to reduce the number of changes. First, cost-effective manufacturing and successful delivery are largely based on well-controlled logistics. In view of material management and inventory control every change causes a potential disturbance. Second, every change order initiates a chain of transactions, both in the design office and on the shop floor. Transactions are usually performed by a set of activities, each contributing to cost accumulation or fixed costs. Even though current PDM systems help in managing product data, version history, and engineering change orders, it is obvious that we should find a systematic way of handling the changes and eliminate unnecessary ones.

2 Background Change occurs constantly and in every aspect of society and human life. In business it means that new markets are opening and new customer needs are being charted. Companies have to maintain a large product variety and be responsive to evolving customer needs at the same time. This is reflected in all levels, especially in the need for product development. The company continuously measures its performance and adjusts its operation to meet the requirements of a changing environment. All changes, especially in the market, affect the business to some extent. The company responds to these changes by means of its processes, which finally implement the changes. The object of change may be a product abstraction, physical product or documentation related to them.

ICED01-C586/087

337

The object of change is an evolving entity, which originates at an abstract level in the form of requirement lists, ideas, and domain structures. It then assumes a more concrete nature in the form of technical specifications, configurations, engineering drawings, and bills of material. These are depictions of the product at different stages and they comprise a continuous information flow, which is united with a material flow to make a physical product in a manufacturing process. Product-related documentation accompanies the product in this evolution. All features and properties, intended or unintended, are involved in the process. In a delivery process the change is intentional alteration of requirements, design, specification or contractual terms. The causes behind the change vary. Some typical causes are: •

Feedback from different life phases of the product, striving for better manufacturing capability, serviceability, and operability

•

Defects found (if any) in products and requests for corrective design

•

Customer-specific requests

•

Introduction of new technology, product structures or components

•

Introduction of new design tools or manufacturing technologies

A customer-orientated approach calls for flexibility and capability in handling changes during the delivery process. Time-based competition emphasises a change-intensive approach, i.e. product improvements must be promptly implemented.

3

Sources of change

If we want to emphasise the environment's dynamic nature in generating changes over time we call it a source of change (henceforth referred to as SOC). There is a complicated interaction between the environment, business and company processes, which can independently or collectively behave as a SOC. Depending on the viewpoint we can speak about external sources and internal sources (see Fig. 1). External SOCs usually fall outside the company's sphere of influence, such as society revising a law or normative rules. However, many changes are not mandatory. Changes induced by market trends are fully within the power of the company because it defines in what market it wants to be and with what product portfolio. Based on its own arguments the company makes decisions on product mix and the introduction of new technologies. These decisions typically lead to an extensive flow of changes at the operative level. On the other hand, there are changes from internal SOCs, in which the company has only limited controlling possibilities, such as specific customer requests and cases in which a component supplier fails to meet its commitments, compelling the company to seek alternatives. Documentation in itself also possesses features of a SOC; e.g. misspelling or a typographical error in one document may cause a chain of others to be revised. This may sound like red tape, but we must keep in mind that very often the implementation is triggered by a given document. Documentation also plays an important role in quality systems and may have significant judicial meaning.

338

ICED01-C586/087

Figure 1. External and internal sources of change and the object

4 Germs 4.1 Definition Flaws hidden in the object always lead to changes, amending of documents and corrective actions. For this we have introduced a new term: germ, which is something that is unintentionally designed into the object and remains undetected until the object meets a particular life phase. A germ carries a potential nonconformity or a malignant disposition. We define it as follows: a germ is a feature, property, solution, principle, mode of action, material, dimension or

ICED01-C586/087

339

whatever factor that makes a potential nonconformity or incorrect parameter settings with respect to the intended life phase process. A disposition is defined as in [3]. We clarify the term with two explanations. First, nonconformity is defined in [4] as nonfulfilment of a specified requirement. This covers the departure or absence of one or more quality characteristics. 'Potential' means that the nonconformity is possible only when the necessary conditions exist. This infers that, at its point of origin, the germ is not a nonconformity and perhaps may never be, unless the conditions in object's later life phases turn unfavourable. Second, we use dispositional approach, as presented in [3]: "By disposition we understand that part of decision taken within one functional area which affects the type, content, efficiency or progress of activities within other functional areas." In a delivery process we may make a decision which carries a germ, affecting the progress of activities later in the process, e.g. in a form of nonconformity.

4.2 Origination In general terms, the germ originates in a transformation system, which consists of a process, an operator, and an operand. Similarly, in an industrial company we have a delivery process, which consists of sub-processes, a designer and information. We have found four major sources of germs, which are more or less specific to the type of company and product. Process In the delivery process there are typically functions ranging from clarification of customer needs to factory tests. Between the performance of these activities, information is stored, transformed and distributed through contact surfaces, which serve as potential points for origination. A process can be seen as an information cycle, in which the output of each activity adds to the volume of object information, accumulating every time the main process is performed (see Fig. 2). In this system a germ may originate and progress as part of the operand to the next round. Designer Designing is a human activity, and the way the designer performs his work reflects all aspects of life. Despite systematic design practices there is always room for biased thinking, misunderstanding, missing motivation or even casual obstinacy. When solving complex design problems under time pressure, the designer is inclined to accept the first working solution without striving to find one that is more optimal. Even if the work is reviewed and checked, there is always a risk of aporia, which prevents us from seeing the best solution [5]. An eventual need for improving the construction later causes a flow of changes. Another problem is that design personnel undergoes changes: people retire and novices start. Tacit knowledge is difficult to transfer. Novices lack experience and due to over-enthusiasm are often prone to haste. They may find drawings with a perfect solution to a technical problem, but cannot understand the original premise for that particular solution, which makes its reuse unpredictable.

340

ICED01-C586/087

Order information In a sales process it is not rare to find some information speculative, incomplete or missing, thus partially basing the configuration on opinion. Sometimes late requests are also received and must be given preferential treatment. Unforeseen requirements may lead to radical changes in sales configuration and to project-related designing. Product information Maintaining a dynamic product-family means managing a large variety at a high rate of change [6]. The variety is based on different configurations, which are realised by means of standard modules. Continuous product improvement results in an extensive revision program, which comprises a myriad of drawings and bills of material. Rushed sales orders cause sudden overloads in the design office. Project-specific applications are realised by joining adaptive modules or non-modules with standard modules. A strong connection between their interfaces may result in some degree of incompatibility between the modules.

4.3 Mechanisms We have identified seven behavioural mechanisms of germs: retracing, circulating, hereditary, mutating, reproducing, contagious, and hidden germs (see Fig. 2). Each of them can work independently or together with others, making their identification difficult. Certain mechanisms can apply to only one product variant, covering its all life phases while others work across the whole product-family. These features describe the germ's nature as a change carrier: originating during the delivery process, it is a considerable internal SOC in a fastmoving environment, where the conditions are changing frequently. The behavioural mechanisms are presented in the following list. The numbers refer to the legend listed in Fig. 2. 1. Retracing. The germ originates somewhere in the process. It is perceived in a later life phase. In searching for its origin it is retraced from one life phase to another. Much time and work is needed before the real origin can be found. 2. Circulating. The germ is detected when the object meets a particular life phase, such as A' for example. Corrective design does not fully succeed in solving the problem and the germ appears in a similar form in life phase N+k. 3. Hereditary. A particular solution made in the product development is introduced in commercial applications; e.g. mapping of functions into physical modules. This may cause interference with particular project-related applications. 4. Mutating. A germ that is perceived in a particular life phase (design, production, use, etc.) appears after corrective design somewhere else in a different form. 5. Reproducing. A germ is copied to new designs by reuse, which results in the need for corrective actions later. Meanwhile the new design is reused somewhere else, including the original germs. This occurs especially when details of existing drawings are copied to new drawings. 6. Contagious. A germ that is perceived in and corrected for a particular product variant creates a set of new germs in other variants that use the same design.

ICED01-C586/087

341

7. Hidden. A germ hidden in a structure, appearing only if structural view is changed.

Figure 2. Examples of germ behavioural mechanisms.

4.4 Controlling the origination Figure 3 shows the relationships between the origin and the behavioural mechanism. First, for each origin there is more than one mechanism. Second, for retracing germ there are four origins and third, product-related reasons are the origin for most mechanisms. To control the origination of germs we suggest taking the following measures: 1. Designer. We stress the recruitment policy, with a focus on aptitude, i.e. education, experience, attitude, motivation, and the desire to achieve professional excellence. Job rotation in the workshop is recommended to extend designers' knowledge on efficient logistics and manufacturing technologies. 2. Process. It is important to find a balance between hard and soft control [6], to develop design rules, and to encourage people to engage in systematic feedback and communication.

342

ICED01-C586/087

3. Order information. Although flexibility is important, standard configurations should primarily be offered. This is also the aim of sales configuration development. On the other hand, we recommend the structured sales process [7], which ensures that all customer needs and expectations are properly clarified and understood. 4. Product information. Standardisation of components reduces a number of different items, which simplifies logistics and reduces inventories. The functional, dimensional, and logistical interchangeability of components widens their applicability. Weak connections between module interfaces are important when developing modular systems.

Figure 3. Relationship between the mechanism and the origin of germs.

5 Implementation process In a manufacturing company all changes cause a chain of operations. We have divided the changes into two main categories according to their implementation process: 1) those where the company has discretionary power and 2) mandatory changes. Processing the changes of category 1 typically consists of two phases. First, we have to judge the necessity of the change, i.e. consider whether to do it or not. At this phase we compare the cost-benefit ratio, taking into account the whole product-family and the entire life cycle. Sometimes the product's manufacturing properties are decisive. Second, we have to assess the impact on the logistical chain, particularly on the availability of the revised material for ordered products. At the same time we have to decide what to do with the material of older versions, whether to use, repair or scrap it. Here we have to balance between inventory costs, reparation costs, and possibly costs of delayed delivery. Processing the changes of category 2 is different because they are frequently based on rules or regulations coming outside the company. Some of these mandatory changes have a transition period, which makes them essentially easier to implement. Non-conformities must be corrected promptly. The same applies to construction changes, which may, if left unimplemented, cause a risk of failure. The object of change may range from particular product variants up to the entire product-family. Customer requests are negotiable and the changes apply usually only to particular product entities. An experienced designer can contribute to logistical interchangeability when making decisions on the types of materials and component specifications. At the same time he can estimate whether to make or buy and finally, how his decisions affect the inventory. These questions are closely related but it may be reasonable to divide the responsibilities between a

ICED01-C586/087

343

designer and another specialist who makes the release and make-or-buy decisions. Naturally, efficient communication is necessary.

6 Conclusions In this study we have identified and analysed sources of change, which affect the delivery process of a manufacturing company. Changes come from both outside and inside the company. The external sources of change can be managed proactively. Most changes, however, originate in the internal processes. We introduced a new term - a germ - which means a hidden flaw in the object. It originates in the process and carries a flow of changes through seven different mechanisms. Process development is suggested to focus to the origins of germs for their better control. The logistical arguments are important in implementing the changes. Finally, we point out that change per se is not negative - on the contrary, it indicates the dynamic nature of our world and allows for industrial companies to prove their commitment to a continuous product improvement, both in terms of quality and of environmentalfriendliness. References [1]

Wartsila Corporation: "Power Divisions". Available at .

[2]

Kotler, Philip: "Marketing Management. Analysis, Planning, Implementation, And Control." Seventh Edition. Prentice-Hall International Editions. Eaglewood Cliffs, New Jersey. 1991. ISBN 0-13-563479-2.

[3]

Olesen, J.: "Concurrent Development In Manufacturing - Based On Dispositional Mechanisms". Ph.D. Thesis from the Integrated Production Systems. Institute for Engineering Design, Technical University of Denmark, 1992. Publication IK.92.116-A. ISBN:87-89867-12-2.

[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, And Organization of Engineering Design Knowledge". Springer-Verlag. Berlin- HeidelbergNew York. 1996. ISBN 3-540-19997-7.

[6]

Sanderson, Susan W. - Uzumeri, M.: "The Innovation Imperative. Strategies for Managing 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 of Technology, Finland. (In print).

Seppo Suistoranta Wartsila Finland Oy Turku Factory Stalarminkatu 45, FIN-20810 Turku Tel. +358(0)107093097 Fax +358(0)107093169 E-Mail: [email protected] ©IMechE2001

344

ICED01-C586/087

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

DESIGN PROCESS PLANNING USING A STATE-ACTION MODEL A F Melo and P J Clarkson Keywords: design management, design strategy, planning and workflow methodology

1

Introduction

The timely introduction of new products to market is a critical factor in determining their commercial success. In turn, design process planning is crucial to their timely introduction. The aim of this paper is to present a model for design process planning which enables the identification of possible alternative plans, their comparison, and the selection of the most appropriate. The model, which provides planning guidance for designers, is to be incorporated into a tool that aids decision making in scheduling, thus enabling design process improvement. Difficulties arise in the introduction of new products because of the complexity of the design process. Unlike other processes, in the design process the state of the product after each stage can not be predicted. This frequently leads to iteration. Many design tasks are undertaken to provide information about the fulfilment of requirements and their outcome has a direct impact on the subsequent direction of the design process. Very often, these outcomes force redesign and re-testing. Development plans (sequences of tasks) are thus bound to change, and schedules (resource allocation timetables) are affected in the process. Scheduling is also affected because the highly complex human designer is the main resource involved. To be effective, design needs to re-evaluate the state of the product, and react to it every time. Exiting approaches to design process planning attempt to simplify the process by defining task precedence. This is equivalent to assuming that activities have predictable outcomes and can imply that there is no iteration. This simplifies the model, but at the same time requires the description of the process components in terms of their relation to the process as a whole. For example, in a PERT diagram, a task is described in terms of the tasks it depends upon and the tasks that depend upon it. This means that changes in the model or unexpected situations require revision of the task descriptions, and therefore render the original model unreliable. Exploring and evaluating possible design processes leads to some problems. The necessary definition of starting points, components of the design process, goals and measures for evaluation is not trivial [1]. The model proposed in this paper separates the description of the components of the process from the process itself. The components are then actions that produce changes in the state of the design process. Their potential outcomes depend on the state of the design when the action is performed and, in this way, the states put the actions into context. The current state can be determined at any point in the process, potential future states can be identified, and plans are made by choosing sequences of tasks according to the comparative benefit they offer.

ICED01-C586/073

345

2

Using the state of the design for process planning

Design can be seen as a series of tasks that are scheduled following precedence relations between them [2]. A complementary view is that design is a process in which a design object (drawings, sketches, manufacturing instructions and parameters in general) evolves and is refined by performing certain actions [3]. This process continues until the design object is considered sufficiently refined. Merging both ideas, a state (described as the refinement of the design object) is repeatedly modified by performing actions (design tasks), until a desired final state is reached. Actions are constrained in that their outcome depends on the input state. State-action models have previously been used for planning and have proved to be useful representation for highlighting ways to produce complex changes within a system [4]. (In this article, in the context of state transitions, the term action is used instead of task, following the usual practice in the literature on the topic.) Our approach to design process planning derived from earlier work on Signposting, a process capture and planning technique which has been successfully applied to a number of design problems [5]. However, the use of Signposting has been limited to identifying only the next step at any stage of the process. Following a review of the Signposting technique and further observation of industrial design practice, a revised state-action model has been developed which allows the identification and evaluation of alternative design routes. This new model is being incorporated in a software tool including uncertainty modelling and scheduling techniques. It supports the construction of a more flexible plan, using a state-action model, which is described by means of an example in the next section.

3

A state-action model of design

The details of the state-action model are now described with reference to the design of a venting valve. A group of designers at the Technische Universitat Miinchen successfully redesigned the valve, and its associated assembly line, in order to resolve a number of operational problems. The model presented here was built using the experience they gained in the process.

3.1

State description

To represent the state of the design, the design object is divided into parameters that can be separately evaluated. These parameters may be components, dimensions, materials, performance parameters, or any other characteristic of the product that is addressed by the design process. The choice of parameters and their levels of detail is critical for the success of the model. It must be simple enough to be easily understood and used by the designers, while still being sufficiently rich to be able to express the situation of the design process in a useful way for the tool. In the case of the valve, the design was divided by components on the one hand, and by stages of development on the other. This resulted in 27 parameters, shown in Figure 1. The state of the design is represented as the refinement of the parameters that describe the product, or more accurately, the confidence that the designer has on the suitability of each of the parameters. The idea is that the refinement of components, dimensions, materials or

346

ICED01-C586/073

performance parameters is higher if their current state is closer to that of the finished product. Naturally, the completely refined product is unknown during the design process, but designers can readily estimate how far are they from reaching it, and the result of that estimation is what we call confidence. In the example, the designers do not really know whether the VALVE CONCEPTS reached its final state, but they can say that they have high confidence that it has.

Figure 1. Valve design parameters

Representing the state of the design by using confidence values in the parameters has three important properties: •

It can be derived at any point during the design process. It is clear that designers can take the list of parameters and assign sensible confidence values to each one, and that it will show a profile of the completeness of the process. For example, they can readily indicate if they have low, medium or high confidence in the SCREWING TOOL DESIGN.

•

The final state is known a priori. In the example, the design process finishes when the designer has a high confidence in all the prototypes (VALVE PROTOTYPE, GRIPPER PROTOTYPE, ASSEMBLY LINE PROTOTYPE, and SO on).

•

Tasks can be described as changes in confidences of parameters. Each task produces a change in one or more of the design parameters; otherwise, it would not be relevant to the process.

The cases previously studied have proved the use of confidence to describe states and tasks to be simple enough, while providing the information needed for dynamic process planning [4].

3.2

Action description

Design tasks are represented in this model in terms of the states they can produce given their input states. In this sense, they are seen as black boxes that produce some output for a given

ICED 01 - C586/073

347

input. Describing the outputs independently from the input would not be accurate, and describing them as exhaustive pairs of possible inputs and resulting outputs would be unnecessarily demanding. Therefore, an option is to generalise the input-output pairs by using rules of change. The parameter confidence representation allows this to be done. Usually a task affects only some of the parameters, while the others remain unchanged. Relevant parameters should have some level of refinement (reflected in a confidence value) before they can be profitably used by a task. Input states that do not have those levels of confidence will remain unchanged if the task is performed; but if they do have them, at least one of the confidences will improve and a new state will be reached. The basic description of the tasks is thus made by indicating the minimum confidences needed in the parameters required to execute the tasks, and the potential increases of confidence. For example, the task detail design of gripper (illustrated in figure 2) requires a medium confidence in the GRIPPER DESIGN and high confidences in the GRIPPER REQUIREMENTS, VALVE DESIGN, VALVE REQUIREMENTS, and WORKSHOP REQUIREMENTS. If the detail design is successful, the confidence on the GRIPPER DESIGN will increase to high.

Figure 2. Example design task

There are two other aspects of tasks that are supported by the model. One is the cost, in time, money or risk, of executing the task. The other is the fact that most tasks are not deterministic; hence, different outcomes must be reflected by a range of possible changes in confidence. For example, if some technical problems were encountered when doing the detail design of gripper task, the confidence in the GRIPPER CONCEPTS and GRIPPER DESIGN might fall, prompting rework. This task representation is appropriate for planning as it describes not only what designers want to achieve, but also what they might achieve instead.

3.3

Task sequences

States and tasks are the building blocks of the state-action model. Designers describe the state of the design at any point, and the tasks that can advance the design are selected. The task representation identifies then the state that can potentially result from performing the task. In this way, states suggest potentially useful tasks, and tasks produce new states. Task sequences can thus be represented as a state-action-state sequence. They are produced by finding the tasks that can be performed given the current state, the states that can be respectively obtained, the tasks that could be used from these new states, and so on. For design planning, it is possible to estimate in this way the possible sequences of tasks and states that would lead to the conclusion of the design. For example, suppose that in the current state of the design, the designer has medium confidence in the parameter VALVE DESIGN. This means that task detail design of gripper

348

ICED 01 - C586/073

cannot be performed yet, as it requires a high refinement of the VALVE DESIGN. However, task detail design valve can be done in the current state, and has the potential to produce the required refinement. Both tasks can thus be done in a sequence, provided that the detail design of valve task is successful in increasing confidence in the VALVE DESIGN parameter. These task sequences are optimistic since they are produced under the assumption that tasks give the best of their possible outcomes. The set of all the possible optimistic task sequences, for given initial and final design states, represents the search space for planning. Due to the combinatorial complexity of such a set of sequences, it is better to take advantage of the fact that most states can be reached through several different task sequences. The search space can thus be represented as a net, where the states are the nodes and the tasks are the links. Different tasks emerging from a state will diverge to different states, and different tasks emerging from different states can converge to the same state. (A good way of showing a state net is by using a tangent graph showing the different optimistic sequences [6].) However, the problem with using optimistic routes is that they do not allow a useful comparison of the task sequences. The risk associated with executing each task needs to be considered at every stage of the process. In particular, the impact of the alternative outcomes of each task, and the different effects they can have, must be evaluated with respect to their position in the task sequence.

3.4

Choosing the next action

Effective design process planning involves identification of appropriate actions to take given the requirements of the design. Actions are preferred when they are more likely to result in lower commercial risk and maximum long-term profit, and ultimately in a more successful product. Time management is critical in design since commercial risk is directly affected by the time taken to design the product [7]. Hence, by choosing the best plan to minimise the expected duration and costs, commercial risk can be reduced. Alternative plans can be compared by treating the state-action model of the design process as a Markov decision chain when choosing which task is best to perform next. Markov chains have been used previously on similar models to aid planning of the design process [8, 9]. However, these models do not have an explicit and intuitive representation of states, and fail to capture some important aspects relating to the complexity of the design process, such as the designer's decision not to perform a task or unexpected changes in the design state. The state-action model allows the building of a net of states and actions producing state transitions, which can be used to compare the different possible task sequences. This net has the same nodes as the optimist task sequence, but these nodes are also joined by links representing the state transitions occurring when the tasks fail to produce their ideal outcome. These links have a weight, representing the probability of the transition occurring. They are unidirectional, as in the optimistic case, and may represent increases or decreases in the parameter confidences. This enhanced state-action model is an example of a Markov decision model. At each state there is a choice of actions (the tasks that fit the state), and these actions can have different outcomes. Actions have also a cost that accumulates as the process develops, until a final stable state is reached. Markov chains are in general well understood, and from this specific

ICED 01 – C586/073

349

kind of Markov chain it is possible to derive information to aid the decisions necessary during planning, i.e., a strategy to minimise the expected duration and costs of the process. The model can be evaluated as a whole to determine the lowest average costs of going from a given state to a final state. This evaluation considers the possible actions that can be done at every state, their costs and possible outcomes (including decreases in confidence). The best policy, which describes the best possible actions for every state, is found in parallel with this evaluation. The algorithms used to evaluate the Markov decision net are standard and can be found in textbooks on the topic. The problem is that even though the number of iterations needed to solve a typical model of the design process is low (two or three using a policy iteration algorithm), the evaluation in each step has combinatorial complexity, and becomes computationally infeasible with large problems. This can be overcome by pre-processing the net to simplify it. This is done by detecting the pairs of tasks whose ordering affects the total rework, and using the Markov net to decide on the ordering of these pairs only, while ignoring the sequences that can be trivially ordered, i.e., those that do not affect the amount of rework. The resulting policy is the same that would be obtained from the complete net, but its computation with the iterative algorithms becomes possible. At the end of the analysis, the dynamic plan that is obtained takes the form of a policy, in which the best actions are identified for each design state. The optimistic task sequences that follow the policy stay as conventional plans, indicating likely routes that can be taken to complete the design process. For dynamic process planning, though, the policy may be used as guide to what to do given the current situation. It is supported by an indication of the additional risk that would be incurred if a different course of action were taken. Conventional plans and schedules can be derived from policies. This can be done by producing an optimistic task sequence net that shows only those tasks that belong to the best policy. A preferred approach is to extract precedence rules from the model. They can be used in addition to the usual parametric precedence relations, as part of the scheduling strategy. Unlike the usual precedence relations, the precedence rules can be broken in a plan, but breaking them has a known cost or risk. Conflicts between precedence rules and scheduling constraints can be solved by comparing the risks and taking the lowest risk route. This has the advantage of including a measure of the expected process risk, which in turn can be used to plan for contingency. In contrast with precedence dependencies, the precedence rules obtained with the model are not obvious from the task descriptions or the process rationale. Precedence dependencies can be easily identified by designers, as they derive the rationale of the process and even of the task description. For instance, in the valve case it is clear that generate gripper concepts cannot be done before tasks generate valve concepts and define gripper requirements have been successfully completed. On the other hand, precedence rules like "detail design valve should precede analyse assembly line" though justifiable and reasonable, are not obvious (see Table 1 for more precedence rules). Breaking this rule would include the relatively expensive analysis of the assembly line in the rework loop of the valve design, causing 36 additional hours of estimated rework. This is an increase of 5% of the total cost of the process. It is therefore in the interest of the project to avoid breaking this and other precedence rules. They should be considered and traded-off with other conditions such as resource cost and availability during scheduling.

350

ICED 01 – C586/073

Table 1. Example precedence rules from the valve design model

Precedence rule

Percentage of total time

Detail design valve

before

Analyse assembly line

47.8 h

7.1 %

, Analyse valve

before

Generate assembly concepts

39.9 h

5.9 %

Analyse assembly line

before

Analyse valve

36.4 h

5.4 %

Analyse assembly line

before

Pre-evaluate gripper

25.3 h

3.7 %

Detail design valve

before

Generate assembly concepts

23.3 h

3.4 %

before

Pre-evaluate gripper

13.7 h

2.0 %

Detail design assembly

4

Estimated cost of breaking rule

Evaluation of planning with a state-action model

The model and its associated tool are being evaluated at two levels. On the one hand, regarding the population of the model, to check that states and actions can be elicited under this representation. On the other hand, regarding the planning strategies given by the tool with a populated model. Models of different levels of complexity have been created, ranging between simple cases of bicycle configuration and the mechanical design of a single component, to the conceptual and detail design of a valve (as used in this paper). Currently, a model of the design process for an automotive powertrain is being constructed with the assistance of Lotus Cars. In all of these cases, the division of the product into parameters proved to be the most critical part of the model elicitation. The idea of defining the parameter refinement needed to perform a task, and its potential outcomes, seems to be quite natural for the designers involved in building these models. The results of evaluating the model, on the other hand, appeared in general to be sensible. Precedence rules are not obvious when building the process, but have an important impact on it. In the valve case exposed, following some of the rules can produce improvements in the order of 5-10% of the total time of the project, which make the analysis worthwhile.

5

Conclusion

A design process model that considers the state of the design, using the designer's perception of the refinement of the design, has been described. The structure of the model is simple, but allows sophisticated analysis of the process structure, to provide useful insight and guidance for dynamic planning. A measure of the progress of the design process may be obtained, and advice, expressed as simple heuristic rules, can be given on the sequences of tasks that are

ICED 01 – C586/073

351

more likely to be effective in meeting the design goals. Current evaluation results suggest that models can be constructed which provide useful output for its planning and scheduling. Further work will focus on elicitation issues, more complex analysis of the model and refinement of the design process representation. Acknowledgements The authors would like to acknowledge the help of the design group of the Technische Universitat Munchen, and in particular of Ludwig Schwankl, in providing information about the valve design and participating in building its model. References [1]

Westerberg, A W, Subrahmanian, E, Reich, Y, Konda, S et al. (1997), "Designing the process design process," Computers & Chemical Engineering. 21:pp S1-S9.

[2]

Steward, D V (1981), "The design structure matrix: A method for managing the design of complex systems," IEEE Transactions on Engineering Management, EM-28(3):pp7174.

[3]

Ullman, D G, Dietterich, T G and Stauffer, L A (1988), "A model of the mechanical design process based on empirical data," AI EDAM. 2(1): pp33-52.

[4]

Fikes R E and Nilsson, N J (1971), "STRIPS: A new approach to the application of theorem proving to theorem solving," Artificial Intelligence. 2:ppl89-208.

[5]

Clarkson, P J and Hamilton, J R (2000), "'Signposting' - A Parameter-driven Taskbased Model of the Design Process." Research in Engineering Design. 12(1), ppl8-38.

[6]

Clarkson, P J, Melo, A F and Eckert, C M (2001), "Visualisation techniques to assist design 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 Method for 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 Structure Matrix to Estimate Product Development Time," in Proceedings of the ASME Design Engineering Technical Conferences. Atlanta, GA, 13-16 September

Andres F Melo Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0) 1223 332 376 Fax: +44 (0) 1223 332 662 E-mail: [email protected] © Cambridge Engineering Design Centre 2001

352

ICED 01 – C586/073

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

INTEGRATED NEW PRODUCT DEVELOPMENT - A CASE-BASED APPROACH R Valkenburg and J Buijs

Keywords: Design reams, systematic product development, concurrent engineering, empirical study, design education.

1

Introduction

Nowadays we should know how to develop good products; enough theories and methods have been developed to support new product development. Many product development models have been introduced over the years [1, 2, 3, 4, 5]. The developers of such models were people with a lot of practical and/or industrial experience. Although they have not made their experience explicit, you can sense the practical base of most models. Theories and methods, however, are always abstractions from real life. New product development (NPD) in daily practice is much more complex and as a result few practitioners recognise their activities in these theories and models. Most 'model builders' of the NPD-process had an engineering background, and as engineers they were used to building and using abstract models to produce real artefacts. They were also used to working in highly compartmentalised companies. Companies with an R&D department for the development of new technology, a design department to translate this technology into a new product, an engineering department to transfer this new product in something to be manufactured, a manufacturing department to produce the product and ship it to the customers, and finally a marketing department to try to sell the product to the customers. Deep down in their hearts the 'model builders' thought that this well-designed new product was of course instantly loved by their intended customers, and that marketing was not really necessary. They 'sold' their models of the NPD-process in more or less the same manner. They threw it over the wall to the 'users' and expected, not only that these users would be able to understand the model, but that they would use the model as they intended. Models, however, are always an abstraction from reality. The fact that NPD-processes can be divided into separate steps or phases is also usual in daily practice. Managing the developing design content within these phases, or dealing with iterations is also common practice, but hardly ever dealt with in the theoretical models. In daily practice the design task is not clear or objectively stated. Rather, the product developer has to deal with conflicting interests and to consider contradictory demands. The product developer hardly ever works individually anymore; he is a member of a product development team, together with members from other departments in the company, such as marketing, production, purchasing, or (from outside the company) suppliers and potential clients. This 'know-how' led to more refinement of the models, which usually meant more stages, more definitions and more abstract terminology. In short more logic was built into the models, because logic is the language of engineers.

ICED 01 1– C586/137

353

Although the original 'model makers' themselves knew how to play with their own models and were well aware of the limitations and constraints, as soon as these models were introduced in education these models became goals in themselves. Many of the engineering teachers left practice a long time ago and models of NPD became more important than the practice of NPD. We are also taught about these abstract models at university and were never taught about implementing these models in real life. By applying these models to practice (and also by trial and error) we have discovered an urgent need in real life for simpler, more applicationoriented models. In short there is a need for a more realistic approach towards NPD, not just offering a stage-gate model, but also guidelines to implement it in real life situations.

2

Learning from case study material

Since 1976 we have collected case study material on NPD projects. At first these descriptions offered a broad view of NPD [6]. Later, data were collected for research on innovation, which led to 120 case histories [7]. Since 1992 we systematically collect detailed case studies for use in education [8, 9].

1. Some products from our case histories: a package design for a homoeopathic medicine by Claessens Product Consultants, a range of cosmetic organisers by Curver (producer of synthetic household products), a traffic sign by njp|k (design agency), a digital copier and printer by Oce (photocopier company), a truck by DAF Trucks N.V., a patient-communication device by Nira (company for communication devices) in co-operation with Well Industrial Design (design agency), a double decker train by The Dutch Railways.

354

ICED 01 – C586/137

In this paper we will present examples from this last empirical study. The case histories presented here provide a load of information on NPD-projects within companies. Projects varied in size and type of organisation; some take place in design agencies or consultancies (e.g. Claessens Product Consultants, n|p|k, Well Industrial Design), others within companies or multinationals (e.g. DAF Trucks N.V., The Dutch Railways, Oce). Products varied from relatively simple consumer goods (by Curver), to complex technical systems (by The Dutch Railways). For all case descriptions we interviewed at least four participating practitioners, representing project management, product development, marketing and engineering. Figure 1 shows an overview of some of these products. The analysis of these case histories reveals characteristics of an integrated approach towards new product development.

2.1 Integration of product development and strategy The Dutch Railways described their vision in "Rail 21', representing their view on public transportation and it's customers in the future. The project for a new double decker train, which is described in the case history, derives directly from this vision. The photocopier company Oce's choice for digital technology had a large impact on their strategy and product development. Functionalities such as printing and scanning came close to the original 'photocopying', which allowed new, multi-functional products. Besides this, the application of digital technology implies software, which makes the development of software applications as important as the development of hardware. These examples indicate that product development is not an isolated activity. It is an activity that should take place in the middle of the company and it's environment. Through products, the company makes a connection between its own strategic wishes, the needs of its customers, and the possibilities left by its competitors. The integration of product development and corporate strategy is crucial; the company must indicate the role of the newly developed product in achieving the future vision it has set for itself.

2.2 Setting the aims for product development Nira wanted to develop an integrated communication device to be used near a hospital bed, although they realised that this new device would be relatively expensive for the health care market. Until then such a device didn't exist. So the design of such a device would be totally new. Nira choose to collaborate with a design firm, Well Design Associates, to fill the gaps in their knowledge. At DAF Trucks a lot of attention was paid to setting the aims for the NPD-project. DAF Trucks knew the importance of thinking before a project starts. In the 'definition phase' DAF Trucks extensively investigated what the new product should be like and a business case and feasibility study were performed before the 'real' NPD project starts. In this way they try to avoid unnecessary iteration later in the project development. These examples indicate that besides the role of the product in the company's strategy, the company must also have a clear view of what they want with the product, and what the NPDproject aims for. What are the strategic strengths that are built on with this project? What advantages can be made in relation to competitors? What are the most important limitations, risks or key points?

ICED 01 – C586/137

355

2.3 Integration of disciplinary knowledge At DAF Trucks and Oce NPD-projects are systematically performed in teams. At DAF Trucks a 'core team, compiled from different disciplines is given responsibility for the end result. The members of this 'core team' involve people from other departments or even suppliers and customers, if they think suitable. At Oce team work is implemented one step further; all participants of the project, which can have over a hundred people, are co-located. Oce has even built a special building for this purpose, shaped like a UFO. At every round floor of this building, designers, chemists, computer analysts, mechanical engineers, and user interface designers work together on 'islands' of work spaces. R&D-employees are no longer situated in a separate department, but appointed to projects fulltime. NPD being an integrated activity implies that diverse areas of knowledge are needed in NPD projects. This means an integration of disciplines; integrated NPD implies teamwork and revolves around people.

2.4 External orientation DAF spends a lot of time finding out the needs of the customer. This occurs by continuous market analysis and interviews with drivers and distributors, which sustains new truck designs. Before the project for a heavy-load truck started, over 1700 interviews had taken place with customers, truck drivers and 'non-drivers'. In the development of cosmetic organisers for small girls, Curver paid a lot of attention to customer research. The product they were going to design had to address a new target group. Therefore from very early on in the NPD process, Curver did research with focus groups to investigate the feasibility of the product, as well as to collect the target group's wishes for the product. Later on in the project Curver performed concept tests to check the product's functionality, colours, expected distribution and prices. Knowing what products to develop requires the company to be alert to developments in its environment. An innovative organisation can effectively deal with changes in this environment, such as activities of competitors, suppliers and customers, but also the users of its products. Besides identifying threats from the environment, it is even more important to create opportunities and act upon them with new or redesigned products. Dealing with user information plays a central role within this orientation to the environment. Knowing what the customer wants is crucial to success and even customer participation within the NPD-project is becoming increasingly implemented in companies.

2.5

Structuring the process of NPD

Just like getting a good 'feeling' with the content of the NPD-process, the practising of the process and procedures is important. In the collaboration between Nira and Well Design Associates, the development of electronics, software and hardware was carried out in parallel. This can lead to time- and cost saving. But equally it implies a number of organisational and management problems. By using a systematic method, the process can be structured and the participants within the projects can learn a common language. Practice showed that it is not

356

ICED 01 – C586/137

that important which language is used (i.e. saying which NPD model is used), as long as all participants agreed on the same language. The NPD-process in all cases follows more or less the same stages. Of course, for different products and different companies, the emphasis within the processes differs, but milestones like programs of requirements, concepts, and prototypes can be found in all case descriptions.

2.6 Project management Management is about planning and budgets. We learned from the cases that to be able to achieve the required quality on time and within budget, participants have to be motivated and properly lead. Management is about people. The project manager is a facilitator, both on 'hard' issues (the resources) and 'soft' issues (motivation and trust).

2.7 Creativity in the NPD process The Dutch Railways conducted a creativity session with 23 people to make an inventory of all needs and requirements, related to the new double decker trains. At the same time they tried to focus thoughts on the concepts of interior and exterior design, so later in the project everyone would know why decisions were made. Nira and Well Design Associates used a creativity session at the beginning of the NPD project to clarify the points of departure. By defining the aims of the project everyone was able to perform their own part within the project (i.e. the development of the software or the hardware) separately. Too often creativity is associated with 'weirdness', artists, or as a trick. The case descriptions indicate that it is especially creativity that should be integrated systematically within the NPD process. It is certainly useful in the creative phases of projects, such as idea or concept generation, but it is also useful in the orientation of problem areas, and selecting or detailing ideas. Dealing with creativity within a company and stimulating the creative behaviour of employees is too often ignored.

3

Ingredients of integrated new product development

Studying NPD projects provides insights, which are of importance for successful new product development. Few existing models address the integration of corporate strategy and product development, integration of knowledge from all the different disciplines involved in product development and integration of process steps and the management of the quality of the design content within these steps. We have developed an approach that addresses these areas of integration [10]. In our view, integrated new product development is a combination of methodological steps and a way of organising and managing these steps within a dynamic business context. We have introduced a stage-gate model that describes four different stages in the new product development process. In the first stage, 'strategy finding', the strategic direction for the company is stated. During the following stage, 'goal finding', the abstract results of the 'strategy finding' will be worked out into product development assignments. In the third stage, 'product finding', these assignments will be carried out and products will be developed. The last stage, 'implementation', involves the introduction of the product onto the market and

ICED 01 – C586/137

357

into the company. For every stage of this process it is important not only to know what should be done, but also what different tools are available to carry this out. The application of this stage-gate model within the company is as important as the model itself. The organisation and management of this approach in a dynamic business context must be aimed at optimisation of the integration of knowledge. We introduce a multi-functional team approach to new product development, and describe how teams can deal with this complex task. Such a multi-functional team is responsible for the integration of knowledge that is needed in the product development process. We also describe other features of the approach, such as the importance of creativity within the process, and the role of the project leader in the project. Both basic elements of integrated new product development - the stage-gate model and the management and organisation - will be described in more detail in the next sections.

3.1 A stage-gate model Less is more: in our interviews with the different companies we discovered that one of the most important reasons for them to reject theoretical NPD-models is their complexity. Complexity in the number of stages and in the used terminology. NPD-project leaders and NPD-managers want simple models in colloquial language, which are easy to communicate with the members of the multi-disciplinary NPD-team. We looked at numerous models of the NPD-process. NPD-Literature distinguishes five different types of models [11]: 1. stage gate models based on the departments involved; 2. stage gate models based on activities; 3. stage gate models based on NPD-decisions; 4. transformation models; 5. stimulus-response models. We discovered two more: 6. learning models; 7. integrated models. Knowing all these models and working together with lots of companies we developped a model with the least stages which was as integrated as possible. We came up with a four stage model based on the experiential learning model of Kolb [12]. Each of the four stages is aimed at one important goal of the NPD-process. The first stage, 'strategy finding', is aimed at finding the strategic goals of the particular NPD-project. This strategic direction is described in search areas. In the second stage, "goal finding', this strategic direction is translated into the design brief, the specific assignment for the NPD-project team. The result of this stage is the design objective. In the third stage, 'product finding', this assignment is executed and the new product is designed, engineered and tested. The result is the new product. In the fourth stage, 'implementation', the new product is introduced on the market and is used by its intended customers.

358

ICED 01 – C586/137

In the strategic steps we suggest a balance between the internal and external orientation of the company. The company should look at its external context; should know what its customers want and what the competition is up to, in order to know that new future business will be successful. However, the company should also know its internal strengths and weaknesses to firmly base these new businesses. In all stages we distinguish between three streams of information. One based on the companies internal strengths and weaknesses and one on the external opportunities and threads. The third stream is the actual NPD-stream in which these two different flows of information are integrated into the new product to be developed. In the product development oriented steps we suggest integration of the different orientations that are required to develop and implement a new product; e.g. marketing, management, production, product development. In every step of the process we indicate the relevant input from all these disciplines and the integrated result of the step.

3.2. Organising & managing People are the core of every NPD-process. Models without people who are willing to use them are useless. So in our approach organising and managing the people in the NPD-process is as important as the model chosen. We suggest a multi-disciplinary team approach. We call this the Multi-X-approach because maximum diversity of knowledge and insights stimulates the quality of the NPD-process. With Multi-X we stipulate the diversity we are looking for: strive for differences in disciplines, knowledge, gender, age, culture, nationality, etcetra. Of course, at the same moment you want the smallest team possible. Management in general, but NPD-management in particular is about dealing with dilemmas! The Multi-X team itself is not enough. You have to integrate knowledge from group dynamics and organisational development into the approach. If you do not allow time, space and resources for teambuilding, the Multi-X -team will never work. Teamwork requires social interaction and communication of the team members. This implies the challenge to synchronise their thoughts and activities to achieve a design: communication on the content related aspects of the new product development task. It is the project manager's responsibility to achieve good communication in these difficult situations [13]. The role of the NPD-project leader is shifting from leadership to facilitator. But in contrast to the well known idea of the facilitator as content independent our cases and parallel research show that the NPD-project leader should be an expert not only in the NPD-process but also in the content of the particular new product itself. This makes the role of the NPD-project leader very complex indeed.

4. Conclusion Thanks to our research in a large number of companies, which resulted in series of detailed cases, we were able to expand the traditional NPD-approach. From its narrow based engineering type of abstract modelling, to a more integrated and concrete approach in which a simple NPD-model is combined with a way of working with the model. These additions are the multi-X-team, a project management system and applying creativity. It is this multidisciplinary NPD-team which uses the model creatively as a basis for their project management of the NPD-process.

ICED 01 – C586/137

359

We asked the participating companies to give us feed back on our case descriptions. This closing our learning loop showed us that our case based approach is more realistic than the traditional way of describing the NPD-process. References [1]

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 innovation process". R & D Management, vol 14. nr. 1, 1984. [12] [12] Kolb, D.A., "Experiential learning; experience as the source of learning and development". New Jersey: Prentice Hall, 1984. [13] Valkenburg, R.C., "The Reflective Practice in product design teams", PhD Thesis, Delft University of Technology, 2000.

Dr. ir. Rianne Valkenburg and Prof. dr. ir. Jan Buijs Delft University of Technology, School of Industrial Design Engineering, Department of Product Innovation & Management, Jaffalaan 9, 2628 BX Delft, The Netherlands. t: +31 (0)15 2783068, f: +31 (0)15 2787662. [email protected], [email protected] © IMechE 2001

360

ICED 01 – C586/137

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 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 and varnishes

1

Introduction

This article considers the role of material instrumentation in the dynamic of innovation and inter trade cooperation. Within a competitive context, innovation and management of knowledge is an increasing preoccupation in the conception of products. Several actors take part in the product design process. We can quote the designers, the technologists and the marketers: so much competence but different visions. In a first part, we would try to show how material instrumentation can stimulate inter trade cooperation. Then, through an experiment, we would try to show in what material instrumentation can favour innovation.

2

Inter trade cooperation

We gather under the expression " material instrumentation " all the interfaces and physical intermediaries used in the product design process: numerical sketches, plans, instruments, schedule of conditions, models . . . Synonyms of time saving, they have as main vocation, the total or partial realization of the product. Through our experiments, we realized that the use of such instruments supports "a company memory", exchange of the various points of view and communications between the different actors during the design process. Actually, they transform ideas, knowledge, know-how and competence into tangible objects. " These knowledge can result from internal sources (designers memory) or from external sources (documents concerning objects conceived first by the designer or a third" [1] The existence of these physical intermediaries allows to leave a trace of the company's know-how. Thus, they generate a memory and allow the re-use of knowledge and ideas crossed in a new context and through new company actors. They can thus take over " the intentions " which gave birth to the various intermediaries. " The formalization of the various actors points of view via symbols facilitates the construction of a shared sense and enriches exchanges. These symbols constitute objects borders between professions, by mediatory

ICED 01 – C586/572

361

intermediate objects of their relation. They translate their logics and constraints of action and make visible the actors decisions and, give catches to the others ". [2] Furthermore, material instrumentation provokes reactions. It allows the projection of the own knowledge on a tool which crystallizes the various points of view. Besides the problems of respective vocabularies, it is not rare to meet communication difficulties among the different actors. It is not easy to change the point of view. Now material instrumentation allows scoring and clarify each actor's visuals and this precipitate their convergence" / it is by the integration of an important volume of information, competence and ideas that from rich strategic options appear, which allow the company to act of coherent way and to play the set of its advantages. [3] Continuous modeling of actor representations and intermediate materialization within a project of conception returns more explicit action for the others. The creation of a specific physical support clarifies the actions of the various trades and returns so more effective cooperation. The use of these representations and realizations generates strong components of collective training. The set of intermediate successive realizations allows the development of a progressive common project representation by developing its own knowledge. This reflection is illustrated by a visual and tactile inter trade communication support to encourage inter trade communication and to consolidate dynamics of innovation[4], [14]. Indeed, in the example which we shall develop afterward, we realized that there was an important cultural deficit on the characterization of the objective visual and tactile properties of a building material and of its finishing, which makes difficult communication between the various actors and consequently the birth and the broadcasting of new concepts.

3 Experimentation : a visual and tactile support

Visual and tactile perceptions became one set criteria for determining acceptance of many products. Therefore visual and tactile contribution becomes a strategic tool of location and differentiation. It becomes essential to propose to the various concerned actors a support to improve understanding between the various actors to avoid errors of conception due to different interpretations.

3.1 Context Stylistic innovation became an essential factor of competitiveness on markets general public as different as telephony, car design, cosmetic, or household electrical appliance. Material aspects play a dominating and increasing role. For the manufacturer, visual and tactile dimension became an effective means for consumer seduction and the differentiation of the products which bring value in the product. Various processes of transformation of material, surface treatment and decoration allow to act on this finish. In the first rank of which is situated, in number of applications, the painting and varnish technology. Three major actors take part in the conception of product aspects : the designers, the marketers and the technologists.

362

ICED 01 – C586/572

3.2The different actors We met different potential users of this support to list their wishes. The persons who were met arise from different sectors (design packaging and product, car sector, sensory metrology of car manufacturer, paintings and varnishes applicators . . .). So,we were able to identify the fields of mastery of the various actors (table 1).

Designers Marketers

Definitions Define the visual and tactile characteristics of the finishing Advise and sell finishing Work out the formulas of paints and varnishes

Technologists Table 1 Actor's control fields

These various actors communicate all with diffuse vocabulary and with different perception. The stylist designer uses vocabulary which send back to mental images, impressions, feelings. [5]He works mostly by iconographic analogies. " I seek a colour or for a painting which gives an impression of leather " .The technologist chooses technical vocabulary relating to the chemical constituents, concerning the elaboration of the finish (formulation) or the application. " I seek a finish of tint X having a touch leather and applied by automatic pulverizing ".The marketer uses vocabulary focused on the consumer expectations , according to his interlocutor. This variety of vocabulary is frequently source of conflicts and ambiguities, pulling numerous consequences : problems when designing products (identification, decision), problems when developing (paintings and varnishes formulation), problems when producing (serial applications not corresponding to the reference standard).

3.3Tool presentation For this inter trade cooperation tool realization, we leaned on the method of multi-field conception developed within the laboratory ENSAM, Paris. We shall not develop [6] this point, it is not the purpose of this article We have, at first realized a state of the visual and tactile art of paintings and varnishes technology by collecting, with formulators and applicators, representative samples of the various visual and tactile families. This stage is very important because of our will to be most exhaustive possible. The collection of samples partner in the analysis of stylistic tendencies allowed us to loose and to confirm a first list of visual and tactile families. This list turns out necessary for our tool conception and the sensory metrology work, used to characterize the visual and tactile families.

ICED 01 – C586/572

363

The sensory metrology purpose is to describe objectively visual and tactile characteristics of the samples by associating them sensory descriptors and to organize them by families [13 ]. The work made in sensory metrology allows to have one identical "vocabulary" for all actors. We want to propose a physical instrumentation which can live and evolve with the various users : it is not especially a question of conceiving the same support for all. It is important that it adapts itself to all the implied corporate actors and that the various users can communicate with and through him. It is also very important to consider how the various actors work and how they communicate within the tool development. That is why we met different users, coming from different sectors (the motorcar, produced, design, design packaging . . .) in order to identify their needs. This various meetings allowed us to set up a list "use scenarios" and draw up those in which we will find communication problems (figurel).

Figure 1 : configuration ou se posent des problemes de communication

Further to the functional analysis, were defined the points which the visual and tactile support should answer: To identify and to select a touch : help in the creation, helps in the decision. - To propose and to specify a touch : help in the communication. - To control a touch : help in the validation (development / production). -To develop new touchs : help in the characterization of the existing, identification of the ways of development. So the visual and tactile support becomes at the same moment a support of inter trade cooperation and a technological watch tool. The examples of exploitation of the support are numerous and answer problems customers concrete, namely : -To study visual and tactile preferences for the marketing. - To communicate to distance on the visual and\or tactile depiction of a finish. - To know offer in terms of paintings and varnishes. - To present the technological offer. - To know the correspondence of a touch for the development and the production. - To analyze competition (characterization of a visual and tactile products perception, location on a visual and tactile space . . .). - To direct the developments of new touchs (to understand the influence of the various formulation and application parameters, ingredients and processes).Meetings, associated to the need and functional analysis allowed us to write a list of indispensable elements which have to compose our support:

364

ICED 01 – C586/572

Sketch 1 : confirmed principle

The principle which we confirmed is a concrete "multifacet" support articulated around an organization of modules representing one by one the various visual and tactile families. The user can, at first constitute his tool of modules of his choice and develop it by completing it according to his needs. He can also feed it of virgin modules to personalize it, according to the industrial sector for example. The shape of the visual and tactile tool favors confrontation among the three actors because it allows among others : -To compose harmonies -To organize pages of style -To personalize the tool according to its activity -To propose various supports The stylist designer finds there a tool to compare, to choose and to present finishes ; the marketer can present and communicate finishes and the technologist finds there reference standards and all the technical information to formulate and to compare finish applied with samples. Moreover, the descriptors to which various samples are associated offer a system of location, which is the same for the various actors. Every actor can so use the "filter" which is convenient for him and can so understand the way to work of another actor. So, every actor can use " the suited filter " and understand the working way of the others. Rather than to be an universal tool of communication, this tool is in fact a material support allowing the confrontation between the various actors. It offers also easier and more effective communication. The points of view of the different actors converge on this tool. It is so possible to build a real communication between various professions. In the same vision, we can quote a study, basing itself on the phenomenon of color in the product conception realized by Herve Christofol [ 7 ] . This study uncorked in the implementation of an inter trade cooperation tool intended for the designers, for the project managers or for the decision-makers, helping them to understand the phenomenon of the color and to express their creativity within the product conception.

ICED 01 – C586/572

365

4 Discussion and conclusion OCDE defines innovation as an improvement. Thus, a change can not claim to be an innovation if it doesn't bring an advantage for the company, the person and the society. In other terms, " To innovate, it is to take risks, to dash into the unknown, to go to meet the unpredictable ". [8] Innovation is also the capacity to cross of a new idea in marketable object and in a realization of new combinations between various resources professions by the company [ 9 ]. Innovation is collectively admitted as having an individual birth. However, the reason to be is in the sharing. As a result, an innovation does not exist without the membership of the others (hierarchy, users, look for etc. . . .). Innovation is a collective phenomenon but not necessarily voluntary [11]. Indeed, to obtain a gaining change, it is necessary to multiply exchanges enter the biggest number of persons of various professions. As explains it R.W WRIGHT [ 10 ], "Indeed, resources based on knowledge are essential factors of force and constraint in the development of the innovation and the competitive advantage. " In this optics, we recommend the use of instruments physical as " catalyst of innovations ". Our tool modularity allows through the manipulations of the samples to try new combinations without constraints connected to the cost of these attempts. They give concrete expression to new ideas until then little envisaged. Through the unpredictable association of new combinations innovative concepts are born (for example, painting silvered with soft touch) and spread. This broadcasting is facilitated by the use of a realized reference, common to the various actors. Our tool of inter trade cooperation is still in development and it remains completely opened and flexible towards the other sectors in which arises the problem of inter trade cooperation. Moreover, it is very important to formalize such a tool as soon as possible in the product design process in order to avoid conception problems (due to the use of a same vocabulary which doesn't mean the same thing for the different actors, for example) and to improve communication between the different actors. It is evident that this article presents in a concise way made work and that it is not the end in itself. F. Daniellou explains that " competence is not passed on. If one considers them as the track on our body of our personal experiences, it is clear that there is no possibility of " transplant " of the competence of the one on the body to another one " [12]. That is why we decided to create a tool encircling a ground of communication and enrichment : an interactive innovation source.

References [1] Falzon and collar. " Les activites de conception : 1'approche de I'ergonomie collective ", Colloquium Searches on the design, Instigations, Implications, Interactions, 17,18 , 19 Oct. 1990, Compiegne. [2] Vinck D, 1999 Ingenieurs au quotidien. ed. INP Grenoble, ISSBN 2 7061 0876-2 , p177

366

ICED 01 – C586/572

[3] Giget M, 2000 La dynamique strategique de 1'entreprise. ed. Dunod. [4] Stoeltzlen N., on 2000, Conception d'un outil intermetiers. application au domaine des finitions; Memory DEA CPNI, Paris. [5] Lawson B., on 1972, How designers think, architectural Press. [6] Aoussat A ., on 1990, La pertinence en innovation : necessite d'une approche plurielle. document of doctoral thesis CPNI Paris. [7] Christofol H., on 1995, " Modelisation systermque du processus de conception de la coloration d'un produit ". Document of thesis. [8] Interview with Judic J.M. Dr, Faurecia Innovation Department Manager, on 2000. [9] Regenthal, on 1981," Design und seine soziale Funktion ", licht 12/81, p648-655. [10] Wright R.W and Collar. On 1995, " Les principes du management des resources fondees sur le savoir". French Review of management, seven - Oct. 1995 , p70-75. [11] Atkinson A and al., Enhancing the innovation and creativity of technical professionals, technology management. 1988, Publication TM1. [12] Daniellou F, 1999, Actes des journees de Bordeaux sur la pratique de 1'ergonomie. p16 [13] Bassereau, Jean-Franfois.- Cahier des charges qualitatif design, elaboration par le mecanisme des sens.- Thesis ENS AM, 1995 – 16093 [14] Edward T.Hall - La dimension cachee - essai, Edition du Seuil- 1966

Nadine STOELTZLEN, Dominique MILLET, Ameziane AOUSSAT New Product Design Lab. (Laboratoire Conception de Produits Nouveaux et Innovation) ENSAM (Ecole Nationale Superieure d'Arts et Metiers), Paris 151 boulevard de 1'Hopital 75013 Paris, France Tel: (+33) 01 44 24 63 80 Fax : (+33) 01 44 24 63 59 E-mail: [email protected] © IMechE 2001

ICED 01 – C586/572

367

This page intentionally left blank

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

GEOMETRY USERS FROM A PROCESS PERSPECTIVE F Fuxin Keywords: Business process re-engineering, Change processes, Concurrent Engineering

1

Introduction

This paper describes the Process Domain, which constitutes one of the four domains that form the Geometry Management Process (GMP). The main theme is to establish systematic methods, processes and perspectives on Geometry Based Product Information (GBPI). The result will contribute to elimination of rework and to increased integration in the extended enterprise [1]. The Function Domain and the Requirement Domain have been outlined in greater detail in [2]. The fourth domain, the Realisation Domain, deals with ways of realising geometry representations, that is the tools for generating, packaging, and viewing. Figure 1 outlines the structure of the GMP. The original hypothesis has been that it is possible to divide the GMP into four separate domains. The initial efforts were made in the function and requirement domains. This publication deals with the process domain. The domain is introduced in the following chapter. Next chapter presents the proposed process, both a broader perspective and in detail. The final chapter is conclusions.

Figure 1. The Geometry Management Process and relevant domains.

2

The process domain

The gradual transition from traditional towards digital product development will favour a well-established process for managing GBPI. The basis of the process domain relies on studies of the evolution of geometric maturity through different stages of the product development process. All studies and surveys were conducted at the Volvo Truck Corporation in Goteborg, Sweden. In the studies, a portion of a heavy truck front axle assembly was used, see figure 2, but issues that are more general have also been taken into consideration. One of the obstacles to increased integration is that the various activities have to be carried out concurrently. It is therefore difficult to manage and sort all the various perspectives on GBPI. Digital product development results in that the digital master, which must be accompanied by new methods and procedures, will replace the physical master. In a company, there is normally a top-down approach where a project plan prescribes different stages to be carried out throughout the duration of the project. The GMP should support the construction of this

ICED 01 – C586/607

369

project plan. The process domain's most important question to answer is "when"; when has a component, sub-assembly or module reached a level of detail (L.O.D.) where it supports all the downstream requirements of a specific function (e.g. product preparation, marketing)? Furthermore, it should be possible to adapt the process domain to different levels of the project, i.e. from a generic level to direct realisation level for different activities and tasks.

Figure 2. The chosen front axle assembly.

There are many methods and theories for how product development should be carried out. They normally divide the product development process into phases, for example Concept Development, System-Level Design, Detail Design, Testing and Refinement and Product Ramp-up [3], The process proposed in this publication comes from application of a geometrical perspective on tasks, activities and co-operation in the development environment. It is motivated by the gradual transition from traditional towards digital product development and should not be considered as a stand-alone process but as a complement to existing business processes.

2.1 The broader perspective on the development process Conceptual development and detail development deal with the creation of the new product. The geometrical foundation is from the very beginning rather vague for those components/modules that not are directly carried over from previous products. During a given project, the geometrical foundation matures and one stage is replaced with the following one; what is taking place is stepwise refinement. Thus, it is reasonable to argue that the development process is iterative during these stages [4]. The design engineer's knowledge about his/her new component/module grows when new problems are penetrated and solved during evolution towards a product that meets predefined specifications [5]. The various activities throughout this iterative sequence are decomposed and generic elements are synthesised. The resulting activities, inputs and outputs are to be considered as generic constituents that populate a generic process. A top-down approach is applied where an important extra stage, preconceptual development, has been included, see figure 3. The growing importance of GBPI is the reason why the preconceptual stage has been introduced. The geometry users in the last stage, industrialisation, will definitely benefit from adequate and accessible GBPI when generating assemble documentation, educational material, service information and marketing brochures. It should be pointed out that these users not are interested in refining the L.O.D., they are interested in applying already created GBPI. However, the activities will justify additional time and resources spent at the earliest stages on definition and adaptation of geometric information. This is the holistic view of GBPI elimination of rework in downstream functions by a structured approach on GBPI.

370

ICED01-C586/607

Figure 3. Proposed different stages in a product development project.

2.2 Basis for process construction A major project is a complex set of activities that have to be coordinated. A product development process should support and coordinate these activities. Almost all activities that constitute the major process have inputs, outputs and some controls/constraints that must be followed. Furthermore, to realise the activity, appropriate resources and tools must exist. Inputs, outputs, control/constraints and resources/tools are fundamentals of IDEFO. They have been applied to the process domain. From the studies conducted, different factors that influence geometry have been identified. These will be briefly presented. Inputs. Each activity has geometrical input. The L.O.D. will differ depending on where in the process the activity is located. Some fundamental properties of the input will always prevail. The specified product structure must be sent together with the geometric representation, the hierarchical position. The expression "carry-over" has thus far been used for components and assemblies carried over from earlier product projects. A redefinition of this expression is made. The same signification is still valid but it may also denote geometrical input from an earlier activity together with geometrical interfaces for adjacent modules. Resources and tools. Staff and functions that must be made available for fulfilling the refinement activities. Partners and suppliers are also to be considered as resources. The notation tools are the tools needed for realising the refinement activity. The range of tools extends from modelling tools, via assembly and packaging tools to more simple viewers. Controls and constraints. Strategies/rules and guidelines, for example demands on commonality and modules, affect the refinement activities. Time plans are constraints that must be followed. Control of product and process documentation must be undertaken continuously to follow up and secure the project's progress. Output. When the refinement activity is completed, the result - the refined geometrical model - should be made available for subsequent activities. The iterations are caused by what is called geometrical modification requests. Some of the subsequent activities mentioned have an obligation to provide a response. In earlier stages, this obligation may merely comprise simple viewing and communication of opinions, but this could extend to problems, for example when applying the GBPI in assembly simulations. Many of these activities can be directly associated with a given function. Figure 4 illustrates the collected aspects together with some examples taken from different stages.

ICED 01 – C586/607

371

Figure 4. Generic structure for decomposition of the process.

Any shortcomings that are discovered must be corrected and they will inevitably result in iterations. Depending on the degree of the shortcoming, the iteration can be directed to the previous activity or all the way back to preconceptual development, in the worst-case scenario. Each stage should refine its given L.O.D. to its next L.O.D. The refinement procedure is more or less independent of the state to which it is applied. Thus, the refinement procedure is subdivided into three chronological steps. Each step is described briefly. Identification. Each stage, and each activity, receives some type of geometrical representation or definition as input. The objective for one stage will be stated in advance. Therefore it is essential that given geometrical prerequisites are identified, stating how the objective might be fulfilled. Have there been any alterations to interfaces or allocated space? This procedure of identification must be performed before any other activities can be initiated. Optimisation. The degree of refinement will improve during the fulfilment of one stage. The assembly structure and physical functions must be optimised towards the stated objective in each stage. In early stages it is of extra importance that these two are highlighted since there will be no physical prototypes where optimisation of these structures and functions can be performed. The focus will shift once the physical prototypes are introduced, and these prototypes will serve as verification rigs where simulations must be validated. Verification. Conclusions and verifications are always important when summing up current status, especially when the same personnel do not perform forthcoming activities. Have there been changes from the initial geometrical prerequisites; will they affect stages and functions downstream? Are the physical functions verified? Is it possible to manufacture and assemble these components and assemblies? The carry-over of components, assemblies and interfaces are verified and summed up here before being sent on to next stage. Preconceptual development Preconceptual development deals with compilation of relevant geometric information at early stages before the actual development activities are initiated. The objective with this stage is to establish geometrical preferences that are as unambiguous as possible. Some of the recommendations proposed will generate extra work during the earlier stages, in addition to the extra effort that must be invested in summing up all the requirements. Eventually, these extra efforts will pay off when the latter stages utilise already-generated GBPI.

372

ICED 01 – C586/607

Most companies utilise large carry-over percentages from earlier products. In this work, geometrical interfaces are also regarded as carry-over material. Product structure will strongly influence development and utilisation of GBPI. Product structure issues will be interpreted from different perspectives, such as modular/commonality and geometry users' perspectives. The matter of uncoupled development activities must be addressed during the preconceptual development phase. There are several reasons for conducting uncoupled development, for example advanced engineering projects or other major systems with their own development cycles. Nevertheless, by properly introducing them at this stage, preparations can be made for their incorporation. The finalisation of the preconceptual development is completed when the degree of refinement of the L.O.D. has reached envelope. Identification. This geometrical input to the preconceptual development stage is composed of carry-over material. On top of these prerequisites, considerations must be given to variants of the future product and to requirements of geometry users who will participate in the forthcoming effort. In this context, carry-over material is regarded as either geometrical representations from previous product projects, geometrical interfaces between different modules (or sub-modules/components) or modules originating from uncoupled development activities. Identification of carry-over material is one of the primary objectives since it will serve as a reference for the space allocation of envelopes and decisions upon interfaces. For components and modules that are to be designed, these geometrical entities will serve as boundaries in the development work of each module. The product-planning department will specify which variants are to be included in the project. The specified variants are generated by a modular structure where commonality aspects are taken into consideration. The proposed method for categorisation of geometry users will add additional requirements to the product structure. Thus, by utilising this methodology, relevant GBPI is generated and in this way, geometry users are taken into consideration from the very beginning of the future project and rework in downstream activities is reduced. The refinement procedure for the preconceptual development stage is synthesised in figure 5.

Figure 5. The preconceptual process procedures.

Optimisation. Preconceptual development does not primarily deal with physical function and assembly structures. However, since the geometrical definitions are carried out in the identification procedures, it is feasible to undertake the first preliminary checks of physical functions and assembly structure. Verification. The output from preconceptual development is compiled here. Are the original specifications fulfilled? Is it possible to geometrically generate all variants in a systematic manner? Will different categories of geometry users have access to relevant geometrical configurations? In the verification procedure, response must be received from areas with long

ICED 01 – C586/607

373

lead-times. This last remark concerns manufacturing and assembly operations where implementation times normally are crucial for entire projects and for their success. There are also other aspects to decide on when specifying the geometrical requirements of the project. One such aspect concerns communication between companies and suppliers, or partners, when there are different CAD systems [6]. Specifications should be made for neutral formats, and perhaps appropriate application protocols, for communication. Conceptual Development The primary objective of this stage is to evaluate several possible proposals and to reach a final concept. The geometrical input to the conceptual stage is more rigid due to the introduction of the preconceptual stage. For a specific module, the geometrical refinement activities will depend on just how many carry-over parts can be used. The result is that some organisational functions will have to start with an envelope with accompanying interface/interfaces. Other functions should concentrate on optimising an already existent concept and updating interfaces to surrounding modules. From the geometrical point of view, the vague envelopes, together with more defined GBPI, should at the end of the stage form a draft L.O.D. Since one or more design functions may not often be located in the same building, or even the same part of the world, regular collation and follow-up are important. Communication is one of the keys to success for the project. Collaborative work and distributed engineering must rely on, and have access to, reliable GBPI. Identification. The input to this stage consists of a mix of envelopes, interfaces and carryover parts/modules. A module will always have one or many interfaces. This is valid for both envelopes and carry-over modules/parts. The first step towards finalising the concept is to agree upon the interfaces. Different modules are joined by interfaces and so too are the organisational functions responsible for the modules. Interfaces are the physical connections to adjacent modules and they are therefore the facilitators of the physical function specified. The envelopes serve as boundaries when evaluations of different concepts are made. The geometrical interfaces connect the different envelopes. All concepts generated will be evaluated against each other and against how well they fulfil the specification of the new product. The geometrical refinement activities depend on the amount of carry-over parts. Initially, organisational functions sharing an interface must ensure that the interface fulfils all connection requirements. Once a mutual agreement on interfaces is established, the focus is turned to physical function and product structure requirements. Optimisation. At this stage, preliminary evaluations must be conducted for the most credible concepts. Carry-over modules and parts have a well-founded geometrical basis from which to start off. Concepts starting with an envelope will have to be further refined before evaluations can be performed. The lack of physical prototypes implies that most decisions must be made from digital simulations and analyses. Even with low level of detail, it is today possible to perform extensive evaluations; e.g. technical calculation and motion/clearance analysis. This of course requires that the company has built up methods and procedures for supporting assessment during the early stages. Product design is one area where visualisation techniques have made it possible to iterate faster. Verification. Before the conceptual development stage is concluded, the physical function, assembly structure and product variants must be verified against the product specification. The end result is the concept that will go through detailed design. The L.O.D. must at least be of draft quality. Drawings have in the past been the only way to communicate with

374

ICED 01 – C586/607

downstream stages. The computerisation of all stages has made it possible for downstream functions, for example production preparation, to both view and utilise already created GBPI. In the latter stages of the refinement procedure of the conceptual development stage, most functions should have access to the draft L.O.D. Management of variants and versions is extremely important. The more functions involved in refinement activities, the greater the emphasis on this type of management. The digital master replaces the physical master, and that lasts for the entire product lifecycle. It must constitute the master reference for all variants and versions. Detailed design The detailed design stage encompasses the fulfilment of the highest level of detail and in the end the introduction of physical prototypes. The gradual transformation of the GBPI, from draft to detailed L.O.D., is associated with rigorous efforts. The generation and distribution of adequate geometry representations rely on competent management of the GBPI and the way in which it should be made accessible to all personnel involved. The concept of digital masters must be clearly stated, communicated and utilised. The initial refinement activities must focus on securing physical function and on ensuring that all suppliers are well informed about the requirements concerning their components and systems. This is the prerequisite for the first generation of physical prototypes. Critical areas and parameters detected from previous activities must be incorporated. There are several functions downstream of detailed design that have high requirements on the level of detail. Some of these functions are to generate illustrations or market material with a high level of both detail and visualisation. Other activities will run in parallel with the refinement activities of the relevant stage. The coordination of geometry-based product information between the parallel activities is important. Identification. Draft is the lowest L.O.D. of carry-over material to enter this stage. Critical parameters detected during optimisation and verification in the conceptual development stage are invaluable as input to the detailed stage. One example is critical clearances detected during motion analysis. There are several functions waiting for the level of detail to reach their set requirements. It is essential to identify when these requirements will be met at this stage. This is necessary in order to be able to start up these activities as soon as possible. An update with the uncoupled activities will identify if there are any mismatches in co-ordination. Before the final refinement activities are initiated, all interfaces should be thoroughly analysed regarding physical function fulfilment. Optimisation. GBPI must be optimised in several different aspects to reach detail L.O.D. It is not until this stage that the utmost refinement can be performed. All radii, chamfers and tolerance zones should be optimised for low weight, tensile properties and cost. Packaging studies, computational models, endurance simulations, manufacturing logistics, assembly operations, maintenance simulations - all these must in the end be performed on real physical products. The physical prototypes that are built are thoroughly selected. The selection is based on earlier experience and from critical specification detected in the conceptual development. In order to further refine and optimise digital product development, any detected mistakes caused by incorrect assumptions in the computer models must be properly documented. They will serve as input to the geometrical prerequisites in the next project. Verification. The physical prototypes must be verified against the product specifications. The prototypes will also verify if it is possible to assemble the products as intended. Verification should be made against rules and regulations (certifications). Verification must also be made

ICED 01 – C586/607

375

of the GBPI against the physical prototypes, taking into account tolerance management and measures. One of the prerequisites for digital product development is that the GBPI will reflect reality. Some approximations will always be done and it is extremely important to document this knowledge about what should be considered as an acceptable approximation.

3

Conclusions

The investigations and studies have clearly indicated that there is a need for a Geometry Management Process. Furthermore, the GBPI must be viewed from a holistic perspective to take full advantage of digital product development. The method of categorisation is one way of mapping corporate requirements on GBPI. It has been proven that it is possible to take the requirements of different categorises of geometry users into consideration in the product development process. The process perspective makes it feasible to detect when the requirements are to be met in the product development process. The breakdown of the process domain into different levels makes it feasible to bridge gaps between project management and personnel working in the line organisation. This article deliberately makes no mention of any tools or systems since it presents the process domain. However, it should be pointed out that in the CAD tool most geometry refinement activities take place. Packaging and viewing tools depend on a geometry base originating from the CAD tool. In these tools, no design modifications are made. Acknowledgements Financial support for this research was provided by Volvo Truck Corporation and the Swedish Strategic Foundation's national programme ENDREA (The Swedish Engineering Design Research and Education Agenda). References: [1]

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". CONCURRENT ENGINEERING: 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 Process Organization". Volume 1, Prentice Hall, 1996.

[5]

Blessing, L. and Wallace K. "Supporting the Knowledge Life-Cycle". Ifip Tc5 Wg5.2 Third 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: [email protected] © IMechE 2001

376

ICED 01 – C586/607

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

CONCURRENT DESIGN OF PRODUCT AND PACKAGE - EXTENDING THE CONCEPT OF IPD C Bramklev, R Bjarnemo, and G Jonson Keywords: Integrated Product Development, Interviews, Design of Packaging, Survey

1

Introduction

As a result of the globalisation of the world economy, many enterprises that previously confined their business activities to national markets are now focusing on broader international markets, thus forming the basis for the establishment of global enterprises. In addition to the extension of markets, these global companies also seek cost reductions through scale economies in logistics, marketing, product development, production and purchasing, and through focused manufacturing and/or assembly operations - Christopher [5], Porter [10]. In order to contribute to the establishment of global enterprises, an interdisciplinary research project has been launched at the Department of Design Sciences, Lund University, Sweden, as a collaborative effort between two of its divisions - Machine Design and Packaging Logistics. The overall objective established for the project is to: "facilitate the establishment of successful global enterprises by providing methods, techniques and an overall procedure model for integrating packaging logistics into the product development process. " By extending the concept of Integrated Product Development (IPD) to include the concurrent design of product and packaging, increased efficiency and effectiveness in the product development process are conceivable. Apart from the apparent advantage of reducing the time to market, environmental impacts in terms of a reduction in the consumption of raw materials due to the possibility of facilitating a "tailor-made" packaging of the product are also conceivable. As a result of the development of more efficient and effective packaging of the products, a reduction in emissions from the distribution of the products is also expected. For the development of the product-to-be, the packaging might provide alternative, less costly, solutions; this especially applies to those products, which have to withstand major structural loads during the distribution phase of the product life cycle. The overall concept of integrating relevant activities from the packaging logistics area into the IPD process has been introduced in a previous paper - see Bjarnemo et al [1 ]. In the paper presented here, the main objective is to:" establish the industrial relevance of introducing the concurrent design of product and packaging thus supporting or rejecting the key element in the previously developed integration concept. " The secondary objective is to: "obtain more detailed information on the actual handling of the interaction between product and packaging design in industry." The latter information is intended to be used either for the further development of the extended IPD concept or for providing a more detailed view why the integration concept has to be rejected.

ICED 01 – C586/609

377

In order to obtain the information requested, an explorative survey has been performed in Swedish industry. The findings from this survey and its implications, as outlined above, are reported here.

2

Basic concepts

In a literature survey reported in Johnsson [7 pp 36-37], a large number of definitions of packaging were found. Based on Paine [9], the following definition has been derived and adopted here: "Packaging is a means of ensuring safe and efficient delivery of the goods in sound condition to the ultimate consumer followed by an efficient reuse of the packaging or recovery and/or disposal of the packaging material at minimum cost". In this definition, "packaging" should be interpreted as ranging from simple wrappings to advanced specialpurpose containers, thus also indicating the hierarchical nature of packaging. One alternative, and maybe a more operational view of the subject in the given context, is to focus on the product features needed in the different phases of the product life cycle. By considering packaging as an "extension" of the product during the manufacturing phase until it is installed/mounted and the packaging is removed from the product, an understanding of the integration of the design and development of packaging and product is facilitated. As long as the technical performance of a product constituted the single most important competitiveness factor on the market, an efficient and effective approach to the design of the product-to-be alone represented the most effective and efficient means of increasing competitiveness. However, as the adaptation to business, industrial design, market/consumer, production, sales etc. became equally important in handling the competition on the global market, new methodologies focusing on the overall development process, the product development process, were developed. Note that the creation of procedure models for the product development process represents an extension of the previous models provided within (engineering) design methodology. In other words, the design procedure becomes embedded in the product development procedure model - see Bjarnemo [3]. The common denominator in these new product development procedure models is the close interaction between a number of the functions of the enterprise, such as design, market, production and sales. Another characteristic of these procedures is the organisation of the work in cross-functional teams. Undoubtedly, the most significant driving force in the development of tomorrow's product development procedures will be the rapid development in modern Information Technology (IT) - including not only hardware and software computer components, but also the links for digital communication. Since communication is the essence of integration, it is only logical to focus on the IPD- procedure as having the inherent potential to become the most successful development procedure of tomorrow in the light of the product development procedures existing today - see Bjarnemo [2]. The product development procedure model referred to here is the original one developed by the late Professor F. Olsson - see [8]. At the Design Policy Conference in London in 1982 this model was revised and renamed. The revision and renaming were undertaken by Professor Olsson in close cooperation with three Danish researchers, Professor M.M. Andreasen, F. M011er Pedersen M.Sc. and Technical Director L. Hein. Together they

378

ICED 01 – C586/609

presented the new procedure model under the name Integrated Product Development or simply IPD, see Hein et al. [6]. In Olsson's original model, the procedure integrates four functions or subprocesses: market, production, (engineering) design and business/finance. In the IPD procedure model, the procedure is decomposed into five stages. The underlying strategy utilised for the decomposition of the complete development procedure corresponds to the decomposition of the design phases of the underlying design methodology, which means that the inherent logic of the engineering design process forms the basis of the whole procedure model. In turn, each and every one of these design phases is decomposed on the basis of a five-step creative problem solving procedure. The most important conceptual cornerstone in the building of the IPD procedure is integration. In this context, "integration" should be interpreted as connecting people, processes and technologies. However, when integration is mentioned, it is usually "vertical" integration between the functions (i.e. between the people and the subprocesses) which is referred to. It is important not to forget "horizontal" integration, or maybe more adequately in the present context, the compatibility between the subactivities forming each of the stages of a given function. In other words, the latter integration/compatibility refers to the integration along the time-axis of the project and within each and every one of the subprocesses, thereby focusing not only on connecting people and process but more specifically, on connecting technologies which focus on the product-to-be.

3

Survey approach

As the IPD procedure model originates from studies of product development processes within mechanical engineering, it is suitable to confine this survey to the same area for theoretical as well as practical reasons. The classification of a product as mechanical is simply based on the fact that its main working principle constitutes the technical realisation of physical (mechanical) effect(s), or that a majority of its subsystems in turn are based on mechanical working principles. In future projects, additional product areas such as those of medical and pharmaceutical devices as well as food and dairy products will also be surveyed. The lack of a commonly accepted terminology creates major problems whenever attempts are made to extract information from mechanical engineering processes, especially when design and development processes in industry are surveyed. To decrease the impact of these problems to some extent, a survey technique based on the combination of a questionnaire and an interview was chosen - see Bjarnemo [4]. In this combination, the questionnaire is simply intended to prepare for the interview, as far as possible. After the interviews, the responses, as transcribed by the interviewers, were sent back to the respondent(s) for correction(s), if necessary. Other issues related to the survey were: •

Selecting companies and identifying respondents

•

Formulating relevant topics for the interviews

ICED 01 – C586/609

379

3.1 Selection of companies and identification of respondents In addition to being a company developing, producing and distributing their own (mechanical) products, the company selected should not be situated too far away from Lund; 200 kms was deemed "not too far away". Within this area there are no larger mechanical engineering companies, which confined the survey to small and medium sized companies (SMEs). The number of companies, i.e. the sample size, was set at 20. This is a number, which ensures the existence of a corresponding number of companies within the other products areas of interest to the future surveys. Furthermore, the companies were selected "almost" at random. In the present context, "almost" refers to the fact that a majority of the companies are not totally unknown to us, at least not as far as their product development functions are concerned, but we are not familiar with their handling of the development of packaging issue. In each of the companies selected, the product development manager was approached and asked to be responsible for the answers given by the company. This gave the product development manager the freedom to select who was going to answer/discuss the interview topics with us.

3.2 Formulation of topics for the interviews The preparation of the questionnaire focused on six main topics. These topics/questions were: 1. Company characteristics 2. The process of product planning/product renewal 3. The company's product development process 4. The role of packaging 5. The interaction between packaging and product 6. The role of packaging in the product development process today and tomorrow These topics provide the information necessary for being able to answer the overall questions presented in the objectives established for the project reported here. For each of the topics above, a number of questions were included in the questionnaire and discussed during the interviews. Due to the qualitative nature of the questions and the fact that this survey is of an explorative nature, statistical methods will not be used in evaluating the results. However, statistical methods will be used in the evaluation/comparison of the overall results from this and future surveys.

4

Survey results

As previously mentioned, each interview was prepared in advance by confronting the product development manager with the six topics and their corresponding questions. In a majority of the interviews, extensive discussions followed each question. For obvious reasons, full accounts of these answers have not been included in the presentation of the survey results below.

380

ICED 01 – C586/609

In order to limit the presentation of the findings of the survey to the relevant issues with reference to the objectives established for this paper, the main part of the answers/information obtained is given in the form of a "Yes" or a "No". All the results have been condensed into two tables. In Table 1, each of the companies is introduced with reference to what kind of products they develop and produce. The size of the product development staff as well as the investment in R&D (in % of the annual turnover) are also included in order to give an insight into the company resources available for product development and design. The final question accounted for in Table 1 is the use of a formalised approach to the product development/design processes. Note that the term formalised approach simply indicates the existence of a procedure model to be followed in the development process and that this procedure is documented. The term is used in order to avoid any value added characteristics such as methodical or systematic. Table 1. Topics 1-3: Company characteristics, PD1 staff and resources and the use of a formalised approach

Company

Products

8 15

Pot washing machines

6

5

Sights for firearms Parts cleaners for body shops and tire shops Dialysis machines and equipment Heart-Lung machines and heater coolers Web cleaners, tension control, breaks and pumps Aseptic dosing units / machines for foods Walk-behinds and lawn mowers

4.5 5

7 7 5

Fuel handling systems for petrol stations Products / systems for handling coins and banknotes

K L M N

Injection moulding of pharmaceutical devices

Q R

s

T

Staff

Investment Formalised in R&D development (% of process turnover)

30 25

A B C D E F G H I J

O P

PD'

Telecom heat exchangers Hygiene systems within geriatric care Industrial metal products; white goods Brakes and brake systems Door automation systems Exhaust extraction systems Power transmission parts and components Recycling systems for stores and industry Industrial door systems

90 6 2

25 2

No Yes Yes No Yes Yes Yes No Yes No Yes

15 1 11

10

2 15

20

No

4 2

Yes Yes No Yes Yes No Yes Yes

5 47

18 7 12

3 14

2 15

4 2 4.8 4 4 3

'PD = Product Development

As expected, and useful for the survey, the products supplied by the companies cover very diversified markets. As for resources for the product development function, these range from a staff of 1 up to 90 people; consultants are not included in these numbers. When the investment in R&D is compared, there is a clear demarcation as to which of the companies are relatively newly established and/or have adopted a pioneering product strategy, and those companies which have established themselves on mature markets and thus keep a lower development profile. Note that 35% of the companies claim that they are not using formalised

ICED 01 – C586/609

381

approach to the product development process. This figure may be somewhat misleading as, some of the companies that give a negative answer do use a formalised approach in the actual development process, even though it is not fully documented. In Table 2 the main results, referring to topics 4-6 of the survey, are presented. Table 2. Topics 4-5: Package specifications and relation package - product Topic 5 - The interaction Topic 4 - The role of the Topic 6 - The role of the packaging packaging between packaging and product in the PD-process today and tomorrow

A B C D E F G H I J K L M N 0 P

0 R S T

Y Y Y Y Y Y Y Y Y Y Y Y Y Y N Y Y N Y Y

I, P I, P I, P, Eg Eg, Ex,T, P, L P P, R P P Au, Ce, P, L I, L, P, T Au, H, I, P As, P Au, L, P I, Ex, P P As, P P P P Ce, P

Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N Y

Y Y N N Y Y N N Y Y Y N Y Y Y Y Y Y Y Y

N Y N Y Y Y Y Y N Y Y Y Y N Y Y Y N Y Y

Y N Y Y Y N N N Y N Y Y Y Y N Y Y N N Y

N N N Y Y Y N N Y N Y N Y Y Y Y Y Y Y Y

Y Y N Y Y Y Y N Y Y Y Y Y Y Y Y Y Y Y Y

Y = yes, N = No As = assembly/installation support Au = support mfg. automation Ce = cost effective Eg = ergonomic

Ex = expose product P = protect H = hygienic R = environment friendly I = carry information T = traceable L = logistics and distribution adopted

Regarding the specification of the packaging, 90% of the companies carry this out as a part of the overall development project. It was also clearly indicated during the discussions that not only the packaging as such, but the whole product distribution chain, are identified today as being significant factors in the overall development efforts. Not very surprisingly, protect was identified as the single most important packaging function. In i.e. 7, 35% of the companies, this was the only function required of the packaging. The second most important packaging function, corresponding to 30 % "Yes" from the companies, is to inform. In 5, or 25%, of the companies, packaging was used as an integral part of assembly/installation and automation in the manufacturing process. However, several other companies are contemplating this use of packaging.

382

ICED 01 – C586/609

In all but one of the companies, the development of the packaging was carried out within the product development project. Even though 75% of the companies claim that the packaging helps to withstand structural loads during the distribution phase, only one of the companies was actively planning to integrate this effect in the actual design of the product. One apparent problem for a majority of the companies, or 75%, was the necessity to decompose the product into subsystems in order to facilitate the transportation of the product. The problem referred to here is the need for costly assembly operations in the field. 60% of the companies agreed that better packaging could contribute significantly to cost reduction. 65% were aware of the customer's demands on the packaging. Note that a number of the companies defined their own personnel installing the product as "customers". In no less than 90% of the companies, the integration of packaging and product development was considered to be an interesting and promising concept.

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 of packaging and product! A second important findings in the survey is that our previous, preliminary extension of packaging logistics into the IPD process can be given a more definite form. In the preliminary version, packaging logistics was simply considered the "fifth function" to be accounted for during the IPD process. The reason for not integrating packaging logistics into one or more of the four existing functions (market, design, production and business/finance) was the lack of information provided by the second question under topic 4 - see Table 2. On the basis of this information we have drawn the conclusion that packaging development should be integrated into all of the functions. In order to provide substantial support for facilitating this integration process, we have identified packaging design as the key element in the process. Consequently, a parallel research project has been launched, in which a computer based analysis tool to support the designer during the combined efforts of designing product and packaging is under development. The tool is based on newly derived constitutive models of corrugated board material and EPS, utilising a combination of powerful FE-codes such as ANSYS and LS-DYNA. Dr. Ake Burman and Lie. Eng. Martin Eriksson, both at our department, carry out the project. An example is given in Figure 1 below. We have also found a far greater interest in these matters than we anticipated at the beginning of the project. In some of the companies, our survey was considered to have started an internal process of discussing the benefits of paying greater attention to the development of packaging. It should be noted that this process might actually have started long before the companies participated in our survey. The number of considerations and measures already taken by the companies evidences the existence of such a process. One example is the widely adopted concept of integrating, at least formally, the development of the packaging into the overall product development project.

ICED 01 – C586/609

383

Figure 1. FE-simulation of packaging and product-courtesy A. Burman and M. Eriksson

6

Acknowledgements

The authors would like to acknowledge the generous support given by the Swedish companies 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, Royal Institute of Technology, Stockholm, 1998, pp 137-146

[3]

Bjarnemo, R., "Product Renewal by Using IPD", Proc. ICCIM'97. Singapore, pp 951960

[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, The Design Council, 1984, pp 86-90.

[7]

Johnsson, M., "Packaging Logistics - a value added approach", Department of Engineering 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 DESIGN ICED 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 requirements of a support system for distributed conceptual design. Distribution offers a number of advantages over co-located design, and the infrastructure for global design is growing rapidly. A variety of systems for the detailed design phase have already been successfully employed in industry, but conceptual design has received little attention up to now. Based on the "Design Assistant" by Schuster [1], a support system that guides a distributed design team systematically through the initial stages of the mechanical design process, as set out by Pahl & Beitz [2] and summarised by Ullman [3], is described. The focus of this paper is on a methodology for a distributed team of designers in comparison to classical methods for colocated design. In this context the integration of suitable tools for communication, information transfer, and design content input plays an important role.

2 A framework for distributed conceptual design Product design and development has become a global process. Distributed product development offers a means of including the know-how of experts from all over the world and of making use of resources at different company sites, in different countries [4]. This results in reduced costs and lead-time, as well as in increased quality. The challenge is to connect designers and design teams worldwide and to make formal information exchanges among them more effective and user friendly. Support systems for distributed design must strive to provide the same functionality and convenience that the designers are used to in working with their co-located colleagues. Currently available support systems, e.g. the framework of Huang & Mak [5], implement methodical conceptual design in a distributed environment, but fail to provide proper tools for communication, information transfer and design-content input. A system of three segments, which complement one another and can interact closely, is necessary. The segment "Design Methodology" places a methodology that guides designers through the conceptual design phase and offers tools for concept generation and evaluation at their disposal. The segment "Communication and Information Transfer" co-ordinates the communication between the distributed designers and provides a platform for the exchange of design-related data, e.g. customer requirements, ideas, sketches, comments and decisions. Both segments make use of the third segment, i.e. a support service for various input devices. Figure 1 illustrates the three main segments of a distributed conceptual design environment.

ICED 01 – C586/049

385

COMMUNICATION AND INFORMATION TRANSFER

DESIGN METHODOLOGY • Distr. Conceptual Design Methodology • Methods and Tools - Lists of Requirements / QFD - Morphological Charts - Creativity Techniques

• • • •

Team Management Phone, E-mail, Videoconferencing Shared Workspace, Bulletin Boards Online Catalogues

INPUT DEVICES FOR CONCEPTUAL DESIGN • Graphic Tablet with Pen, Scanner, WebCam, etc.

Figure 1. Main segments of a distributed conceptual design environment

The proposed framework comprises a number of software components referred to as "Assistants". These provide the functionality and the user interfaces for the segments mentioned above. The segments and the accompanying framework components will be described in more detail in the following chapters.

3 Methodology for distributed conceptual design Classical design methodologies, like the methodologies described by Pahl & Beitz [2], Ullman [3] or in the VDI Guideline 2221 [6], provide a systematic and well established approach to the design process. These methodologies were analysed to determine their suitability for a distributed design scenario and recommendations for improvement were made.

3.1 Specification development The design process starts with an idea or a need for a new product or a product redesign, as expressed by a customer. The customer can be an external client and/or a department within the company. The recording of the customer requirements usually does not involve the whole design team. This step has therefore to be carried out as accurately as possible, in order to reduce later enquiries to a minimum. In particular, distributed team members far from the customer's location may find it difficult to get in contact with the client. Pahl & Beitz [2] recommend using a requirements list containing the "Wishes" and "Demands" of the customer in a standardised form. The use of uniform lists and questionnaires make the distribution of design specifications easier, since the conversion between file formats, a common source of errors and omissions, is reduced. Checklists containing general and specific objectives and constraints support the process of creating and updating the requirements list. Ullman [3] bases the development of the engineering specification on the "Quality Function Deployment" (QFD) technique, although Suh [7] states that it is only useful for redesign. For a distributed design environment QFD is particularly valuable because of its high information content and the comprehensible graphic representation in the form of the QFD "House of

386

ICED 01 – C586/049

Quality" matrix. This step ensures that the problem is understood by all team members, which is a vital aspect, especially for a distributed team. The "Specification Development Assistant" supports the user in recording the customer's requirements and establishing the engineering requirements. Every customer requirement has to be linked to at least one engineering requirement and vice versa. Every team member can make contributions to both lists. The team manager can organise all entries into categories and check the lists for completeness. A "House of Quality" can also be created. Since group discussions cannot always take place, each matrix entry can be annotated to inform the other team members of one's reasoning or to give additional information.

3.2 Functional analysis The next step is the functional decomposition of the design problem into an overall function and multi-level sub-functions. For distributed design teams a hierarchical, numbered treestructure is more suitable than graphic-oriented diagrams, e.g. functional flow charts, since the tree-elements, their positions and their linkages with each other are easier to record, to store and to impart to the other team members than graphical components. After the decomposition, the lower-level elements of the hierarchy can be grouped into logical units, i.e. related functions or functions that might be satisfied with similar solutions. This procedure is also known as "Functional Packaging" [8]. The functional analysis is supported by the "Functional Analysis Assistant".

3.3 Concept generation For each low-level element of the tree-structure, i.e. the sub-functions identified in the previous step, one or more suitable solutions must be found. Various techniques to support this process are included in the framework. The proposed solutions for the sub-functions are then combined to a number of concept proposals to satisfy sub-concepts, i.e. functional packages, or the overall function. The "Concept Generation Assistant" is used to describe each solution with a short phrase. The entry can be accompanied by more detailed textual descriptions and links to graphic files, e.g. sketches, diagrams or images from a catalogue. References to other sub-functions can also be made, e.g. when these can be satisfied by the same solution or when an off-the-shelf component is a practical answer. By using one solution for multiple sub-functions it is possible to reduce the component count of the developed product. Each designer can go through the concept proposals generated by the other team members to stimulate creative thinking and eventually lead to more and better solutions. In case too few or unsatisfactory solutions have been identified for a particular sub-function, the team manager can initiate a brainstorming or brainwriting session. Brainstorming and brainwriting are valuable methods, especially when used as computer-based tools in a design group [9]. Brainstorming sessions can be held in the form of group-chats or videoconferences, with the team manager or another person guiding the discussion, taking notes and distributing the collected information to all team members. The biggest problem here is the coordination of a suitable time for all participants. Brainwriting sessions are time-wise unrestricted, since they can run asynchronously. Brainwriting, also called "Method 635", makes use of forms that circulate in the group to collect ideas and at the same time stimulate the designer.

ICED 01 -C5 86/049

387

The number and quality of ideas produced during distributed and co-located brainstorming sessions depend on the knowledge and experience of the participants rather than on their location. The personal interaction of the designers, e.g. the exchange of models and gestures, and the cross-stimulation resulting from it, is an important aspect of a brainstorming session. Nevertheless with the right technical equipment the negative effects of being distributed on the intercommunication could be reduced to a minimum. Other problems, such as a designer's "fear of being foolish" or the use of so-called "Killer-Phrases" might even be neutralized due to the lack of personal contact. For the generation of concept proposals, the "Concept Generation Assistant" provides a list of the functions and sub-functions and their possible solutions. Each user can select one solution for every sub-function and combine them into a number of concept proposals. This approach is similar to the use of a "Morphological Matrix" [2], but does not automatically create a vast and incalculable number of concepts. Instead it allows for the development of numerous different concept proposals that already went through an initial selection process, namely the choice by the user. This increases the chances of obtaining a large number of high quality concepts. The number of concepts generated by each designer is dependent on the time available, the company policies and, of course, the quantity the design team feels comfortable with.

3.4 Concept evaluation The concept generation is followed by a screening process to eliminate all proposals that do not meet the previously established requirements or that are regarded as not worth further consideration, based on the designer's "gut feel" [3]. Discarded concept proposals are not deleted from the pool, but marked as rejected. In this way they can still serve as a source of inspiration for the designers during the refinement of the other concepts. Different techniques can be used, from simple yes/no-voting to short group discussions, depending on the team manager or on the company's policies. The remaining concept proposals are evaluated in order to determine the most suitable ones for further development. The "Decision-Matrix-Method", or "Pugh's Method" [10], is used to score each alternative concept, relative to another. According to Ullman [3] this method is most effective if each team member performs it independently, to avoid any influencing, and the individual results are compared. The distributed team is therefore not at a disadvantage when using this method. The "Concept Evaluation Assistant" helps each designer to check for compliance with the initial customer requirements and the evaluation criteria. It supports the designers in weighting the criteria and assessing each concept proposal, and calculates the final score.

3.5 Design review and team management In both co-located and distributed design teams the role of the team manager is very important. The team manager has to decide on an applicable strategy and to coordinate the separate steps of the design process. In many cases the team manager does not directly participate in the design process, but rather supervises the progress of the team. The proposed framework includes a "Team Management Assistant" which provides, among other tools, a questionnaire-based method for design team formation, as recommended by Wilde [13].

388

ICED01-C586/049

All the steps of the procedure presented above can be performed either synchronously or asynchronously with the other team members, depending on the scenario and available equipment. Each phase should be concluded with a design review, moderated by the team manager. These reviews are important elements of the methodologies described by Ullman [3] and Blanchard & Fabrycky [8]. hi a distributed environment the meetings and the exchange of notes provide a deep insight into the project (this is natural in co-located design groups). The users are also encouraged and aided in documenting all their steps in order to allow the fellow designers, or designers of follow-up projects, to understand the decisions made. A "Documentation Assistant" provides templates and guidelines for the proper compilation of the conceptual design specification and other reports. It also assists in integrating the various tables, notes and graphics generated during the conceptual design phase into the project documentation.

4 Communication and information transfer A greatest disadvantage of distributed design is the restricted communication between the participating team members. Designers in a co-located environment can call for a meeting whenever necessary, but conferences in distributed design teams have to be planned more carefully. Considerations such as office hours in different time zones as well as the availability and suitability of communication tools have to be taken into account. With the continuous expansion and the increasing capacity of the World Wide Web, communication is no longer restricted to telephone, fax and postal mail. Traditional and modern communication means are complementary and should be used in an optimised way. The "Communication Assistant" is a support tool for all communication issues. It keeps track of team members logged into the system, displays the status of availability for synchronous communication, i.e. phone, chat or videoconferencing, together with the necessary contact details, and provides an interface for e-mail, chat and a message board. Information transfer during the conceptual design stage differs from the later phases in content and frequency. The exchanged information consists in many instances of sketches, ideas, mock-ups and other difficult to grasp objects. As the amount of information increases it becomes more and more inconvenient to distribute files in a design team by electronic mail. An alternative is to publish the information on a shared workspace system. The participating designers now do not have to send every bit of information to every team-member that they assume will be interested in the information. Instead, the designers upload their data only once to a shared workspace server, like the BSCW system developed by Bentley et al. [11], and download only the information they need. This also helps to maintain a certain level of consistency, i.e. all team members can work with the same version of a file, as earlier investigation by the authors have shown [12]. Designers need a global perspective of the project they are working on and therefore should have access to as much information as possible, for instance in form of online catalogues and Internet search engines.

5 Input devices for conceptual design Distributed conceptual design makes special demands on the input devices used. While standard tools, such as a mouse and a keyboard, meet the requirements of subsequent stages

ICED 01 -C5 86/049

389

of the design process, e.g. CAD during the detailed design phase, they are often impractical in creating or annotating a sketch. The proposed framework takes this into account by integrating hardware and software from other disciplines, e.g. graphical design. A case study was carried out by the authors [12] to evaluate tools used for synchronous and asynchronous collaboration in distributed conceptual design. Of particular interest was the suitability for the exchange and discussion of difficult-to-grasp design information, such as ideas and hand-sketches. The tools included telephone, fax, e-mail, videoconferencing and a shared workspace environment, as well as various input devices, such as a scanner and a graphic tablet with pen. The case study confirms the advantages of pen-based sketch input over standard input devices, like the computer mouse, in terms of speed and quality. Personal experience of the first author also indicates the value of digital cameras and WebCams to capture and exchange design information in form of sketches, notes on white-boards, and three-dimensional mock-ups.

6 Conclusions The investigation into the practicability and the requirements of a support system for distributed conceptual design shows that most elements of classical design methodologies are also applicable to distributed design. Especially the structured approach is an advantage in distributed design environments. But it is not enough to develop a number of tools for design methodology and provide access to this system from different locations. Ullman [3] states that "communication is one of the key features of concurrent engineering, and effective communication is essential among design team members." A methodical approach must be accompanied by a system to enhance the communication and information transfer between the participating designers and support their interaction. The framework segments "Design Methodology" and "Communication and Information Transfer" cannot be put to good use without the provision for advanced input devices, fast and accurate enough to capture a flash of inspiration before it disappears. The framework for distributed conceptual design is currently under development and will be used for validation case studies.

Acknowledgements The financial support of the National Research Foundation (NRF grant GUN 2034084) and the Stellenbosch University Research Committee is gratefully acknowledged. References [1]

Schuster, H.R., "A Computer Aid for Specification Development, Conceptual Design and Manufacturing Cost Estimation in Mechanical Design", Ph.D. Thesis, University of Stellenbosch, South Africa, 1997.

[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 and Development Processes", Proceedings of the 1999 ASME Design Engineering Technical Conferences. Las Vegas, 1999, DETC/DTM-8777.

[5]

Huang, G.Q. and Mak, K.L., "Web-based Collaborative Conceptual Design", Journal of Engineering Design. Vol. 10(2), 1999, p. 183-194.

[6]

VDI, "VDI Guideline 2221 - Systematic Approach to the Development and Design of Technical 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". Prentice Hall, Upper Saddle River, 1998.

[9]

Holt, K., "Brainstorming - From Classics to Electronics", Journal of Engineering Design. Vol. 7 (1), 1996, p. 77-82.

[10] Pugh, S., "Total Design - Integrated Methods for Successful Engineering". AddisonWesley, Wokingham, 1991. [11] Bentley, R., Appelt, W., Busbach, U., Hinrichs, E., Kerr, D., Sikkel, K., Trevor, J. and Woetzel, G., "Basic Support for Cooperative Work on the World Wide Web", International Journal of Human Computer Studies: Special issue on Novel Applications of the WWW. Academic Press, Cambridge, 1997. [12] Schueller, A. and Basson, A.H., "Case Study on Synchronous and Asynchronous Communication in Distributed Conceptual Design", to be published in Proceedings of the 2001 International CIRP Design Seminar. KTH Stockholm, Sweden, 2001. [13] Wilde, D.J., "Using Student Preferences to guide Design Team Composition", Proceedings of the 1997 ASME Design Engineering Technical Conferences. Sacramento, 1997, DETC97/DTM-3890. Prof. Anton H. Basson Department of Mechanical Engineering, Stellenbosch University, Private Bag X1, Matieland 7602, South Africa, Tel: +27 (0) 21 808-4250, Fax: +27 (0) 21 808-4958, E-mail: [email protected], URL: http://www.mecheng.sun.ac.za/

©IMcchE2001

ICED 01 -C5 86/049

391

This page intentionally left blank

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

A SYSTEM FOR CO-ORDINATING CONCURRENT ENGINEERING R I Whitfield, G Coates, A H B Duffy, and W Hills

Keywords: Tactical design co-ordination, distributed design, concurrent engineering.

1

Introduction

Design of large made-to-order products invariably involves design activities which are increasingly being distributed globally in order to reduce costs, gain competitive advantage and utilise external expertise and resources. Designers specialise within their domain producing solutions to design problems using the tools and techniques with which they are familiar. They possess a relatively local perception of where their expertise and actions are consumed within the design process. This is further compounded when design activities are geographically distributed, resulting with the increased disassociation between an individual designer's activities and the overall design process. The tools and techniques used by designers rarely facilitate concurrency, producing solutions within a particular discipline without using or sharing information from other disciplines, and seldom considering stages within the product's life-cycle other than conceptual, embodiment or detail [1, 2]. Conventional management and maintenance of consistency throughout the product model can subsequently become difficult to achieve since there are many factors that need to be simultaneously considered whilst making a change to the product model. Concurrent Engineering (CE) is often regarded as a means of significantly reducing design time to enhance competitive advantage by maximising the amount of parallel design activities. Winner et al. [3] described concurrent engineering as: "a systematic approach to the integrated, concurrent design of products and their related processes, including manufacture and support. This approach is intended to cause the developers, from the outset, to consider all elements of the product life-cycle from conception through disposal, including quality, cost, schedule, and user requirements." This definition is representative of many of those encountered in that the main emphasis is placed on its systematic approach to the design process as it reduces the design time and hence total design cost, which is one of the main considerations in the entire design process. CE however cannot be fully realised without co-ordination [4] and given a co-ordinated approach without de-coupling dependencies, concurrency will only be achieved where the design process permits. The DMS is intended to tackle some of the issues arising from the above statements by providing a formalism that would enable the design process to be co-ordinated in a tactical manner. This involves determining the actions required to be undertaken to perform a specific task for the right reasons, to meet the right requirements and to give the right results [5].

1CED01-C586/114

393

Design co-ordination is a relatively new concept within the engineering design community and is aimed at improving the performance of the engineering design process. One of the most prominent frameworks associated within design co-ordination is the Design Co-ordination Framework (DCF) [5]. The DCF presents a number of frames, each of which is aimed at representing different aspects of design co-ordination. The DCF also describes the management of the links between the frames. The research presented in this paper identified that tactical co-ordination may be represented by: the goal/result model; the discipline/technology model, and, the task model frames within the DCF. These models are described within section 3. The focus of this tactical design co-ordination system is the management of design tasks, information, goals and rationale within the product development process such that the process may be performed in a timely and appropriate manner. The Design Management System (DMS) was used to manage and co-ordinate these tasks, and evaluate the constraints, maximising concurrent design activity, whilst maintaining inter-task dependencies. Close contacts with industry were maintained during the research programme which focused on the development of the DMS system towards tackling design issues that were considered pertinent to the companies such as reducing design time, ensuring informational consistency, and facilitating, not automating, the decision making process. An application of the DMS within an industrial case study is demonstrated within section 4. The case study represents a number of inter-dependent tasks that need to be performed and constraints that need to be satisfied for the design of a stage of blades within a steam turbine. Conclusions and recommendations are made within section 5.

2

DMS architecture

The DMS was constructed to co-ordinate the design activity of an agent-oriented design process with respect to managing design tasks, information, goals and rationale, and facilitating the decision making process. A basic representation of a software-based design agent was produced to: manage the functionality of existing design tools; enable communication with the DMS and other design agents, and, demonstrate how the distributed design problem may be managed and co-ordinated. The focus of this work was, however, not towards the development of autonomous agents. Malone et al. [6] proposed two design principles for the design of agent-based systems which were used during the development of both the DMS and the associated design agents: "Don't build computational agents that try to solve complex problems all by themselves. Instead, build systems where the boundary between what the agents do and what the humans do is a flexible one." "Don't build agents that try to figure out for themselves things that humans could easily tell them. Instead, try to build systems that make it as easy as possible for humans to see and modify the same information and reasoning processes that the agents are using."

2.1 The discipline/technology model The discipline/technology model represents the disciplines which are present within the product as a whole and also within its subsystems [5]. The model also indicates which

394

ICED 01 - C586/114

technologies are required for the design development, as well as displaying how the disciplines and technologies are distributed over the artefact. Within the context of an agent-oriented distributed design architecture, the discipline/technology model represents the structure of the agents and the technologies that they utilise. That is, the agents and associated design tools often reflect the discipline knowledge and technologies within the domain. The model also contains information pertaining to the tasks that the design agents are capable of undertaking. Through the production of a design process displaying the inter-dependencies between the tasks, it is possible to display the relationships between the design agents as well as the technologies. The design agents register their information with the DMS to enable communication, as well as providing information regarding the tasks that the agents are capable of undertaking. Currently this process is confined to software agents, where the tasks that may be performed are defined by the functions that the associated design software may achieve. However, developments are underway to define and model tasks and their associated disciplines and technologies within the DMS to enable the management and co-ordination of human agents. The DMS may manage human agent task enactment by sending an email to an engineer containing a description of the task that needs to be performed as well as the information required to perform the task and the information that the task will produce. When the task is completed the engineer would submit the produced information back to the DMS.

2.2 The design process builder and task model A graphical user interface was developed which would enable the designer to define the design process at any level of abstraction using information obtained from the discipline/ technology model. A number of different events were defined such as: perform task; branching operations (to facilitate concurrency); process pause; and, decision events, which could be used to define the process as well as co-ordinate the activities of the design agents. The Design Structure Matrix has been adopted as a mechanism for managing the tasks and inter-task relationships within the design process [7, 8]. This concept has been extended such that iteration and decision based branching may be represented within the design process with each process having its own matrix representing the tasks that need to be undertaken to achieve a particular goal. Providing individual representations in this way has enabled the overall goals of a process to be identified based upon the tasks contained within it, as well as enabling the DMS to manage more than one design process simultaneously. Allowing simultaneous management of processes further increases the functionality of the DMS since different aspects of the same design problem may be modelled and evaluated concurrently, for example the determination of the performance of a design artefact within different life phases. The DMS not only manages the dependencies within each individual process model, but also manages the dependencies between process models that are required to co-ordinate concurrent design activity. The new Design Structure Matrices also include decision based dependencies to provide an exit condition from an iterative loop. A number of partitioning and concurrency based criteria were included to evaluate the performance of the design process.

ICED 01 -C586/114

395

2.3 Process information model The DMS contains a formalism for the management of design information based upon an object-oriented approach. Currently, four different types of information have been developed based upon this formalism: Parameter, Option, File and File Group. The formalism requires all design information used within the DMS to inherit from a base class which provides mechanisms for comparing different pieces of information, serialising information such that it may be communicated across a network or stored persistently on a disk, and enabling information to be displayed graphically within the DMS. Extending the base class enables new types of information to be developed to suit the intended application. For example, if the design problem is to develop an internal combustion engine, the base class could be extended to produce a new information type which provides all of the information required to represent a piston. In addition, this information may be displayed three dimensionally within the DMS, enabling the designer to visualise the information, as well as modify it. Knowledge may also be included within the new information type to constrain how the information may be changed. Each design process has an associated information model, containing information that has been either provided or produced, which is stored centrally within the DMS. When a new piece of information has been generated as a result of performing a task it is placed into the produced area of the information repository, replacing existing or outdated information as necessary. The DMS allows concurrent access to the information model by multiple agents.

2.4 The goal/result model The DMS does not attempt to take the decision making process away from the designer, instead, it facilitates the decision making by providing the designer with information which would enable decisions to be made more appropriately. Using parametric information made available from within the process information model, it is possible to construct and evaluate mathematical expressions which represent certain requirements or constraint-based goals of the design process, such as, for example, checking that the calculated efficiency is greater than a minimum efficiency. The design goals will be evaluated automatically when the design process has been enacted and the design solution for a particular design concept produced. If a goal has not been satisfied, then the user is notified of the problem, such that decisions may be made with respect to the design concept in order to satisfy the goal. The DMS currently lacks optimisation-based goals, i.e. there are no mechanisms for expressing the goal, "maximise efficiency". Current developments within the DMS include a suite of optimisation software for both the optimisation of the design process and the design product. The optimisation software includes: a robust design tool which may be used to either increase the robustness of a product, or give a good "ballpark" design which is near the optimum, a multi-criteria genetic algorithm which either may be applied to optimising the design process or product, and a multi-criteria simulated annealing algorithm which may also be applied to optimising the design process. Both the multi-criteria genetic algorithm and simulated annealing algorithm have been implemented within the design structure matrix and have successfully demonstrated that the design process may be improved with respect to both concurrency and partitioning.

396

ICED 01 -C586/114

3

Implementation and case study

The industrial case study used to validate the DMS software consisted of the co-ordination of a number of disparate design agents that were used to evaluate particular aspects of the performance of a stage within a turbo-generator. The associated tasks are represented within the design process seen in Figure 1, which describes the activity that needs to be performed to determine aerodynamic, stress, and vibration characteristics of the turbine, as well as providing information regarding the dependencies between the tasks. The design process area also contains a list of the information that is provided as input to the design process which describes the design concept to be evaluated, a list of output information which describes the corresponding design solution, as well as a list of design goals.

Figure 1. DMS Showing Bladepath Design Process.

A Design Structure Matrix is also used to represent the tasks and dependencies of the design process and provide evaluations of design process based performance criteria. A number of optimisation algorithms may be used to re-sequence the tasks within the design structure matrix with the objectives of improving the process performance with respect to the partitioning and concurrency criteria. Different weightings may be applied to the dependencies to represent strong and weak relationships. In this particular example however, all of the dependencies are defined as being strong since it is not possible to start a tool prior to the completion of a preceding tool.

3.1 Previous implementation A typical evaluation of a design concept started with the production of a preliminary concept which would provide the necessary information for the process. The concept would then be

1CED01-C586/114

397

evaluated through the enactment of the design process shown within Figure 1 requiring the manual execution of each of the tools in the order depicted by the design structure matrix. The flow of execution through the process is from top to bottom, although it may be modelled in any direction within the DMS. It can be seen from Figure 1 that certain tasks may be undertaken concurrently, however the process was generally managed by a single designer, and as such proved to be difficult to manage more than one tool simultaneously. Upon completion of each task, the information generated required moving to the correct location for the following tasks to maintain informational dependencies. This process was undertaken manually, and found to take approximately 11 minutes. The design solution, spread across a large number of files and a number of different disciplines, would then be examined to extract certain information which would be used within additional manual calculations to determine whether the design concept satisfied the design constraints. Rules would then be applied based upon the designer's experience to vary the parameters, changing the design concept to satisfy these design criteria. A number of iterations are generally required to satisfy the constraints.

3.2 DMS implementation Design work commences with the design agents registering with the DMS. Agent details are registered within the discipline/technology model of the DMS. This initial communication informs the DMS that the specified agent is capable of undertaking some design activity. The DMS then makes a request that the design agent provides information regarding the nature of the design activity that it can undertake. This information will take the form of a list of tasks, details of files or parameters that the task may require, constraints that need to be satisfied prior to task enactment, and files and criterion that result from the enactment of the task. These task details may be either low-level or high-level terms and may describe an individual atomic task or a group of tasks depending upon the level of abstraction of the implementation of the design agent. The design process may then be designed by decomposing it into the relevant tasks available. Informational dependencies must be maintained during the design of the process. The DMS will notify the user if a task has been included within the process that requires information that has not yet been produced. The task would then disable itself until this informational dependency has been satisfied. The consequence of ensuring informational dependency is that tasks may not be decoupled, and concurrency may only occur as defined by the process. The design concept to be evaluated may be selected and modified by viewing the input files within the design process. Once a suitable design concept has been defined, the process is started with the DMS communicating to the design agents in turn providing them with the necessary information to undertake the current task. Once the design agent has processed the information and executed the associated tool, the design agent will notify the DMS of the information that has been produced from the tool. The DMS then determines from the design structure matrix which tasks are now capable of being enacted and communicates with those agents in a similar manner. Once the process has been completed, the DMS will evaluate any goals that have been provided and notify the user of the outcome. Experiments using the DMS to co-ordinate the activity of those agents operating on the same workstation have produced the same results as that produced using the applications manually, but within 75% of the time due to the removal of the overhead associated with manual enactment. The experiment was repeated with the agents distributed across a number of workstations, resulting with a 46% reduction in the time taken to evaluate the concept whilst

398

ICED01-C586/114

guaranteeing the consistency of the information within the process. This greater reduction was due to concurrent design activity across a number of computational resources. The DMS also ensures that if an application failed to produce a solution, a warning would be issued to the user with a description of the nature of the failure, and the remaining tasks would be suspended.

4

Conclusions

A new approach to tactically co-ordinating distributed, agent-based design activities has been presented. The approach enables concurrent engineering to be realised through the management of dependencies. From a CE perspective the focus is more towards enabling concurrency, rather than maximising concurrency by de-coupling activities, thus allowing the design process to progress naturally. The approach was evaluated using an industrial case study that had a well-established design process. The activities within the process as well as the management of the information resulting from the activities were previously performed manually using a number of different computer-based design tools. Upon completion of the process, the results from the design activities would be used within calculations to check that the design concept satisfied the constraints. Alterations would subsequently be made to the parameters that were thought to be preventing the concept from satisfying the constraints, and the process would be repeated until the design concept fulfils these requirements. The time taken to evaluate a design concept through the manual enactment of the process was approximately 11 minutes. Each design tool was subsequently managed by a design agent within the DMS. The design process was then constructed using information obtained from these agents. Through the management of the dependencies within the process, two threads of concurrent activities were made apparent. The evaluation of a design concept was managed using the DMS using the same platform as the manual test with the agents distributed across three Ultrasparc workstations and produced a reduction in process time of approximately 46%. This time obviously depends upon the amount of the resources available to the agents, however, the same principle applies for the manual case, and in both the manual and DMS experiments, the resources had 100% of the cpu available to the user. This time may be considerably reduced further with the inclusion of a generic "operational co-ordination" module [4] through the dynamic co-ordination of resources. The DMS was also responsible for managing the constraints such that the stresses within the blades and the vibration characteristics met certain pre-determined requirements. This was achieved by altering various geometrical characteristics of the blades using specific guidelines.

5 Acknowledgements The authors gratefully acknowledge the support given by the Engineering and Physical Science Research Council who provided the grant RES/4741/0929 that enabled this work to be undertaken. Additionally, the authors acknowledge Siemens Power Generation Systems, for their advice, expertise and for providing the case study.

1CED01-C586/114

399

References [1]

Coates G, Whitfield RI, Duffy AHB & Hills W, "A Review of Co-ordination Approaches and Systems - Part II: An Operational Perspective", Research in Engineering Design, Vol. 12, No. 2, 2000, pp. 73-89.

[2]

Whitfield, RI, Coates G, Duffy AHB & Hills W, "A Review of Coordination Approaches and Systems - Part I: Strategic Perspective", Research in Engineering Design, Vol. 12 No. 1, 2000, pp. 48-60.

[3]

Winner RI, Fennel JP, Bertrand HE & Slusarczuk MMG, "The Role of Concurrent Engineering in Weapons System Acquisition", IDA Report R-338, Institute of Defence Analyses, Alexandria VA. 1988.

[4]

Coates G, Whitfield RI, Duffy AHB & Hills W, "Enabling Concurrent Engineering Through Design Co-ordination", 6th ISPE International Conference on Concurrent Engineering, Bath, United Kingdom, September 1-3 1999.

[5]

Andreasen MM, Duffy AHB, MacCallum KJ, Bowen J & Storm T, "The Design Coordination Framework: key elements for effective product development", International engineering design debate: The design productivity debate, Meeting; 1st Sept. 1996, Glasgow, pp. 151-174.

[6]

Malone TW, Lai K & Grant KR, "Agent for Information Sharing and Co-ordination: A History and Some Reflections", Software Agents, AAAI Press, 1997, pp. 109-143.

[7]

Eppinger SD, Whitney DE, Smith RP & Gebala DA, "A Model-Based Method for Organizing Tasks in Product Development", Research in Engineering Design, 6, pp. l13, 1994.

[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. Whitfield CAD Centre, Department of Manufacturing and Engineering Management, University of Strathclyde, 75 Montrose Street, Glasgow, Gl 1XJ, Scotland. Tel.: +44 (0)141 548 3020 Fax: +44 (0)141 552 7896 E-mail: [email protected] Formerly: Newcastle Engineering Design Centre, Armstrong Building, University of Newcastle upon Tyne, Tyne and Wear, NE1 7RU, England. Tel: +44 (0)191 222 8556 Fax: +44 (0)191 261 6059 E-mail: [email protected] © IMechE 2001

400

ICED01-C586/114

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

DISTRIBUTED PRODUCT DEVELOPMENT - A CASE STUDY IN INTERORGANIZATIONAL SME BUSINESS NETWORKS J Pilemalm, S Gullander, P Norling, and A Ohrvall-Ronnback Keywords: Industrial case study, industrial co-operation, SMEs

1

Introduction

The globalisation increases the competition and causes many companies to live under a heightened strain. Companies are faced with completely new demands and challenges. Some companies are, however, creating new opportunities by increased co-operation across boundaries. Small and Medium sized Enterprises (SMEs) working together in interorganisational business networks enable entirely new business opportunities by means of aggregation of their resources and knowledge. Such networks make it possible for SMEs to develop and to offer more complete systems and products that could not without great difficulties, or at all, be offered by individual companies alone. This implies a need for research and knowledge development in the area, especially regarding how to perform distributed development of new products.

2

Objectives

The purpose of this paper is to present the results of a study investigating how companies in business networks communicate and collaborate between themselves and with customers, throughout the complete product development process. More specifically, the objective is to investigate factors that facilitate successful collaboration in networks, and if distributed product development can be applied in the Integrated Product Development (IPD) methodology, even when the team is dispersed. IPD is a concept for increasing efficiency and learning in industrial Product Development (PD) [1].

3

Theoretical framework

In order to respond to new challenges companies have to be dynamic and fractal. A fractal company is an independently acting corporate entity whose goals can be precisely described. It has an integrating approach where integration not necessarily needs to remain in the factory. In this way, a network of companies is created [2]. Cooperation across boundaries in interorganisational business networks enables SMEs to develop and to offer more complete systems and products in virtual organisations. There are several possible ways for creation of such organisations. One is when a leader enterprise builds a virtual organisation by involving partners to a specific business venture. A second is when one or several companies seek to join forces with similar partners to achieve a whole greater than the sum of its parts. A third is when a company creates a unifying factor and engages other parties [3].

ICED 01 - C586/145

401

According to one study, which focuses on coordination and control of interdependent actors in networked biomedical projects, it is indicated that there are certain factors inherent in networks contributing to the success in PD. Examples of such factors include ambiguities about authority relations, geographical dispersion, sensitivities about intellectual property, and problems with knowledge capture and information flow. Further, the importance of different issues varies between networks but also from phase to phase in the networked projects [4]. Previous research regarding SMEs has demonstrated that existing resources, the product type and the project scope influence the design process. Accordingly, three models based on the type of design activities performed, are proposed: Original design that includes all development steps, and the intended product is new to the company and has no prior design history. Evolutionary design that is intended to development of a new product that is basically based on a previous design. Incremental design used for minor changes to an existing design [5J. Most smaller companies do not see any problems in distributed activities [6], This indicates that SMEs could perform PD jointly in inter-organisational business networks. IPD is a concept for achieving efficient PD where integration refers to multifunctional integration between organisational functions, hierarchical levels, activities, divisions and across companies. The performance of IPD is characterised by parallel activities, crossfunctional collaboration, structured processes, and front-loaded development [1], [7], To perform IPD, using network structures is supposed to be a suitable organisational approach to make dynamic and flexible procedures in PD possible. Several advantages have been noted, such as distributed and flat structures, know-how building and knowledge transfer, access to complementary abilities as well as quality, cost and time advantages [8].

4

Research method

The research project "Distributed Product Development" (DPD) is one of several sub-projects in a project named "New Industrial Cooperation". The overarching project aims at industrial guidance to SMEs in cooperation in PD, but also at long-lasting collaboration between Swedish manufacturing industry, a research institute and several universities. The research question to be answered in DPD is: How should distributed product development in business networks be performed to enable efficient development from idea to final product? This will be answered through identification of important factors that, when exploited in the distributed PD, enhance the probability for obtaining the desired outcome compared to when an ad-hoc distributed PD is practiced. The question will also be answered through analysing to what degree and how IPD has been performed in the cases. In this paper an inter-organisational SME business network (IOBN) is defined as a virtual company consisting of SMEs and connected to a regional or local network. Two types of lOBNs will be discussed in this paper: IOBN with an own product (IOBN-P), and IOBN developing a subsystem as a consultant to an external customer (IOBN-S). In order to answer the research question, three lOBNs were investigated. Approximately 25 companies and organisations have been involved in the study. First several regional networks were contacted with the aim to find and select three regional networks containing at least one IOBN. The key persons at the regional networks were interviewed to identify and elucidate the main actors in three lOBNs (Case A, B and C), one in each regional network. Then the persons involved in the PD at the lOBNs were interviewed. Finally the customers were interviewed. The data was collected through semi-structured interviews, which are

402

ICED01-C586/145

characterised by open questions. The interviews were recorded on tape and transcribed. The analysis was carried out through a process were the material was structured through allocation of codes. The researchers represent different subject fields: Industrial -engineering, -organisation, -marketing, and -economics, which imply a multidisciplinary approach.

5

Results

The analysis indicated that some aspects were particularly important for the PD and the success of the lOBNs. Those aspects are presented in three sections below. First the two types of lOBNs are described. Thereafter factors judged as important for successful collaboration in lOBNs, and to what degree and how IPD has been performed in the lOBNs are presented.

5.1 Two types of inter-organisational SME business networks Two types of lOBNs were studied. Figure 1 supports the description of the IOBN-P case and Figure 2 the two IOBN-S cases. Both figures visualise the cases over time and organisationally. In the left section of the figures the involvement of the customers, the collaborators (e.g. C1A in Case A), and the supporting organisations (e.g. S1C in Case C) are visualised over time. The organisations are marked as dark grey horizontal bars. Dotted lines indicate surrounding organisations that might have played some role for the project. The time when the main contract came into enforcement is also indicated. In the right section of the figures, the organisation of the lOBNs and the surrounding organisations are shown. IOBN-P are visualised with a solid rectangle and IOBN-S with a dotted rectangle. Each organisation is visualised with a circle. The adjacent regional network is visualised with a large dotted circle with minor circles symbolising the members. The regional networks surrounding the lOBNs The three regional networks were started during the 1990s. The regional network in which Case A was found, acts in mechanical industry and has approximately twenty members. Case B was found in a regional network that is active in the electronics industry and has only three members. The regional network in which Case C was found, acts in the polymer industry and has approximately twenty members. The main goal of the three regional networks is to support the members, especially by creating new business opportunities. There exist different opinions among the interviewees whether some of the specific lOBNs studied are results of the regional networks or not. Case A - A business network with an own product The idea to Product A emerged in relation to an outrage with several persons killed by a rifle. The inventor realised a need for a gunlock for rifles and started to outline a solution. The inventor who was without experience from the industry contacted some friends and together (CIA) they got into touch with local authorities (SIA and S2A) to ask for support with the first phases of this original development. The customer, which is a government authority, had realised the same problem as the inventor and issued a purchasing request. To continue with the next step it was realised by CIA that more actors were needed. Company C2A was contacted first, thereafter C3A to C5A. The regional network (S3A) might have played a part in finding the right companies. An external independent project leader (S4A) was engaged to manage the project. When finally the order for manufacturing was received (by C3A) from

ICED01-C586/145

403

the customer (Customer A), the IOBN-P established a common enterprise (C6A) to fulfil the order, but also to perform future projects and business opportunities.

Figure 1. Organisations involved in business network A. Case B - A business network developing a subsystem on request from a customer The three members in a regional network (SIB) had manufactured parts of the previous version of the current subsystem, which is a regulation system (Subsystem B) to specific ventilation equipment. When the customer (Customer B) was planning for a new generation of the product, a dialogue was held with C1B. The dialogue ended up with a contract for an incremental design between C2B and the customer. The reason for choosing C2B was their experience of project leadership and of assembling similar products. One person at C2B performed most of the development alone. However, to some extent he had support from C1B, C3B, the customer, some suppliers and other personnel at C2B. The result from the development was judged as successful. Case C- A business network developing a subsystem on request from a customer The idea for the complete product, which is a medical device, originated from a researcher (SIC) who also developed the first prototype. The idea was bought by a company (Customer C), which held the formal leadership of the development of the complete product. Customer C delegated the development of the mechanics (Subsystem C) to a firm of consultants (C1C) but developed the electronics itself. The PD can be judged as a compromise between original and evolutionary design. C1C is an experienced firm of consultants with a network of suppliers, both internal and external to the regional network (S2C). One person at C1C performed the bulk of the development work unaccompanied. However, to some extent he had support from C2C, CSC, the customer, some suppliers, and staff at C1C. The regional network (S2C) might have played a part for finding the right partners. The result from the IOBN-S was judged as successful and an almost complete supplier network came with the subsystem.

404

ICED 01 -C586/145

Figure 2. Organisations involved in business network B and C (B within brackets).

5.2 Important factors for successful collaboration in lOBNs In this section six factors observed from the three cases judged as vital for successful collaboration in lOBNs are presented. The factors are intensive dialogue, geographically proximity, clear goals and responsibilities, complementary resources, straight business relations and early determination of reward and risk system. In all the three cases there was an intensive dialogue. This was most prevalent in the IOBN-P were all the participants were involved in regular discussions. The physical meetings were frequent and according to the interviewees the participants worked as a real team. The physical meetings within the lOBN-Ss were fewer, but there was an almost daily communication through telephone and e-mail. Consequently there were intensive dialogues, mainly between two persons at each time. In the IOBN-P problems and possible solutions were discussed together which led to better solutions than if the work should have been performed individually. The prevalent intensive dialogues in the IOBN-P indicated increased unanimity, openness and confidence, which was not equally evident in the lOBN-Ss. The requirement specifications were made in terms of functions rather than in technical details and this lead to an intensive dialogue between the customers and the lOBNs. The communication was mainly held between the contacts at the customer and the contractor. The dialogue was especially intensive at the lOBN-Ss. It was mentioned that the contact people should preferably possess equivalent technical competence and be on the same level, and also that the customer had to get the impression that the contractor would manage to fulfil the contract. The need for intensive dialogue made the geographical proximity obvious, especially in Case C in which the involved organisations were dispersed across large distances. According to the interviewees the geographical distance affected the frequency of physical meetings negatively. This was not estimated as critical, but the cooperation could have been even better with less distance.

ICED 01 - C586/145

405

Geographical dispersed teams with less physical meetings imply increased importance of clear goals and responsibilities. However, the distribution of the work differed between the 1OBN-P and the lOBN-Ss. In the latter the responsibilities were fairly clear, which was facilitated through clear interfaces in the products and the subsystems. In the IOBN-P both the team and the product were integrated to a high degree, which made clear responsibilities somewhat less important. Nevertheless, the activities surrounding the PD, e.g. purchasing and marketing were clearly distributed in all the lOBNs. The need for complementary resources was important for the lOBNs. In all the three cases the resources were complementary even though exceptions existed. In the IOBN-P the potential order was so big that the manufacturing resources had to be partially overlapping. Further, in Case C the designing company was replaced due to close down. The lOBNs were based on straight business relations. This was obvious between the lOBNs and the customer as well as between the lOBNs and their subcontractors. None of the customers considered the network organisation form at the lOBNs as important. From their point of view they made a business agreement with one single company. The main importance in the business agreement was mentioned as threefold: the function of the product or the subsystem, the price, and the time for delivery. Previous contact and references, and personal chemistry were also mentioned, but only at the IOBN-S. Finally, ISO 9000 certification was mentioned as important. The contractors mentioned previous contacts as important regarding their choice of partners and subcontractors. There was also some degree of favouritism; the contractors preferred partners and subcontractors from the local region. The contractors' cooperation differed much between partners and subcontractors. The latter's knowledge was mainly used in the late PD phases, and the adjustment of detail to their manufacturing processes was lesser than to the partners' manufacturing processes. To the majority of the companies, the business deals were relatively great. Therefore, early determination of reward and risk system was judged as important. The IOBN-P had a potential for a very large order and even larger in the future. The partners invested much time and money in the PD, but did also receive financial support from external organisations. The partners shared the complete risk of the project and also agreed on sharing possible profits. This was early formalised. The IOBN-S in Case B had a potential for a fairly large order, but the PD was paid trough payment for prototypes. In case C the contractor had no potential for a manufacturing order, but the other partners and the subcontractors had. The customer paid per hour for the development and took the main risk of the project. This was formalised before the development began. Thus, the main risk as well as the possible profits was shared by the partners in the IOBN-P and by the customers in the lOBN-Ss. However, the manufacturing partners and subcontractors risked being excluded from future manufacturing orders.

5.3 Integrated product development in network enterprises In this section the cases will be analysed trough an IPD perspective according to the theoretical framework. Even though the participants in the IOBN-P knew each other the least in the beginning of the project, the PD in this network was more integrated than in the other two lOBNs. The involved persons worked as a team and thereby the companies become integrated in the actual project. This was particularly obvious in the work just before formal deadlines to the customer and when problems had occurred. The team was very committed to its task and the focus on bringing home the order brought the team very close together. Most of the work was

406

ICED 01 -C586/145

performed at one of the workshops where project information was shared among the participants. Possibly the integration between organisational functions could have been better, the focus was very much set on the manufacturing process. In the lOBN-Ss the integration between individual, functions and organisations were poor. The integration was most apparent between the contacts of the customer and the contractor and within parts of the companies. The small organisations in the lOBNs lead to that the involved person within each company worked close to each other and the integration between hierarchical levels was not a big issue. The issue of knowledge -capture, -transfer and -property has not been mentioned as a problem in the lOBNs. At the frequent physical meetings in the IOBN-P there was great openness and the results were documented. After the order was settled the partners established a common enterprise and the knowledge was transferred to that. In the lOBN-Ss the information and knowledge handling were somewhat restricted to what each partner and subcontractor needed. In all the cases there was a frequent communication through telephone and after some time also e-mail. The IT maturity increased gradually in the projects. The PD in the cases was to some extent performed in parallel. However, only the PD in Case C was following a structured process. The contractor in that IOBN had a settled process and this was followed throughout the project. In Case A and B PD was a new experience for the companies. Customer B had an internal PD-process, but the contact at that company appreciated the less bureaucratic PD performed in the IOBN, even though the lack of experience was a risk. In the IOBN-P the goal was to produce ten prototypes that fulfilled the requirement specification. This was focused throughout the complete PD process after the customer issued a purchasing order for manufacturing. Other aspects like e.g. the price-fixing were largely secondary. In the lOBN-Ss the PD were performed more gradually with different prototypes as goal. In all the three cases the project leader and to some degree the team settled a list of activities with a time schedule. According to the interviews the development time, the cost and the quality have not been mentioned as problems in the lOBN-Ss. However, in the IOBN-P, technical problems delayed the project several times. According to the interviewees it is doubtful if the PD in the IOBN-P would have succeeded if the key persons were experienced in PD. The project would probably be judged as a dead end due to the technical problems and the success it resulted in was judged as a consequence of a very great interest. On the other hand, some of the interviewees requested a more structured PD.

6

Conclusion

The IOBN-P studied is certainly a product of an entrepreneur choosing complementary partners for a specific business venture. In one of the IOBN-S, the contractor had previous contacts with the customer, but chose complementary partners for this specific business venture in the regional network. There exist different opinions regarding whether those specific lOBNs are results of the regional network or not. To know for certain, probably another research method following the emergence of the lOBNs would be needed. The other IOBN-S studied act as a united front toward the market and it is clear that such an approach might cause new business opportunities, in this specific case in a new area of business. Six factors judged as vital for successful collaboration in lOBNs have been observed in the three cases. They are somewhat supplementary to the theoretical framework. To decide on the importance of those factors more research has to be performed. However, the results indicate

ICED 01 - C586/145

407

that the importance is varying depending on IOBN. The main risk as well as the possible profits is shared by the partners in the IOBN-P and by the customers in the lOBN-Ss. Further, the complexity in an IOBN-P with original design is greater than e.g. in an IOBN-S with incremental design. Thereby the factors observed ought to be more important. The PD in the IOBN-P was more integrated than in the lOBN-Ss. There are several possible reasons for this. The PD concerned an original design, the team was very committed to its task and the team had a possibility to bringing home a large order. In addition the partners own the future product jointly. The fact that the tendency to integrate the individuals in a team increased just before formal deadlines and when problems had occurred indicates that this is a natural way of working at critical situations. The integration in the lOBN-Ss was narrow and most apparent between the contacts of the customer and the contractor and within the companies. This could be a result of a strong contractor, the fact that the network is developing a subsystem, but also on the type of subsystem developed. Finally, our results confirm that the project scope influences the design process. A conclusion is that the difference of design practices between companies [5] is true even between different lOBNs. The need for maturity in PD seems to be dependent on if the IOBN is developing an own product or a subsystem as a consultant, but also on the complexity in the project. The degree of structure in the PD also seems to be dependent on previous experience of PD. References [1]

Norell, M., "Managing Integrated Product Development", Critical Enthusiasm Contributions to Design Science. Department of Product Design Engineering, Norwegian University of Technology and Natural Science, Trondheim, 1999, pp 129136

[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 and Beyond. Discover Imaginary Systems" Chichester, England, 1997.

[4]

McCormack, U. and Oliver, N., "Networked New Product Development in the Biomedical 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 Product Development Methodology with Concurrent Engineering for Small Manufacturing Companies", Journal of Engineering Design. Vol. 8, No. 4, 1997, pp 305-328

[6]

Hietikko, E. and Parkkinen, H., "Principles and Tools of Concurrent Engineering in Network of Small and Medium Sized Companies", Proc. ICED '99. Munich, 1999, pp 329-332

[7]

Andreasen, M. and Hein, L., "Integrated Product Development". London, U.K. 1987

[8]

Vajna, S., Burchardt, C. and Richter, A., "Organizing Integrated Product Development with network Structures" Proc. ICED '99. Munich, 1999, pp 393-396

Jorgen Pilemalm Royal Institute of Technology, Department of Machine Design, SE-100 44 Stockholm, Sweden, Phone: +46 8 790 68 61, Fax: +46 8 20 22 87, E-mail: [email protected] © IMechE 2001

408

ICED 01 - C586/145

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

ORGANIZATIONAL DESIGN - A TOOL FOR EVALUATING ALTERNATIVE EXTENDED ENTERPRISE STRUCTURES A McKay and A de Pennington Keywords: extended enterprise design, supply chain design, interfacing suppliers and manufacturers

to customers,

Abstract 3D Concurrent Engineering (3DCE) draws upon parallels between product and supply chain architectures to provide insights into supply chain performance and design. In essence, 3DCE argues for the parallel development of product, process and supply chain. Three dimensions from which supply chains can be viewed (organisation, technology and business capability) and four kinds of proximity (organisational, cultural, electronic and geographic) that are features of supply chains are provided; in integral (as opposed to modular) supply chains the proximities are close. More broadly, these proximities can be seen as indicators to the likely success of proposed supply chain configurations. For example, data exchange between organisations is more likely to be successful when the organisations have similar hardware and software platforms: a high electronic proximity. This paper reports on research that resulted in the establishment of a software tool that drew upon learning from product design and data representation and applied it to the representation and analysis of alternative supply chain structures. The purpose of this paper is to illustrate how learning from the representation of products, and specifically product structures, can be applied to the representation and design of enterprise architectures. A data model for the representation of extended enterprise structures is presented; supply chains can be seen as paths through extended enterprise networks. This data model has been successfully implemented in a relational database. Its use to support a prototypical software tool that allows alternative extended enterprise structures to be visualised is discussed.

1

Introduction

Research on the operation of retail packaging supply chains has indicated that there are drawbacks in having information flows mirror the product flows in a given supply chain [1]. Benefits can be gained, especially in terms of improved quality and reduced costs and lead times, by considering and implementing chains for the flow of information that are not necessarily the same as the [product] supply chain. For example, Fisher [2] argues that, before devising a supply chain, one should consider factors such as the demand for the product and the kind of product that is being produced. These can be seen as requirements in a supply chain design process. Krishnan and Ulrich identify four kinds of product development decisions that are alluded to in the literature: namely, concept development, supply chain design, product design and production ramp-up and launch [3]. Like any design decisions, support for decision-making processes related to the configuration of supply chains

ICED01-C586/431

409

require both representations of alternative supply chain structures and tools that allow the alternatives to be evaluated. The research reported in this paper asked the question, "Can techniques used to support product design decision-making processes be transferred to the domain of supply chain design?" Research with industry sectors that produce large systems (for example, aircraft and marine vessels) has concluded that there is a need for people to be able to consider a number of extended enterprise structures in parallel and then make trade-offs between them. Further, these extended enterprise structures cover the entire product life-cycle, from concept to inservice support, rather than the supply chain alone. For example, at the early stages of product development, a prime contractor on a long-term project might wish to explore the risk of key suppliers becoming insolvent through a cash flow enterprise structure. Here, decision-making processes related to the configuration of extended enterprise structures, one of which might be a supply chain structure, are needed; both representations of alternative extended enterprise structures and tools that allow the alternatives to be evaluated are required to support such processes. This paper describes such a tool and its associated extended enterprise representation scheme. The tool allows people to visualise alternative extended enterprise structures. Its use in support of an analysis of the electronic proximities within alternative supply chain structures is described. A case study is used to is used to illustrate the capability of the representation scheme.

2

Case study

The case study that is used in this paper is a synthetic supply chain based on the fast moving consumer goods sector. It has been synthesised from a number of specific examples from retail packaging chains. A key player in the chain is a sandwich maker that has been required to work, by a supermarket that it supplies, with a given package manufacturer and a given label manufacturer. The supermarket demands that these suppliers will supply the packaging for a new style of pre-packed sandwich. The sandwich maker is a packer/filler during the operation of the supply chain. It also has overall responsibility for designing the packaged sandwiches which includes both labels and a container for the sandwiches. The supply chain is illustrated in the schematic given in Figure 1.

Figure 1: The example supply chain (in operation)

410

Figure 2: Design chain scenario 2

ICED01-C586/431

It can be seen that the product supply chain is defined by the supermarket. However, although it frequently is the case, it does not follow that the organisations must work in a similar chain during the design phase except passing product requirements down the chain (from customer to supplier) and product [design] definitions up the chain (from supplier to customer). In fact, experience dictates that teams of partners are more effective in carrying out design processes than chains of suppliers. Hence, discussions within product development projects lead to questions such as, "What are the best extended enterprise structures for the product development and production processes?" An alternative design chain structure is given in Figure 2. Here the package, label and sandwich makers work together collaboratively on the design of the packs of sandwiches. The dashed circle denotes a "virtual" organisation that works on the design [7]. Later in this paper, these two scenarios are modelled and their electronic proximity evaluated.

Background Supply chain modelling and research has directed much effort towards improving the performance and operation of supply chains [8]. Supply chain design, on the other hand, has received far less attention [3]. In supply chains the key players are customers and suppliers with information, artefacts and money flowing between them. The research reported in this paper builds upon an alternative view. It considers the notion of an extended enterprise where the key players are stakeholders. A benefit of taking this view is that players who are typically considered to be outside the supply chain, for example, designers according to SCOR (The Supply Chain Council's Supply Chain Operation Reference model'), can be considered as a being a part of a system that is the extended enterprise. Fine [9] argues that supply chains should be designed concurrently with the product and the process: namely, 3D concurrent engineering (3DCE). A logical conclusion from Fine's work is that people carrying out 3DCE will need such tools when they are synthesising and analysing supply chains in addition to product and process design tools [10]. Tools for visualising supply chains are an early step on a path towards tools to allow people to design products in parallel with the organisations [supply chains] that will make, deliver and use them, and then evaluate their potential effectiveness.

2.1 Extended enterprises An extended enterprise is a collection of organisations related to each other through a network of relationships. Some relationships create pathways along which things flow. For example, a supply chain includes paths through which goods and services flow; supply chain processes are what make the goods and services flow between the organisations in the supply chain. During the operation of a supply chain, supply chain processes make the flows (material and information) flow. The Supply Chain Council's Supply Chain Operation Reference model (SCOR) describes four key processes for each organisation that are needed to ensure effective supply chain operation: source, make, deliver and plan. Supply chains are not the only kind of path that exist. Extended enterprise processes in general make flows flow around extended enterprise networks. An important factor in determining what flows and the most appropriate pathway depends upon the stage of the product life-cycle. Different kinds of relationship exist and organisations can be seen to play different roles, for example, organisational [product] provider, technology provider, business capability provider. Brandenburger [11] identifies co-operation (e.g., along a supply chain) and competition as 1

Supply Chain Council - http://www.scc.org

ICED 01 - C586/431

411

two types of relationship that occur in an extended enterprise. Other relationship types include complementation (doing things that improve the product of another organisation's product for its customer) and collaboration (for example, partnership).

2.2 Designing supply chains According to Suh [12] any design process includes three processes: synthesis, analysis and decision making. For example, an extended enterprise designer might create [i.e. synthesise] three alternative extended enterprise scenarios. Each scenario could then be analysed and, finally, a decision made as to which was the best, for example, the most fit for purpose or the least risky. Alternatively the extended enterprise designer could decide to create more extended enterprise scenarios. The research reported in this paper used the data model (see later) to capture the alternative extended enterprise scenarios and underpin an electronic proximity tool with which to analyse the scenarios. Presently, clearly defined and rigorous mechanisms for selecting the "best" design are unclear. However, it does appear that what constitutes a desirable supply chain structure depends upon the nature of the flows and the product life-cycle process that is to be carried out. For example, if flow is a commodity and widely available then the closeness of a customer and its supplier might be less of a priority than for a flow that is critical to the success of the customer's own product or process. An earlier example highlighted the importance of life-cycle stage.

3

Electronic proximity data model

When considered as a structure, a supply chain can be modelled as a collection of related elements and relationships. Lee [13], for example, models a two-level supply chain in terms of the companies on each level and the relationships, in his case an information flow of demand data, between them. In product structures, composition relationships are typically used in administrative tasks (such as planning and purchasing) whereas connection relationships are typically used in technical tasks (such as design, planning to manufacture, manufacture and maintenance) [14]. As in product design, in supply chain design the interfaces between organisations are of primary importance.

3.1 A note on the EXPRESS-G notation This summary is intended to provide sufficient information for readers to understand the EXPRESS-G diagrams in this paper. In the EXPRESS language [15], entities are used to describe the concepts that are being modelled and the attributes of entities are used to describe relationships between these concepts. EXPRESS-G boxes represent entities and fine lines between boxes represent attributes. The plain end of the fine line is placed at the box representing the entity to which the attribute belongs and the circled end is placed at the box representing the [data] type of the attribute. Boxes are labelled with the name of the entity and fine lines are labelled with the name of the attribute. Thick lines between entities are used to show EXPRESS sub/supertype (specialisation/generalisation) structures. The "(1)'" label means that the sub-supertype relationship is of the ONEOF type.

412

ICED01-C586/431

3.2 Data model definition The data model that was used to represent supply chain structures and support the electronic proximity analysis is defined in Figure 3 using the EXPRESS-G notation. The identification of each organisation in the chain is represented as an instance of the organisation entity. The organisation_deflnition entity allows a given organisation to participate in multiple chains whilst the characterised_organisation_definition entity allows each participation to be characterised in a number of ways. For example, the electronic proximity for exchanging product requirements may be different to that for exchanging product definitions (such as shape models) because different computing environments might be used in each case.

Figure 3: Data model to support electronic proximity analysis

It can be deduced that a "full" instance of the data model would need to explicitly characterise each communication channel in the extended enterprise or supply chain. The organisation_E_charas entity captures the data about an organisation in a communication channel that are needed for the electronic proximity analysis to be carried out. The characterised_organisation_definition_relationship entity allows each relationship, in this case communication channel, to be characterised. In practice we found a need for only one characterisation of each communication channel but in principle there appears to be no reason to prohibit multiple characterisations. Similarly to the organisation_E_charas entity, the re!ationship_E_charas entity captures the data about a communication channel between organisations that is needed for the electronic proximity analysis to be carried out.

3.3 Data model population Example instances of the data model, populated with selected parts of the case study data, are given in Figures 4 and 5 using the EXPRESS-1-G notation [17]. Figure 4 shows the relationships between the sandwich maker and the package maker in Scenario 1. It can be seen that each flow, that is one of product requirements and one of product definitions, are represented separately. This is to allow for the fact that different computing environments are likely to be used in the different contexts. The relationships between the sandwich maker, the label maker and the package maker in Scenario 2 are given in Figure 4. There are fewer relationships because each of the flows concerned in Scenario 2 are bi-directional. In practice more than one relationship might need to be represented. However, the purpose of

ICED01-C586/431

413

the electronic proximity is to inform extended enterprise decision makers about the electronic proximity of alternative configurations and not necessarily to reduce the number of relationships that are present. A key point to note in Figures 4 and 5 is that the real difference is in terms of the relationships between organisations and not the organisations themselves. In the design of a supply (or design) chain trade-offs between the different proximities would need to be made.

Figure 4: Partial representation of Scenario 1

4

Electronic proximity software tool

The purpose of this research was to examine whether insights can be gained by applying product data engineering techniques to the representation of extended enterprise structures. If appropriate, tools to support supply chain designer in their decision making processes [3] become a real possibility. Emphasis was placed more on the underlying representation scheme than on the calculation of electronic proximities. The software that was implemented calculated electronic proximity by considering each defined relationship in turn. For each relationship the characteristics of the related organisations [context of use, software, operating system and hardware] were compared and given a value of 1 if they were the same as each other and 6 if they were not the same as each other. Thus, for example, a pair of companies using the same software in the same context but on different operating systems and hardware platforms are less electronically close than a pair of companies using the same software in the same context and with the same operating systems and hardware platform. Similar values were assigned to characteristics of the relationship itself. The data model was implemented in a relational database [Microsoft's Access] and the electronic proximity software was implemented using SQL queries.

414

ICED01-C586/431

Figure 5: Partial representation of Scenario 2

5

Conclusions

There is a real need for tools that will support extended enterprise and supply chain design decision-making processes. Research issues include identifying the key attributes of extended enterprises and, initially at least, supporting the quick visualisation of alternative structures. Extended enterprises are socio-technical systems and many of the issues to be resolved relate to human issues, for example trust [18], and to the dynamics of their operation; the latter leads to a need to link work on extended enterprise design with simulation tools. It is not clear that extended enterprise structures can be optimised for all participants. However, given the appropriate tools, it is possible to build robust extended enterprise structures that are fit for purpose. There is an intrinsic interdependency between an extended enterprise and the products and processes of the participating organisations. As such, an extended enterprise system will only perform as desired if it reflects the policies and processes used by the various stakeholders within the system. The research reported here has started to provide an integrated modelling and analysis tool for extended enterprise supply chains. New methodologies are required to handle uncertainties inherent in, for example, supplier reliability and changes of requirements imposed by customers.

Acknowledgements This research was carried out as part of the UK EPSRC/SII project no. GR/M56715 (MAPPSEE). The academic partners are University of Leeds and De Montfort University and the industrial partners are BAE Systems and Rolls-Royce plc. References [1]

Christensen, C.M., The Innovator's dilemma: When New Technologies Cause Great Firms to Fail. 1997: Harvard Business School Press.

ICED01-C586/431

415

[2]

Fisher, ML., What is the right supply chain for your product? Harvard Business Review, 1997: p. 105-116.

[3]

Krishnan, V. and K.T. Ulrich, Product development decisions: a review of the literature. 1998, Department of Operations and Information Management, The Wharton School, Philadelphia, USA. p. 1-33.

[4]

Checkland, P.B., Achieving Desirable and Feasible Change: an Application of Soft Systems Methodology. Journal of Operational Research Society, 1985. 36(9): p. 821831.

[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 product structure laws, in 3rd WDK Workshop on Product Structuring. 1997. Delft University of Technology, Delft, The Netherlands.

[7]

Venkatraman, N. and J. Henderson, Real strategies for virtual organizing. Sloan Management Review, 1998: p. 33-48.

[8]

Towill, D.R., Supply chain dynamics - the change engineering challenge of the mid 1990s. Proceedings of the Institution of Mechanical Engineers, 1992. 206: p. 233-245.

[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 of organizational processes. Management Science, 1999. 45(3): p. 425-443. [11] Brandenburger, A.M., B.J. Nalebuff, and A. Brandenberger, Co-opetition. 1997: Doubleday. [12] Sun, N.P., The principles of design. 1990: Oxford University Press. [13] Lee, H.L.S., C So; Tang, Christopher S;, The Value of Information Sharing in a TwoLevel Supply Chain. Management Science, 2000. 46(5): p. 626-643. [14] McKay, A. A framework for the characterization of product structures, in 3rd WDK Workshop on Product Structuring. 1997. [15] ISO10303-11, EXPRESS Language Reference Manual. Industrial Automation Systems and Integration - Product Data Representations and Exchange. Vol. ISO 10303-11. 1994: ISO. [16] ISO10303-1, Overview and fundamental principles. Industrial Automation Systems and Integration - Product Data Representations and Exchange. Vol. ISO 10303-1. 1994: ISO. [17] McKay, A., et al. EXPRESS-I-G: A graphical notation for EXPRESS-I. in EXPRESS User's Group (EUG'93) Conference. 1993. [18] Clegg, C.W., M.O. Gray, and P.E. Waterson, The "Charge of the Byte Brigade" and a socio-technical response. International Journal of Human-Computer Studies, 2000. 52: p. 235-251.

Dr Alison McKay, School of Mechanical Engineering, University of Leeds, Leeds, UK, LS2 9JT, telephone: 01132332217, fax: 0113 233 2150, [email protected] © IMechE 2001

416

ICED 01 - C586/431

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

CULTURAL ISSUES IN AEROSPACE ENGINEERING DESIGN TEAMS K H Payne and P J Deasley

Keywords: Concurrent Engineering, Culture, Design Teams, Human Resources

1 Introduction Recent years have seen the Aerospace industry move to product development approaches that are more concurrent. One approach is the Integrated Product Development (IPD) Process. A principle of IPD is to organise around multi-functional Engineering Design Teams or Integrated Product Teams (IPTs). IPT members are not only multifunctional but also likely to work for different companies, have different nationalities and languages and stem from different sites of one company or even be scattered across the globe. This paper presents research carried out to understand the cultural issues faced by these IPTs in the aerospace industry, and why culture differences are important. Existing approaches to cultural assessment are reviewed, as well as their limitations. A description of a new assessment technique is presented. Based on findings from this technique the paper discusses some cultural issues faced by IPTs. It concludes with suggestions for future work and thoughts about how this information can be used for other means such as training, partner selection and to support distributed IPTs that are increasingly being used.

2 Background IPTs are composed of representatives from all appropriate functional disciplines, major subcontractors, and customer representatives, working with a team leader to identify and resolve issues and to make sound and timely decisions throughout the design and manufacture of a product. Once on a team, the role of an IPT member changes from that of a representative of a particular function focusing on a given discipline, to that of a team member who focuses on a product and associated processes. Getting people together from several functions is intended to promote a complete understanding of requirements resulting in superior products, which satisfy the customer needs appropriately. In the very basic circumstances IPTs ensure that engineering and manufacturing agree with the product design. In addition, IPTs encourage the integration of customer representatives and the main suppliers to work alongside the prime contractor in the initial development phases. This is primarily to understand the needs of the customer to a greater extent, and to ensure that the customers and the key suppliers are happy with a design at the outset of the development process. In an increasingly global industry, IPTs can include individuals from different countries. Initial investigations were carried out to understand the key issues faced by IPTs. The investigations used techniques such as workshops, surveys and semi-structured interviews, involving IPT members from more than 30 different aerospace organisations. The information collected from this work formed several conclusions. The first was that one of the biggest

ICED01-C586/035

417

problems for IPTs is the 'culture' differences existing between team members. Secondly, culture differences occur at different levels within a team, for example, national, organisational, functional, site and project cultures. Finally, individuals found it difficult to define what they meant by 'culture', and identify which elements caused the greatest problems. A large amount of literature in this area focused on cultures of different nations, for example [1] and [2]; or organisational culture, for example [3] and [4]. The limitations of this are that many existing models fail to consider regional cultures of nations, or organisations. In addition, the structure of IPTs can mean that the culture composition is more complex than previous models can accommodate.

2.1 Subcultures Culture does not only occur at national or organisational levels. It is incorrect to assume that any nation or organisation is solely influenced by a single culture. In reality there can be any number of subcultures, and it is inappropriate to assume one culture per organisation [5]. By making such an assumption, it should not matter who describes the culture, or at what hierarchical level or geographic region or product division the individual is from, the resulting conclusion should be the same. This is unlikely to be the case. The assumption of a single culture fails to recognise that each hierarchical level; geographic region or product division may be the potential site of a distinct culture itself. This phenomenon is even more likely to apply to IPTs, in which case it would be incorrect to assume one culture per team. The structuring of organisations into work roles affects patterns of interactions between individuals. Each role brings with it specific tasks and a particular status relative to other roles [5]. The degree of interaction between members and between roles differs so that some individuals will interact with others more frequently if they share the same problems, or are working on the same product or project. From these interactions, subcultures will develop. The division of organisations into functions and specialist areas has promoted a greater creation of subcultures. The specialisation of functions narrows the number of employees who are able to do a particular type of work [5]. As each specialisation develops it's own language, norms, perspectives and objectives, sub-cultural abundance should be expected.

2.2 Barriers caused by culture differences The presence of different cultures can create barriers, leading to reductions in team effectiveness1 due to poor communication [6]. Effective communication between members of an IPT is vital as it allows focus on what is important. Ineffective communication discourages the free exchange of ideas, up and down the product development cycle. With ineffective communication comes the danger that deficiencies discovered in the downstream activities in a product lifecycle may not be correctly communicated to upstream activities [6]. A second barrier is parochialism [7], viewing the world solely through one's own eyes, leading to the belief, "my way is the only way to do things". A person with a parochial perspective neither recognises other people's different ways of working nor appreciates that such differences have serious consequences. Parochialism can be observed when things go wrong and individuals point the finger to somebody else with the refrain of, "If only they had made it the way I had designed it." [8]. A third barrier, ethnocentricity or judging another by one's own standards makes individuals unable to understand another culture. It leads to false 1 Whilst this paper discusses the effect of culture differences on team effectiveness, this is based on perceptions of effectiveness rather than specific measures.

418

ICED01-C586/035

distortions of what is meaningful to others through one's own eyes, causing a failure to understand that another's ways have their own meanings and functions in life and these may be different to one's own. Related to parochialism is arrogance, which reflects one's closure to outside opinion [9]. Arrogance is a similar expression of an unwillingness to value and incorporate the contributions of other cultures. Ignoring these barriers has the potential to reduce team effectiveness; it creates conflict between members and causes misunderstandings, which can lead to engineering changes occurring later in the product development process. It also prevents opportunities for recognising cultural diversity within team members. All too often, cultural diversity is seen as an area of difficulty rather than as an opportunity to build a competitive advantage for the team [7].

3 Culture Assessment Whilst it is evident that differences are present between different cultural groups, and these differences can be detrimental to IPTs, it is less obvious how to assess the differences and their impact. There are different ways that culture assessment has been carried out. There are many different cultural assessment techniques available. The first type of culture techniques is quantitative in nature. They typically require respondents to rank, or rate their respective culture along a particular dimension, for example, "On a 1 to 10 scale, rank the extent of information transfer within your organisation" [10]. This may involve completing the assessment twice - the first response based on the culture of the respondent's organisation, and the second response based on the culture of another organisation. The technique can also be used to assess differences between actual and desired cultures. Other quantitative techniques require respondents to allocate points between statements, awarding the highest points to the statement that best reflects their culture [11]. There are drawbacks to quantitative approaches. They are simple to administer and analyse, but do not allow for variations in the interpretations of the statements, or rating scales. For example, two individuals rating very strong agreement with a statement may be rating it for different reasons. Quantitative approaches do not capture these reasons. Finally, quantitative assessment techniques assume that the assessor (and the scale developer) fully understand that the exact item being assessed is known and can be evaluated (or quantified) using a single number. This is unlikely to be the case due to the complexity of the phenomenon of culture. The second type of techniques is qualitative in nature. Qualitative data contain rich information that is often deep in content and context. Whilst qualitative information is harder to analyse, it is useful in assessing culture where contextual information is important for understanding meaning. It provides a basis for further exploration and identifies areas of the culture that quantitative assessment would not. An example of a qualitative assessment technique is the Cultural Web [4]. This requires respondents to answer questions relating to six different aspects of culture including 'Symbols', 'Structure' and 'Control Systems', and a 'Cultural Paradigm' representing the core of an organisation's culture.

3.1 Limitations of traditional approaches One of the limitations of the existing cultural assessment techniques is that many of them have been developed for generic use across different industries. This has a practical benefit as the same technique can be used across many industries, but may be less reliable than a technique developed in, and used in a single industry. The cultural factors that are important for one industry, i.e. aerospace, may be different from those that are important for another, i.e., automotive. The industry itself may be considered as another culture level, i.e.

ICED01-C586/035

419

"aerospace" culture. Different industries operate by different means: they have different relationships with customers and suppliers, different motivations and goals, and different production characteristics. For example, the aerospace industry is a low-volume manufacturer of products with typical lead times of 10-15 years, with new products developed every 10-20 years. The customer plays a strong role in product development and selects the manufacturers of the main sub-systems. In contrast, the automotive industry is a high-volume manufacturer of products that have lead times of (typically) 24-36 months, occurring relatively frequently with new products being developed every 1-2 years. The products are relatively standardised, although the customer is increasingly able to make choices about some of the features of the product, but with relatively little impact on the choice of the suppliers. Probably the most serious limitation of many of the techniques has been pointed out by Edgar Schein [12] who questioned whether the phenomenon was understood adequately. He claimed that the label of "culture1 had been hung on everything from behavioural patterns to new corporate values that senior management wished to incorporate into an organisation. How is it possible to measure something that isn't understood properly? If this is the case, then one of the first objectives in the development of any cultural assessment technique is to understand the concept of culture fully, and in the context of the industry.

4 Developing a new framework The initial investigations produced many factors perceived to contribute to culture differences and the creation of barriers to effective team performance, including language, motivation, values, politics, and structure. Following an extensive literature review and the identification of 55 cultural factors creating barriers to working together, an industrial survey was carried out to determine which of these 55 factors had the greatest impact on individuals working together. A factor analysis was carried out on the data and based on the results, a five-factor framework was produced to provide a basis for understanding those components of culture that have the greatest impact on IPTs and team members working together. The total variance explained by the factor analysis model was 60.649%. Table 1 presents the percentage of variance explained by each of the resulting five factors. The five factors of the framework consisted of 19 variables from the original 55 variables, about Communication; Leadership; Practices undertaken; the Structure; and characteristics of the working Environment. Table 2 presents the distribution of the variables in the five factors. Table 1. Variance explained in factor analysis model

Factor

1 2 3 4 5

% of variance 19.637 15.449 9.639 8.135 7.789

Cumulative % 19.637 35.086 44.726 52.861 60.649 (total)

The factors and associated variables were assembled into a workbook. This provided details of each variable and it's relative impact on the culture of the environment, including 49 open questions relating to the variables. For example, "What is the 'working language of your culture?"; "What traditions are present within your culture?".

420

ICED 01 - C586/035

Table 2.

Factor Practices Structure Communication Leadership Environment

Variables within each factor

Variables within the factor Knowledge sharing; Expertise; Decision making; Trust; Roles & contributions; Motivation; Work ownership Reporting hierarchies; Values held; Structure; Management control; Flexibility Language; Approach to communication Support for initiative; Leadership style Stability; Politics; Goals & objectives

5 Case Studies The workbook was partially validated using three case study applications in order to assess it's effectiveness and usefulness in the industry. A vast amount of qualitative data were produced. Some of the findings are presented below.

5.1 Case study one - Organisational culture Case study one involved the assessment of culture differences between two recently merged organisations from the military aerospace sector. The merger had created a project set-up where individuals from both organisations were expected to work together. Seven individuals took part, four from organisation A and three from organisation B. One issue was that prior to the merger, organisation B had been a major supplier to A. Individuals from A felt that individuals from B were "muscling into their territory", creating an environment of mistrust. A perceived B as uncooperative and stubborn. B perceived that A was suffering from jealousy due to changes in the way that projects were distributed following the merger. In addition, the prime customers of both A and B (pre-merger) had very different influences on the respective organisations. The customer's culture can heavily influence the culture of a supplier. To a large extent, the main customer of A tends to be defence ministries, both in the UK and abroad. The organisation is driven by (possibly dictated by) the need to develop products to suitable design and cost for government(s) in order to retain their custom. Defence ministries had less direct influence over organisation B. The leadership style of A is perceived as close to manager-centred with a desire to be teamcentred, and possibly attempting to shift to a more democratic direction. The leadership style at B is perceived as being autocratic and manager-centred to a greater extent. Within A, there appears to be a greater focus on responsibility to the functions, whereas in B, responsibility appears to be towards projects. The values held by individuals at B are strongly financial in orientation, i.e. Finance has the last word, and is seen as highest in order of importance. In contrast, individuals at A tend to value 'people' aspects of the work. The main reason for this culture was thought to be the legacy from a Managing Director of B who was known for maintaining tight financial control and a 'process mentality' throughout the organisation.

5.2 Case study two - National culture The second case study involved an IPT working on a civil aerospace project, with a military application. The project comprised individuals from several different nationalities, but working for the same organisation. The team had been experiencing cultural difficulties

ICED01-C586/035

421

between several of the different nationalities and was interested in understanding why this was happening. Three individuals took part, two British males and an Italian female. The findings indicated displays of nationalism from both the British and Italian respondents, which were negative in connotation. There was evidence of 'Europa-phobia' between individuals of different nationalities, even in the same organisation and at the same site. The Italian respondent felt that foreign team members had the potential for introducing new ideas, yet these were perceived to be rejected because of the potential for misunderstanding by British members. The values of the British and Italian respondents differed. The values of the British respondents tended to relate to the organisation, yet for the Italian respondent the values were towards hard work and perseverance. The Italian respondent described how British people value time, and how they will leave work when it is time, rather than staying to complete work. This reflects the British' sequential culture concerning time orientation, identified by Trompenaars and Hampden-Turner [2]. There were issues concerning language differences even though both groups used English as the working language. For example, the British respondents described problems of explaining instructions slowly and repeatedly.

5.3 Case study three - Site culture The third case study looked at cultures from different sites within the same organisation working on a military aerospace project. The IPT comprised eight individuals at three different military aerospace sites. Four individuals were from site X, three were from site Y and one from site Z. The team had recently been created for a short-term aerospace project involving the improvement of specifications of an existing aircraft. Findings highlighted that different sites of the same organisation have different cultures. For example, there were differences in leadership and decision-making styles. Individuals at site X were encouraged to be involved with other projects and information was shared openly, yet at site Y, individuals felt that there was very little information sharing between projects, and "people held their cards very close to their chest". One cause of the culture at site Z is the recent threat of closure. This has meant that individuals have operated in a flexible manner to accommodate changes, there is little formal organisational structure, and the company has carried out work outside of the aerospace industry in order to survive. The differences in cultures may be due to several reasons. The first may be company heritage of the respective sites. Each site was owned by different organisations over the past 100 years. Whilst significant changes occur with the introduction of each organisation, several individuals commented that "culture is in the walls", implying even if you change the practices and processes of the people, the basic culture remains. All three sites are located in the north of England, but site culture differences may be partly due the location of the site. There was evidence of culture stereotypes based on geographical location. For example, "they have whippets and flat caps" (a characteristic Northern stereotype), even though the sites are only about 75 miles apart from each other - a relatively short distance in a global industry!

6 Cultural Issues for Aerospace Teams The case studies raised several issues for IPTs in the Aerospace industry. The first is concerned with culture change. Whilst the desirable solution may be to change the cultures of team members to match other's culture, this is problematic in the context. IPTs are formed on a temporary basis and team members move to new teams on completion of the project. In which case, culture change may be required again for this new team. One suggestion to

422

ICED01-C586/03

overcome this is the use of techniques allowing cultural alignment (as opposed to change) and appreciation, to be carried out. This would allow team members with different cultures to work together without the need for change, yet understand reasons for differences. The second issue is that IPTs have a complex structure consisting of many different types of culture. The inherent nature of an IPT means that at the very least, an IPT will comprise team members from different functions, and major subcontractors. Increasing use of globalisation and consortiums has meant that IPTs frequently comprise team members from different nationalities, different organisations, and different sites (especially for large organisations occupying different locations in one country). With each division comes another subculture, and each team member may be a member of several different subcultures at any one time. The third issue to consider is that the role of leader of an IPT may be more than simply ensuring that a product or project is delivered to specification. The team leader may become a 'controller' of the team culture. For instance, the team leader might have the authority to control how resources are allocated, how individuals behave, how decisions are made and so on. In addition, there is also an issue as to whether cultural behaviours should be encouraged in an environment in which they are not widespread. For example, a typical European greeting of kissing a person on a cheek may not be welcomed in a British engineering office. But does the British team leader have a right to preclude two European partners on his team from greeting each other, or other British team members in this manner? Stereotypes may play a significant part in how outsiders view the culture of others. Mullins [13] describes stereotyping as the tendency to ascribe positive or negative characteristics to a person on the basis of a general categorisation. It occurs when an individual is judged on the basis of the group, to which they belong, for example, individuals belonging to a group are all seen as having the same characteristics. Mullins provides examples of stereotyping, "All Germans are orderly and industrious" (Nationality); "All accountants are boring" (Profession). The danger is that stereotyping is a limited view of the average behaviour in a certain environment, and exaggerates and caricatures the culture of another. It also ignores the fact that individuals in the same culture do not necessarily behave according to the cultural norm, or the stereotype [2]. The impact of customers and suppliers can affect the cultures of team members. In some situations, suppliers can develop cultural traits similar to their customer. Being dependant on major customers for business can mean that companies listen to their customer's needs intently. In some cases, customer's needs and wants have become the raison d'etre of the company's philosophy, [14]. Based on the findings from this research there are implications for training programmes for awareness of the complexity of the IPT structure and it's potential effect on problems that can arise between individuals. IPT members need to be aware of these issues, the origin of cultural behaviour and possible detrimental effects on IPT performance. In addition, there are questions to be considered, for example, do individual differences such as personality characteristics and gender have any effect on the extent to which culture differences might cause problems between individuals in IPTs?

7 Conclusions The implications of this research to engineering teams include: better team management; more effective team performance; improved team communication (possibly leading to fewer engineering changes); and enhanced collaboration within IPTs. This research was carried out within a project developing tools and techniques for distributed IPTs. Distributed IPT

ICED 01 - C586/035

423

members work apart for long periods, with relatively little collocation. Whilst desirable, it is resource consuming to spend time understanding the culture of colleagues to appreciate why they might work differently. Tools, such as the one described, allow distributed members to appreciate culture differences and their origin. The value of qualitative information extends beyond cultural assessments. The data help to build scenarios to accelerate the introduction of new team members into an IPT. This technique may also provide due diligence potential prior to selecting team members, or to allow customers selecting suppliers, or organisations selecting partners to assess the culture in order to favour those that are most culturally aligned to themselves. It may be more effective to chose teams to work with that are more aligned to one's own culture, to reduce the likelihood of conflict occurring. References [I]

Hofstede, G. Identifying Organizational Subculture: An Empirical Approach. Journal of Management Studies, 35 (1), 1-12, 1998.

[2]

Trompenaars, F. and Hampden-Turner, C. Riding the Waves of Culture, Nicholas Brealey 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 Range Planning, 25(1), 28-36, 1992.

[5]

Frost, P.J.; Moore, L.F.; Louis, M.R.; Lundberg, C.C. and Martin, J. Organizational Culture. Sage Publications, Beverly Hills, CA., 1995.

[6]

Clark, K.B. & Fujimoto, T. Product Development Performance Strategy. Harvard Business School Press, Boston, MA, 1991.

[7]

Adler, N.J. International Dimensions of Organizational Behaviour. South-Western College 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, San Francisco, 1995.

[9]

Fishbein, M. & Azjen, I.Belief, Attitude and Behaviour. Addison Wesley Publsihers Inc., Reading, MA. 1975.

[10] Galpin, T.J. & Herndon, M. The Complete Guide to Mergers and Acquisitions, JosseyBass Inc., San Francisco, CA, 1999. [II] Cameron, K.S. and Quinn, R.E. Diagnozing and Changing Organizational Culture. Addison-Wesley Longman Inc., 1999. [12] Schein, E.H. Organizational Culture. American Psychologist, 45, (2), 109-119, 1990. [13] Mullins, L.J. The Nature of Groups. Management and Organisational Behaviour. Pitman Publishing, Maidstone, Kent, 1996. [14] Harrison, M.I. Diagnosing Organizations. Sage Publications, CA. 1987 Katy Payne School of Industrial & Manufacturing, Cranfield University, Cranfield, Beds MK43 OAL, UK Tel: 01234 754194, Fax: 01234 750852, E-mail: [email protected], Web Address: http://www.cranfield.ac.uk/sims/cim/people/payne.htm ©IMechE2001

424

ICED01-C586/035

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

SUPPORTING THE TEAMWORK BY NEW MEANS OF THE INFORMATION TECHNOLOGY A M Kunz, S Miiller, T Kennel, K Lauche, and K Mbiti

Keywords: collaborative design tools; methodology; information technologies; product development process; design teams; computer supported collaborative work; human creativity;

1

Abstract

With increasing divulgence of the information technology also possibilities to support the teamwork are arising. In many fields of the product development process an IT-based support is available as for example in the design stage (CAD and PDM). However, the early stages in the product development process still go without the support of the information technology. The topic this paper is to show the causes of that and to show possible solutions.

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 the teamwork - the concurrent engineering - urgently necessary. In many enterprise processes modern information technologies are already used, for example in the design process and also in the sales process. In the early stages of a product development process, where in particular new ideas are created, the information technology is hardly used because the current available technology is not suitable to support a teamwork decisively. The early stages of the development process as a basis for a new product are based on creativity and imaginativeness in the individual person as well as in the team. At the present time the teamwork is based on a paper-based working method which is in a multiple way inadequate, however, in particular with larger groups. Also the documentation of a session is difficult since the integration of the results is complicated due to the unwieldy format of the paper presentations.

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 very strongly on the composition of a group. Trained teams with personal experience show higher productivity than spontaneously gathered groups. In this case social competence or different levels in the persons hierarchy has an disturbing influence on the effectiveness of the group. Using the above methods requires self-confidence in order to present ideas, to review ideas of the others or to let own ideas to be assessed.

ICED 01 - C586/040

425

In addition, the use of the methods from the above requires that the contributions must be provided in a hard-copy form which must be clearly and readable. However, in most cases these requirements are not fulfilled. Taking the protocol of a teamsession often becomes very difficult because most of the ideas are created on flipchart papers that are not suitable for a protocol and the flipcharts must be processed afterwards. Additional mistakes arise from that which can noticeable reduce the success of a teamsession. Also very frequently information are needed which are not spontaneously available. This results in delays of the team session.

4

Contributions

In order to examine how a new technology can be used in the early stages of the product development process to avoid the above-mentioned difficulties a room was furnished with the currently available technique and practical investigations about his use were carried out. The objective was to find out whether this additional technique is usable or leads to a technical overkill. In a next stage the room will be redesigned and complemented by software tools in order to optimize the teamwork. The technology based conference environment is supposed to offer the following possibilities: presentation from system or laptop; mixedmedia-presentation (for example video, slides, overhead projector, plans, posters, rough paper drafts); simplified taking of the protocol; common sketching possibilities; smaller groups (for a short period of time a smaller formation of groups is possible); providing of external information from databases or out of the internet; integration of external participants by the use of videoconferencing; integration of conventional media and methods; possibility of mixedmode and all-digital methods. Figure 1 gives an overview of the technology-based conference environment:

Figure 1. Conference environment

The conference room includes in total three projection screens, two of them are used in connection with a touch-sensitive surface, the so-called SmartBoard. The third projection screen can be used for a stereoscopic projection or video. The touch-sensitive boards can be used for sketching. The color and the pen position are registered by the computer and the sketches are projected onto the touch-sensitive surface of

426

ICED 01 - C586/040

the board. Thus, the digitalization of the drawn pictures also fulfills the demand for a simplified recording and archiving because the data can be stored at any time. The touchsensitive boards represent the common sketching-possibility where the common ideas are created and visualized [4]. A video-conferencing equipment allows the transmitting of picture and sound to a remote station as well as an application sharing. This will allow to communicate and to work collaboratively with additional team members. Thus, it is possible to obtain additional information from further persons and to allow a teamwork via a physical network as well as acquiring spontaneously needed information. For the visualization of existing objects an additional camera is installed. The camera's picture can be projected onto the third projection screen. Small objects and prototypes can be shown to the team as well as conventional overhead slides or pictures. The technology based conference room is completed by the possibility to present videos as well as slides. With the linking of previous media it is possible to realize a mixed-media presentation. An additional connection at the conferencing table gives access to the projectors so that presentations can be directly carried out from a private laptop. The technical installation of the moderation room is completed by the possibility to plot large scale sketches from the touch-sensitive boards as well as the possibility for scaled printouts. Several test were made with the completely equipped conference room. The scope of these test is to find out the benefits of the new conference room and the way how the persons can work with this new technology. Furthermore it is supposed to be examined, whether previous working methods can be moved in the new moderation environment.

5

First Results

The series of experiments were carried out as far as possible with realistic problems. An essential criterion for the successful use of the conference room was the result and the duration of the session. The tests were carried out with students, with members of the institute and with industry partners in order to receive a representative sectional view. It was essential to the carried out series of experiments were made on real existing projects and not on artificial settings. Thus there was a real demand for moderation technique, for presentation technique or for the metaplan technique in order to carry out the team sessions (up to 10 persons) with maximum efficiency. For the teamsession traditional means were available as well as the described new technologies. The scope of the carried out experiments was to find out where the new technology could not be used anymore and the traditional means were used instead. The working with the new technologies and the different conferencing techniques needs a certain effort. Thus the usage of the moderation room and its technology requires basic knowledge in the information technology in order to take full advantage of the room within a short time.

6

Influence on the moderation techniques

In the following fields changes of the moderation technique arose that must be considered by the user:

ICED 01 - C586/040

427

6.1 Writing and sketching The writing and sketching on touch-sensitive boards distinguishes considerably from that on paper. The recording of the pen position and color by the computer has a latency time which can lead to a confusion while working the first time with this device. Furthermore it has to be considered that the person causes a shadow onto the pressure-sensitive face when a front projection is used. Unlike the writing and sketching on normal paper the line drawn from the pen is only visible as soon as the person is out of the projection way. The shadow caused by the person can be eliminated when a back projection is used together with the touch-sensitive board. This solution is much more expensive and requires more space for the projection system. Although conventional pens are used for writing and sketching, the time delay, which is inherent to the system, must be considered at the presentation. The delay causes quantization mistakes when the speed of the tip exceeds the maximum value. This will result in an interrupted line although it was drawn continuously. The user must draw consciously slower in order to avoid those mistakes. The tests showed, that the user wasn't disturbed anymore by the effects from the above after a short training stage. After the training phase the writing and sketching on the touch-sensitive boards were possible as fast and simple as on traditional paper. Thus the traditional method and the technology based method are equivalent on this field.

6.2 Gallery method During a discussion the writing and sketching is done on a poster. This poster will be used within the gallery method as an elaborated point when the discussion proceeds. The posters are in the person's field of view so they can refer on them if required. The gallery method allows a parallel visualization of several aspects, which can become important in case of comparative discussions. In a contrast to the above the usage of a touch-sensitive board allows only a serial visualization of the currently processed poster. A cross-reference is only possible by paging backward. However, this backward paging represents a break in the moderation process which should be avoided as far as possible. Through the serial representation of the processed posters on the touch-sensitive boards it is not possible to compare the individual posters. In the practical usage within the moderation room this deficiency can be counteract in two ways. The usage of two projection screens allows to visualize the current poster as well as one of the posters before. Thus it is possible to generate a new poster and to represent the preceding relevant posters simultaneously. By that the previously described break in the moderation process can be eliminated. Furthermore there is the possibility to print a poster on a A0-plotter and to use this printout for the gallery method. However, the practical test of these possibilities showed that the use of two touch-sensitive boards as well as the usage of the A0 plotter can only be done by experienced users. Furthermore it has to be considered that no changes or add-ons should be done on the printed posters because these modifications cannot be digitized for a later on usage. However, during the realization of the sessions it becomes clear that two projection screens for the realization of a fluid moderation are sufficient. The additional plotting of the constructed posters during a session was the exception and was not satisfying due to the high time consumption.

428

ICED 01 - C586/040

6.3 Metaplan technique The metaplan method is used very frequently in workshops in order to create ideas and to find out opinions. This method also can be used for larger amount of session members. Within this method short contributions for a defaulted subject are written onto cards. On a common presentation wall the cards are arranged and combined to an entire unit. This method has the advantage that the participants can create their ideas in a certain anonymity without being disturbed by other influences. At the present time it is not possible to realize a technical supported metaplan method. There is no technique available to label a card, to digitize it and to displace it onto a common work area from the participant's place. If a metaplan technique is needed for a team session it must be done with the use of conventional means. This causes an interrupt in the technology-based teamwork. The results that are elaborated with the metaplan method are not digitized and must be processed afterwards for further use. Beside the time consumption further mistakes and corruption can arise from that. Therefore the metaplan method is not feasible in the above described environment.

6.4 Presentation Presentations normally consist of two parts. This is the performance of a prepared visualization and the need of supplementary comments. The usage of the touch-sensitive boards offers two possibilities: on the one hand existing PowerPoint-slides can be complemented through additional rough drafts and comments, on the other hand complements can be represented also separately on the second touch-sensitive board. The test of this possibility brought out very good results. The test persons were mainly able to add complements on the second visualization equipment while the presentation was running on the first visualization equipment. The usage of both touch-sensitive boards did not cause any irritating media alternation but raised the listeners attention since the line of vision could be changed. The presenter must get used to the functionality of the touch-sensitive boards together with a PowerPoint-presentation. It allows to switch to the next slide by touching the surface. In the beginning mistakes occurred during the explanations of the slides combined with the human gesticulation (pointing).

6.5 Providing the information During a session there is the need to provide additional information. The demand for such information arises spontaneous and is not foreseeable. If this information requirement can not be covered by existing materials, an information gap remains that complicates the further process of the session. With the technique installed in the conference room it is possible to retrieve information via the internet or intranet. The carried out test-sessions indicated that many information were already processed by the participants of a session and were provided on servers. Out of this reason the possibility of an information retrieval over a network is very useful. The network access is used in all utilization phases of the conference room: presentations were called up completely over a network and not carried around physically on computers or a missing information is procured during conversation or discussion. The delay which arose from the procuring of the information is marginal in comparison with a delayed session due to missing information. In total the availability of a network is very useful to support an effective teamwork.

ICED01-C586/040

429

6.6 Moderation The technique installed in the conference room enables the presenter to form the moderation of a session more effectively. This is based mainly on a very good visualization of the subjects of interest. This is of interest when a discussion is based on these objects. If the objects are very small only a few members of the discussion can see them while all others have to wait. This causes an unnecessary delay of the discussion until everyone has seen the objects. The problem is eliminated in the conference room by the use of a camera, which takes the picture of the object and visualizes it on the third screen so it can be seen by everyone simultaneously. Tridimensional objects can be turned by moderator and facilitate thus the recognition of specific qualities or functionalities [5]. The sketching on the touchsensitive board can be visualized via two channels. Thus, the problem of hiding the sketches by the presenter is solved. The second projection screen is not masked and allows the listeners to perceive the visualization and the relevant explanation synchronously. The available technique enables the presenter to choose a fitting visualization device in order to present almost any information without any spill [2] [3]. However, this will result in new requirement profiles for the presenter, which are totally different from the conventional moderation techniques. An example will be the performed visualization with the use of projectors. This requires a partial or completely darkened room unlike a visualization on posters. Thus, the presenter and his gesticulation becomes less important and an important information channel between the presenter and the team-members is disabled. The classical rules of the presentation technique can only be relatively used in the technology based moderation environment. The usage of the devices is an additional task for the presenter and requires also new rules in the moderation. The result of the series of experiments was that persons without experience in moderation techniques are unable to handle both, the presentation and the technical equipment. In this case no benefit arises from the new technology. The available technique encourages the presenter to change the media very frequently which has a negative result on the listeners.

6.7 Teamwork Very frequently larger sessions or workshops are splitted up into individual teams. These teams have to process exactly defined subject areas. The teamwork is followed by a presentation for the other workshop members. For the effective realization of the teamwork it is reasonable that the team starts with working materials made available by the plenum. It is conceivable that every group gets the complete technical setup. However, this is prohibited by the high costs. Due to the missing technical equipment conventional means like blackboards, flipcharts etc. are used instead. Using these conventional devices causes that the technological chain is disturbed. This implies that identical devices must be used for a later presentation of the teamwork in front of the group. From that a break of the technological concatenation results in a deactivation of the technological support. If a further work of the plenum is needed based on the results of the teams the plenum has to use the same means. In order to use the results of the teamwork later on the conventionally generated posters have to be post-processed and digitized. This results in additional work combined with a restructuring of the poster. Since any change can corrupt the poster's contents it is not recommended to make any modifications.

430

ICED 01 - C586/040

Furthermore a teamwork distinguishes considerably from a presentation. Beside the completely different working methods another essential difference is that the work area is horizontal during a teamwork while it is vertical for a presentation. The available touchsensitive boards are designed for presentation tasks and thus not suitable for horizontal use. Within a normal interaction, for example during drawing or sketching, the persons frequently touch the sensitive surface at several places. Placing the hand on the pad during the writing or sketching will cause digitalization errors. This problem was recognized very fast by the tested persons. However, the above described mistake occurred again and again. The reason for this is that the required single-point input for the touch-sensitive board is not corresponding to the natural movement of the human being. The unnatural way the write or to sketch on a horizontal surface results in a cramp and in fast exhaustion. Combined with that is a clear reduction of the efficiency of a group [1]. Another difference between a teamwork and a presentation is that the teamwork uses other techniques than a presentation, for example it is not moderated. Thus, it is possible that several members of a team can draw simultaneously. However, a synchronous recording of several pen positions is not supported by the technology of the touch-sensitive boards. Therefore the touch-sensitive boards cannot be used for such a teamwork. In conclusion the available technology does not support the work of subgroups very well. However, the available technology basically supports the presentation but not the creative generation of ideas.

6.8 Taking a protocol To guarantee the success of a carried out session it is necessary that a protocol is taken. Taking the protocol of a conventional session is difficult, since the elaborated documents are not suitable to be taken into a protocol without any modification. Large scale documents like posters have to be reformatted or post-processed in order to make them suitable for the protocol. Very frequently important context information is lost and a later reworking of a session becomes complicated. In addition the preparation of such posters is time-consuming and cost-intensive. In part important posters are linked into a protocol as a photograph. In order to keep the document size small for an electronic forwarding the pictures are embedded with low resolution which complicates the later on use. The carried out series of experiments showed that the possibility of the immediate printout of the posters is regarded as very useful. These printouts can be full-scale by the use of a plotter or they can be scaled down in order to realize smaller formats for a printer. In part the digital data which were created in the plenum could be taken over directly into the protocol. An essential advantage of the digitizing by the touch-sensitive boards consists in archiving and reworking. All written or sketched inputs are in a digital form and can be distributed for example to the team members as a handout. The digitized data can be used in future sessions, either with the functionality of the touch-sensitive board itself or with a bitmap processing program. All the required tasks could be done by the tested persons very easily and result in a higher effectiveness of the carried out sessions.

7

Conclusions

The different situations of a teamwork were examined, both the work in the plenum as well as the work in smaller teams. The carried out investigations made clear that the technology of the conference room cannot be used completely without further knowledge on the system.

ICED 01 -C586/040

431

Although the intuitive writing or sketching on the touch-sensitive boards is possible after a short training phase the further use of these elaborations as well as the usage of the peripheral units only can be done by a trained presenter. The technology-based conference room does not support all conventional working methods. Thus, in many cases the conventional methods are still needed. Using such a conventional method causes a break of the technological chain. In particular in the presentation technique, in the elaboration of common posters and in taking the minutes the new technology is very helpful. On the other hand other techniques as for example the metaplan technique or the teamwork cannot be supported very well by the new technology. The currently available components only can be used in particular fields. However, they do not offer yet a comprehensive solution for the realization of a complete meeting.

8

Future work

Future work will aim at eliminating the recognized problems. This will be in particular the realization metaplan technique as well as the realization of an teamwork supported by new information technologies. A continuous technological chain over an entire teamsession is supposed to be achieved. On the one hand this can be done by better software- and hardware and also in the networking of existing components. On the other hand the construction of new interaction devices and procedures have to be realized. In order to keep on optimizing the moderation technique the writing and sketching on the two touch-sensitive boards must be exchanged between the two projection screens as desired. This will realized by extending the currently used software.

9

Acknowledgements

The above project was funded by the Swiss research fund KTI 4475. 1PMS. We thank in particular the IfAP (Institute for Work and Organization Psychology) and the HGKZ (University of Art and Design Zurich). References [1]

Ernesto Arias, Hal Eden, Gerhard Fischer, Andrew Gorman, Eric Scharff; ,,Creating Shared Understanding through Collaborative Deisgn"; University of Colorado, Boulder; CHI-Proceedings

[2]

Thomas P. Moran, Patrick Chiu, William van Melle, Gordon Kurtenbach; Jmplicit Structures for Pen-Based Systems Within a Freeform Interaction Paradigm"; Proceedings og CHI 1995

[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 for Collective Design Processes"; International Design Conference, May 23.-26, 2000

[5]

Orfeo Niedermann; ,,Nutzenanalyse des Einsatzes der Virtual Reality Technologie in der Failure Mode and Effect Analysis"; ETH Internal Research Report 1999

© IMechE 2001

432

ICED 01 - C586/040

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

THE IMPORTANCE OF INFORMAL NETWORKS TO EFFECTIVE DESIGN MANAGEMENT N J Brookes, P Smart, and F Lettice keywords: design management, design teams, human resources, concurrent engineering

1 Introduction "Well, does it really matter how you organise the company or what the functions are or what the organisation inside the functions are? ....A (product development) project or a set of projects are nothing more than conversations and relationships with people. How you have those conversations and how you deal with people enables them to push limits." Project Director - New Product Development, interview transcript from the 'Working the Boundaries' project The aim of this paper is to present the work of the 'Working the Boundaries' project and the way in which this work has highlighted the importance of informal networks of organisational relationships in design management. The 'Working the Boundaries' project was an eighteen month project funded by the Engineering and Physical Sciences Research Council and based in the Wolfson School of Mechanical and Manufacturing Engineering in Loughborough University in the United Kingdom.

2 Background to the 'Working the Boundaries' Project Much of the recent work on improving design management has focused on developing the formal organization. Researchers and practitioners have concentrated on changing formal organizational structures often to make them more project-focused and have introduced formal processes and procedures for developing new products. This is especially evident in the work of the International Motor Vehicle Program and its related projects [1],[2],[3],[4] and structurally based approaches to concurrent engineering [5],[6],[7],[8]. Although significant individual project success has been reported through the adoption of these methods, problems related to total system performance have also been reported [9],[10],[11]. These focus on the following:• •

the 'functional rump' - product development activities that are difficult to place in projects either because of low volume or scarcity of resources to perform them. organizational learning issues - functional specialists allocated into project teams may gradually lose the distinguishing features that initially made them so desirable.

One response to these undesirable sides affects may be to further change the formal organization but, given the changing external and internal environment this may be an impossible task. Furthermore, research by Henderson [12] at the Sloan Management School, Massachusetts Institute of Technology has indicated that an 'optimal' form is not even

ICED01-C586/272

433

necessary. She has shown in the pharmaceutical industry that the formal organization was not the prime determinant of product development success. Instead she identified that the companies who sought to overcome formal boundaries wherever they were positioned were better at developing products successfully. This immediately begs the question of what mechanism can be used to overcome formal organizational boundaries and whether it can be harnessed in some way to improve the way design is managed and hence assist in improving product development performance. A feasibility study based at Loughborough University , the 'Working the Boundaries' Project, set out to answer this question. In order to do this, the project team made much use of the concept of 'informal organizational networks.' The phenomenon of informal networks within organisations has been widely recognised for some time [13],[14],[15],[16]. Some work has been undertaken to characterise these networks. For example Boutty [17] has identified how different types of relationship share R&D information across organisations. However the role of informal networks in design management remains largely unexplored and no-one has yet addressed the issue of whether these networks can be enhanced to improve the effectiveness of the design process.

3 Research Methodology The objectives of the 'Working the Boundaries project were:•

To investigate to see if Henderson's work held true in a different industrial environment i.e. to establish if other organisational factors than formal structure had an impact on successful design management

•

If formal structure was not of prime importance, to identify what organisational phenomena was associated with 'working the boundaries' to result in product development success

The research was highly exploratory in nature. The research team therefore determined that an 'in-depth' qualitative approach was required. To this end, it contacted a major UK automotive design and manufacturer who agreed to act as a case-study subject for the 'Working the Boundaries' project's investigations. The project sought to undertake a longitudinal analysis of twenty years of small and medium-sized automobile product development in case-study company. Using a time-line approach, it aimed to map the major product introductions and the performance of those product introductions. It also aimed to map, on the same time-line, the changes in formal organisational structure during that period and to characterize the changes in overall approach to design management that was experienced during this period. Using this data, the project proposed that tentative links could be developed between the performance of design managment and organisational characteristics present at that time. Because the research team were highly uncertain as to what they might find when undertaking the longitudinal analysis, the following staged research process was adopted:-

434

ICED 01 -C5 86/272

Figure 1 The Research Process for the 'Working the Boundaries' Project

The study obtained its data from project and programme manger and project directors. It used a variety of data collection mechanisms:• • •

semi-structured questionnaires non-directive interviews (whose transcripts were then thematically analysed) supporting documentary evidence.

Carrying out the research process in a series of stages proved invaluable. Two particular problems were encountered in generating a time-line for the case-study:Measuring the success of design management The research team began by trying to find objectively reported quantitative data on the performance of design and development projects. This proved difficult for the following reasons:• • •

data was never recorded in the first place historic data that was available was held in legacy systems ( sometimes as crude as people's individual filing cabinets) which were difficult to access data often had different datums which made comparisons difficult.

These results were not surprising and were similar to experience in a previous research study [18]. The team determined to measure the success of a particular design project by asking individuals concerned with a particular project to rate it from 1-5 (where 1 represented minimum performance and 5 a maximum level of performance) against the following criteria:• • •

design and development costs the quality of the product designed the lead-time for design and development

There are obvious problems with measuring a design and development project in these ways. The ratings used by the project were subjective. A tendency may also exist for an individual to 'mark up' a project in which she or he was concerned. Given the alternative (i.e. not trying to measure at all,) the team decided to proceed with this imperfect measurement of design activity.

ICED01-C586/272

435

Matching structure to project. The second difficulty encountered was matching a formal structure with a particular design and development project. The formal structure was never stable. In between significant step changes it was undergoing a process of constant 'tweaking'. Formal changes to structure were made whilst a project was underway so some projects found themselves operating, over time, with completely different organizational structure. The research team only mapped significant step changes in organisational structure associated with significant resource re-allocations.

4 Research Findings A simplified time-line for product introductions during the past twenty years is given in Figure 2. Three types of formal organization were used throughout this period. The first was a 'functional' organisation, where separate engineering disciplines were oganised in isolation. The second type of structure was a 'project' structure where virtually all engineering resources were allocated to a particular project and reported to a project director. The final type of formal organizational structure adopted was a 'lightweight' approach where a project grouping of primarily commercial and some limited engineering resource was maintained but the vast majority of engineering resource was organised functionally. When looking at the organisational success of these different structures, a first glance may suggest that a formal project structure was most successful. However this viewpoint must be tempered with the thematic analysis of the interviews undertaken. These indicated that the success of the

Figure 2 Simplified Time-line for New Product Introductions

'project' structure was not due to its inherent characteristics but because it promoted informality and allowed the interviewees to use the informal networks to achieve tasks. The following quotation illustrates this:"Networking, very important. I mean that's how project teams ... that's how the whole company works. It doesn 't matter what the formal organisation is, within reason, we all have to get the job

436

ICED 01 - C5 86/272

done. So long as you know who can help, and do things, via the old network scheme, you can get the right guy on the phone and you talk to him, explain, which is why project teams, I think are better, because they give you that freedom and everybody has that responsibility. So you're all working for a common aim and we're moving forward. "

This suggests that the period of success during the 'project' formal structure was due to flourishing informal networks. The following quotation illustrates how informal networks could be used to improve performance:"If there's a problem, say it's a body problem, and you know this problem, there's probably two ways of getting the problem sorted out. Maybe it's a very big problem the body falls apart after 1000 miles or something. Then using the formal organisation structure you 'd contact the head of this department and he would contact his junior who 'd contact the guy who does the work and then he 'd prepare a report for him and he 'd prepare a report for him and he'd give the information back to you.. The way Chinese whispers work....it means, you know, that you've lost something. You lose the problem definition, you don't quite get the answer to the question that you wanted to ask. You 've got to know that man. If you know him, you can ask him that question. You can have a much broader conversation than saying I've got a problem, please fix it. You can understand why is the problem there ? He understands why you are concerned about it "

Using the thematic analysis of the interviews, it was possible to characterize the informal networks that were designing and developing new products. (See Table 1). It is important to remember that the interviews were non-directive (i.e. they were not specifically asked about the themes outlined). Table 1: Thematic Analysis of Interviews

The informal organisation is important to successful product development

of interviewees stressed the importance of the informal organisation to successful product development 33% said the formal structure had little impact on project performance

The informal organisation is formed form relationships

80% stated that a network of productive relationships were needed for product development success

Informal networks last

60% recognised the longevity of relationships over several projects

Productive relationships need trust, common experience a social context and respect

40% highlighted the importance of trust to productive relationships 33% highlighted the importance of common experience (e.g. similar educational background, similar career history) 25% highlighted the importance of social context (i.e. the relationship is not solely work-based) 15% highlighted the importance of respect

ICED 01 - C586/272

437

If the findings of the 'Working the Boundaries project are viewed in the conjunction with Henderson's work, it is the informal network of relationships that overcomes the boundaries of formal structure. Individuals use informal networks to obtain and disseminate information and to re-allocate design and development activities.

5 Conclusions and Further Work In drawing conclusions from the 'Working the Boundaries' project, there is an obvious need for circumspection. The results were case-study based which immediately limits their wider applicability and the research methods adopted were, of necessity, subject to simplification. In spite of these limitations, the 'Working the Boundaries project' fulfilled its aims within its research boundaries. It identified that other organisational phenomena than formal structure were associated with successful product introduction. It identified these as informal networks of relationships. The conclusions of the 'Working the Boundaries' project can be summarised in the following statement of speculative theory:•

Successful introduction of new products is associated with using the informal organisation

•

The informal organisation is a network of relationships initiated by an individual that reallocates tasks and re-directs information

•

These informal relationships are strengthened by trust, common experiences, a social context and, to a lesser degree, respect.

•

These informal relationships are long lasting and survive may changes in the formal organisational structure

The implications of this speculative theory are immense. They suggest that successfully managing design may be much less about formal 'managing' (in terms of directing information flows, allocating tasks and identifying formal structure) and much more about 'letting go.' Managing design successfully may mean providing individuals with the skills and opportunities to enhance their own networks of relationships and allowing individuals to use their own networks. Further work is needed to confirm the findings of the 'Working the Boundaries' project on a much wider scale. This needs to not only to investigate other design and development projects in the pharmaceutical and automotive sectors but also to widen the industrial sectors involved in research Given the potential cultural sensitivity of informal networks, it would also be extremely interesting to investigate if similar findings were establishes in other cultures. Further work is also needed to embed the theory developed by the project into a management tool. This would enable organizations to assist individuals in developing and enhancing their own personal networks during the design process.

438

ICED 01 - C586/272

References [1] Clark KB and Fujimoto T, "Product Development Performance:Strategy . Organization and management in the world auto industry". HBS, Boston Mass, 1991. [2] Wheelwright, S.C., Clark, K.B.. Revolutionizing Product Development: Quantum Leaps in Speed. Efficiency and Quality, 1992, (Free Press, NY) [3] Kusiak A Wang J "Efficient Organizing of Design Activities." International Journal of Production Research v31 pp 753-769, 1993 [4] Eppinger AD, Whitney DE Smith RP Gebula D "A Model -base Method for Organizing Tasks in Product Development" Research in Engineering Design v6 nl ppl-13 1994 [5] Backhouse C J, Brookes N J, Concurrent Engineering: What's working where. Design Council/Gower, 1996 [6] Shina S G (ed). Successful implementation of Concurrent Engineering products and processes. New York: Van Nostrand Reinhold 1994. [7] Shenas D G and S Derakhshan. Organisational approaches to the implementation of Simultaneous Engineering. International Journal of Operations and Production Management, Vol 14, No 10, 30-43 1994. [8] Lettice F E. Concurrent Engineering: A team-based approach to rapid implementation. PhD Thesis. The CIM Institute, School of Industrial and Manufacturing Science, Cranfield University, UK 1995. [9] Francia, A, Macintosh, The Market, technological and industry context of business process re-engineering in the U.K. International Journal of Operations and Production Management, v17 n4 pp344-364 1997, [10] Sobek DK, Liker JK and Ward AC, Another Look at How Toyota Integrates Product Development, Harvard Business Review, July-August 1998 [11] Cusumano MA and Nobeka K Thinking Beyond Lean: How Multi-project Management is Transforming Product Development at Toyota and Other Companies. The Free Press. , 1998, [12] Henderson R, Managing Information in the Information Age Harvard Business Review Jan 1994 Reprint no: 94105 [13] Nohria N and Eccles RG Networks and Organizations: Structure. Form and Action. Harvard Business School Press, 1992. [14] Mintzberg H. van Heyden L. "Organigraphs: Drawing how companies really work". v77 n5 Sept-Oct, pp87-94, 1999 [15] Krackhardt D. and Hanson J.R. Informal Networks: The Company Behind the Chart. Harvard Business review July-August 1993 pp104-lll [16] Wenger EC, Snyder WM Communities of Practice: The organisational frontier Harvard Business Review Januray February 2000

ICED 01-C586/272

439

[17] Boutty I, Interpersonal and Interaction Influences on Informal Resource Exchanges Between R7D Researchers Across Organisational Boundaries. Academy of Management Journal, v43, nl, pp50-65, 2000 [18] Brookes, N.J. Backhouse, C.J., "Measuring the Performance of Product Introduction", Proceedings of the I.Mech.E. Part B Journal of Engineering Manufacture 212(B1), 1998, pp 1-11, ISSN 0954 4054.

Corresponding Author's Details: Naomi Brookes PhD DIC Lecturer - Wolfson School of Mechanical and Manufacturing Engineering Loughborough University Loughborough Leics LE11 3TU United Kingdom Tel: +44 (0)1509 227668 Email: [email protected] © IMechE2001

440

ICED 01 - C5 86/272

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

MANAGING UNCERTAINTY IN DESIGN COMMUNICATION M K Stacey and C M Eckert

Keywords: Ambiguity, uncertainty, design information management, collaborative design tools, computer supported cooperative work.

1

design

teams,

Introduction

The design of complex engineering products involves communicating design ideas and specifications - requirements, constraints, functions, parameters, behaviours, structures and components. These ideas are often exchanged when still tentative, imprecise and incomplete; moreover the forms in which they are expressed can be imprecise and ambiguous. In conversations, sketches, gestures and words are used in combination to disambiguate each other, and designers convey their degree of commitment to ideas by modulating phrasing and tone of voice [1]. But in large-scale design processes, the different elements of designs also need to travel through space and time, to places where misunderstandings can have severe consequences. How can engineers separated by space and time avoid misunderstandings and make effective use of the uncertainty and provisionality inherent in design idea development?

2

Uncertainty in design communication

In any team designing activity designers need to express ideas for parts of the design that are provisional, imprecise or incomplete. This is obviously true for early conceptual design. Early in the design process designers expect that some information is provisional and may question the status of parameter values and other decisions. But designers have to deal with uncertain information and provisional proposals at all stages in the design process. This provisionality and imprecision is usually apparent to the participants in meetings where ideas are put forward, though there is plenty of scope for misunderstandings. But coping with uncertainty is more problematic in the interactions between separate tasks and activities dealing with related aspects of the design, especially where information is exchanged primarily through diagrams, drawings, CAD models or written specifications. The difficulty of coordinating complex design processes is a limiting factor on the effective use of provisional and uncertain information. In the design of complex products, designers need to made decisions when they cannot assess their consequences; and the designers responsible for mutually dependent aspects of the design need to influence each other's designing to be sure of finding shared parameter values that work for both parts of the design. This requires working with and passing on provisional and incomplete design decisions [2, 3]. But commonly some tasks and parameters are given priority, to give the design process a manageable linear structure, at the cost of harder tasks and suboptimal designs later on. Sometimes more-or-less arbitrary choices are treated as fixed and firm at later stages in the process; other values and decisions are set provisionally while others are left open.

ICED 01 - C586/516

441

In engineering design, conversations are almost always centred round some external representation of the design, such as sketches, drawings, CAD models and prototypes. Moreover, communication between design activities is largely through artefacts such as CAD models, drawings and specifications; they often convey information between designers with different expertise and sets of concepts for thinking about designs, who read them in different ways [see 4]. Often these representations are ill suited to expressing imprecise and provisional information. Many companies feel that once the entire organisation uses CAD models to design and communicate all their problems will be solved, but contemporary CAD systems require precise values, and do not support imprecision or other uncertainty information [but see 5], so that provisional decisions or placeholders look firm.

2.1 Communicating uncertainty in joint designing Joint designing in meetings is important in most design processes, especially for early conceptual design, where design ideas are typically vague, provisional, imprecise and incomplete. In design conversations sketches, gestures and words are used in combination to explicate and disambiguate each other [6, 7, 8, 9]. The participants in joint designing usually get rapid feedback on whether they have been understood (though clarification is a major activity within meetings). So they can interactively negotiate an understanding of each other's positions, as well as negotiate about decisions, before the (provisional or imprecise) decisions are represented in precise-seeming forms [8]. Designers use rhetorical techniques for argumentation, including subtleties of phrasing and tone, to modulate the degree of belief they express in ideas, and signal willingness to make trade-offs, as well as to express exactitude [8, 1]. However there is no guarantee that all the participants will always pick up these signals.

2.2 Communicating uncertainty between design activities The need to handle imprecision and provisionality is not restricted to designing individual aspects of the design, or to meetings between designers. In the design of complex products, many design activities make decisions that impinge on activities carried out elsewhere, or later. Resolving conflicts between different aspects of a design is often an important activity. Designers who receive messages and specifications and interpret graphic representations need to know both how far they can rely on what they are given and how far they can change it. The senders need to ensure that further development of the design is not incompatible with what they have done [see 10]. Design handover situations still exist in many industries. Even if a handover is accompanied by a meeting, the recipients usually get little or no indication about what aspects of the design are fixed and essential and which are mutable; and they may only become aware of problems once they are working on their own. They thus have much less scope for interactively negotiating a common understanding of the situation with their colleagues, and so depend much more on clear and complete design specifications. As products become more complex their development becomes more multidisciplinary and increasingly more international. Despite the best efforts of groupware system developers, joint designing in virtual meetings across different locations remains cumbersome, and is hard to make work across cultural, time and language barriers.

2.3 Uncertainty and ambiguity in graphical representations Ambiguity is created by the availability of alternative referents for words, symbols, and symbolic or deictic gestures [see 9 for examples]. What referents are available depends on the interpreter's understanding of languages and notational conventions, as well as of the design

442

ICED 01-C586/516

situation [see 4]. But the role of prior context in design communication goes beyond the need for the recipient to recognise graphic codes and ascribe the intended referents to words and symbols. Representations of designs are abstractions in which aspects of the design are not fully specified. Understanding how much of what is not shown is fixed, and what can be varied, is as essential as understanding the explicit content of a representation. Alternative interpretations of the omitted elements of a design are made possible by uncertainty or misunderstanding about the interpretive conventions to be applied to a representation, as well as the context in which it is embedded and the assumptions the generator makes about how the gaps will be filled in. Thus it can be ambiguous by omission. In other words, what is implicit in any representation depends on the interpretive skills of the recipient and the extent of the shared understanding of context established between the sender and the recipient. Roughness in sketches expresses lack of certainty, but the viewers often can't distinguish between intended imprecision and poor drawing, or between a qualitative placeholder and a relatively exact depiction, or between a simple form drawn roughly and a more subtle form drawn more accurately [10, 11]. One sketch or drawing often stands for a whole space of possible designs, but the viewer and the creator cannot know whether they interpret this space in the same way. As we have found in the case of knitwear designers' garment specifications [11, 12], the generation of sketches and other forms of external descriptions that constitute accurate and unbiased representations of the generator's understanding of a design is problematic: people don't mean exactly what they draw. Idiosyncrasies and poor drawing in their sketches and diagrams bias interpretation by others towards different central meanings as well as different judgements of imprecision and provisionality. While the reasons for decisions are usually apparent to the participants in joint designing activities, they can be opaque to other readers of design representations. Understanding the reasons for decisions is often essential for interpreting the uncertainty of design information, as well as for interpreting omissions. Methodologies and computer systems for process management place increasing importance on recording the rationales for decisions, as part of managing the provision of contextual information. Some earlier discussions of imprecision, uncertainty and ambiguity in design communication [8, 1] lump all these together under 'ambiguity'. This is confusing, and promotes the currently influential view that ambiguity (more narrowly defined as the availability of more than one qualitatively distinct interpretation) is beneficial in design communication, and that aiming to use computer tools to create unambiguous descriptions of designs is a discredited enterprise; this we doubt [10]. However Minneman argues that designers sometimes do exploit ambiguity. Nonetheless joint designing is very different from communication between activities; handing over ambiguous representations can cause severe problems [11, 12].

2.4 Allowing for uncertainty in design planning One of the great challenges of design management is to find the right time to start a task. If one waits until all the information is available the process can become rather drawn out. Starting a task too early with insufficient information can lead to later reworking, which in turn can lead to delays in the design process. Many tasks are mutually dependent, because different aspects of the design influence and depend on the same parameters. Design managers can use methods such as Design Structure Matrices [13] to identify the information dependencies between tasks and find the shortest design process requiring a minimum amount of provisional information. Design Structure Matrices also make it possible to identify clusters of mutually dependent tasks, where each task needs the result of the other as inputs.

ICED01-C586/516

443

These clusters can only be broken by using parameter estimates and repeating tasks to converge to compatible parameter values in a tightly integrated design process [2, 3]. Planning design processes to use uncertain information has three conflicting goals: to minimise development time; to minimise the risk of starting tasks with provisional information; and to exploit provisionality and imprecision in solutions to underconstrained problems in optimising other aspects of the design. To meet these objectives designers need to identify those tasks that can be undertaken with provisional information (for example it would not make sense to start finite element analysis with estimates). They need suitable ways to estimate parameter values. And they need to find ways to communicate which decisions and parameter values are fixed and which are provisional, and how far they can be modified.

3

A typology of forms of uncertainty in design

Greater conceptual clarity about the different forms of uncertainty is needed both for understanding human design behaviour, and for planning and managing design processes to achieve better coordination between design activities. The following concepts are conceptually distinct and potentially useful for interpreting what design actions are compatible with the current state of the design. This typology is discussed with more careful attention to the conceptual status of the different uncertainty concepts in [10]. •

Precision. How exactly the aspect of the design is specified. (Does x=10 mean 9.998<x<10.002 or 8<x<12?) Less quantitatively, how far the details of the representation are meant exactly or as placeholders for qualitative values or more abstract categories.

•

Typicality. The extent to which the aspect of the design is typical of the range of possible acceptable choices, or shows a central value in a quantitative range. (A sketch or diagram often represents an entire space of possible designs by showing a relatively concrete typical design. The interpretation of what is a typical case varies between individuals.)

•

Commitment (the opposite of provisionality). The degree to which the project is committed to keeping this aspect of the design the way it is (and conversely, how easily it can be changed to meet other needs). Representations of designs such as sketches often include elements embodying provisional decisions (or even non-decisions) to provide a context for other elements with a greater degree of commitment.

•

Sensitivity. How far the aspect of the design can be changed without significantly affecting the rest of the design. (Analyses of sensitivity include the consequences of changing it more than that.)

•

Input Confidence. The degree to which the inputs and assumptions on which the aspect of the design was based are stable and reliable.

•

Understanding. The extent to which the user has sufficient information and expertise to decide the form of this aspect of the design from the input information. Hence, the degree to which an aspect of the design can be relied as being satisfactory in relation to the parameter values and constraints from which it was generated.

•

Confidence. The degree to which an aspect of the design can be relied on as satisfactory. (The product of Input Confidence and Understanding.)

444

ICED 01-C586/516

These aspects of uncertainty are signalled (or not) in the communicative objects and messages (including gestures as well as the intonation of speech) designers use to communicate their ideas. However designers' perception and phenomenological experience of uncertainty is certainly often more wholistic and conceptually messier, for instance in the modulation of subjective degree of belief (confidence x commitment?) [see 1]. What uncertainty information engineers and other designers can, in practice, both use and pass on is a significant open research question. Clarkson et al. [2] argue from extensive experience of industrial engineering design that engineers are content with classifying values as initial estimates, feasible estimates, and final values. Failure to interpret any of these uncertainty factors correctly causes misunderstanding of the scope for further designing. Similarly, uncertainty about these factors (as well as about what the values of parameters or other choices are) causes doubt about how to proceed with a design. This is the consequence of vagueness. Ambiguity in design communication is the availability of interpretations as qualitatively different alternative models, either for individuals, or for those different people with different knowledge and interpretive skills whose interpretations are relevant to the task or situation.

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 out partly in parallel; and to avoid premature closure of design decisions resulting from imposing a linear sequence on tasks that could achieve better results if treated as interdependent. In all these situations all team members must understand in which way information is uncertain, and what is the likelihood and scope of possible variation. To do this managing uncertainty must be treated as an integral part of managing information flow through a design process. •

Supporting informal channels. Many studies of complex organisations have found that informal communication channels are vitally important and often poorly understood [for instance 14]. Communication between the people who need to exchange information should be easy and efficient, but is often blocked by the social organisation of the design process [see 15]. When a design process is restructured, for example when parts of it are sub-contracted, it essential to identify the information that flows through informal contacts to ensure that it is not cut off. Meta-information about uncertainty that is never formally recorded is sometimes an important part of this.

•

Understanding task dependencies. Understanding how different aspects of the design are mutually dependent, and what design activities can and cannot achieve with imprecise or provisional information, is an essential first step towards planning the interactions between design activities that are needed for achieving an effective sequence of tasks. This includes making decisions about the priorities of parameters, and providing for the exchange of provisional information between activities so that they can converge iteratively to a compatible design.

•

Assembling negotiation groups. This leads to the question of who needs to be involved in a design activity to ensure that all the relevant issues are considered, and how the designers responsible for one task should interact with their colleagues who are affected by their decisions. Therefore it is important to establish who needs to meet for rapid negotiation and informal briefing; and who needs to be provided with meta-information by message passing or annotation. An answer to this question needs to be cost-effective

ICED 01 - C586/516

445

both globally, in that increasing opportunities for debate and change increases quality without adversely affecting lead times, and locally, in that the communication of uncertainty information by individuals must not impose a burden on designers that is onerous or not clearly justified. Endless meetings often take up a lot of the designers' time and stop them from working productively on their own. •

Composition of design teams. How team members interpret information depends on their background and experience. The more diverse they are the more likely they are to bring new ideas and insights into the process, but the less likely they are to understand ambiguous information in the intended way or know how widely to interpret uncertain information. Members of task teams who understand connected tasks can anticipate and judge the exactness and commitment of the other tasks' outputs.

•

Assessing the power of design representations. Designers and their managers must be aware of what can be expressed in a certain design representation, and how different people will read it. All representations make some aspects salient and obscure others.

•

Assessing the role of the design representations. Representations of designs serve to structure the design process [4], sometimes in ways that their creators are only partly conscious of, for example when faults in specifications are used deliberately to force face to face communication [12]. Understanding how involvement with the design is organised around CAD models and other information artefacts will help understanding how uncertainty information is used.

•

Coordinating understanding. Designers with different expertise and awareness of context will read sketches and representations of designs differently. They are likely to interpret gaps in incomplete descriptions and indications of provisionality and imprecision differently. However this can be alleviated by coordinating understanding, not just by negotiating over individual designs, but by developing a vocabulary of terms with agreed compatible interpretations (for instance, of signals for imprecision and provisionality).

•

Supporting asynchronous negotiation through the transmission of meta-information. When designers need to create models and records, and communicate asynchronously, they should be able to indicate degrees of uncertainty by annotating diagrams and models. However this annotation needs to be quick and easy enough to be cost-effective.

5

Computer systems for communicating uncertainty clearly

Computer support for communication in design has concentrated largely on facilitating remote real time communication, thus supporting handling uncertainty indirectly by enabling the use of speech, gestures and sketching, with rapid feedback, in situation that otherwise would be dealt with by telephone or by sending messages. But computer systems can also enhance the effectiveness of message passing and communicating through designs. Nevertheless the human designers still need to make sure that their colleagues can understand the degree and type of uncertainty they wish to communicate. •

Increasing the bandwidth of asynchronous message passing. One strand of research aims to use remote meeting technology for sending messages using the full resources of face-to-face conversation (sketching, gesturing and referring to objects in the environment, as well as tones of voice signalling degree of belief) [16].

446

ICED 01 - C586/516

•

Removing the uncertainty from the representation. In some situations communication could be enhanced by enabling designers to create more exact or detailed design information cost-effectively, or by solving technical problems for them [see 12]. Systems that generate designs from user specifications, or guided by user selection, can produce designs that are technically correct and certain at a certain level of abstraction. We discuss elsewhere the role of generative systems in design creativity and communication, arguing that automatic design systems can facilitate creative designing and can fit naturally into some commercial design processes [17]. We present a technological solution to some of the communication problems in knitwear design caused by ambiguity and conflicting indicators of uncertainty: a garment shape design system that uses mathematical models and heuristic reasoning to construct shapes from designers' customary descriptions, incomplete (and often incorrect and inconsistent) sets of parameters [17].

•

Annotating design information. An agreed vocabulary of uncertainty indicators, and quick and easy methods for adding annotations to CAD models and other representations would make indicating appropriate degrees of uncertainty substantially easier, and hence more likely to prove cost-effective in practice.

•

Planning interactions between tasks. We are developing Signposting systems to support design planning that break task dependency loops and coordinate interdependent activities by exploiting estimated and preliminary parameter values. The first systems use confidence as a qualifier on parameter values ('preliminary estimate', 'good estimate', 'final'), to determine the earliest time that a task can be started [2]. We are currently exploring how a much wider range of uncertainty information might be used to guide task planning and task selection in further Signposting systems [3].

Acknowledgements This research was supported by the EPSRC rolling grant to the Cambridge Engineering Design Centre, and by GKN Westland Helicopters Ltd and Lotus Engineering Ltd. We are grateful to our informants for the time and trouble they took talking to us. References [1]

Brereton, M.F, Cannon, D.M., Mabogunje, A. and Leifer, L., "Collaboration in Design Teams: Mediating Design Progress through Social Interaction", in N.G. Cross, H.H.C.M. Christiaans and K. Dorst, (eds.), Analysing Design Activity, John Wiley, Chichester, UK, 1996, pp. 319-341.

[2]

Clarkson, P.J. and Hamilton, J.R., "'Signposting', A Parameter-driven Task-based Model of the Design Process", Research in Engineering Design. Vol. 12, pp. 18-38, 2000.

[3]

Stacey, M.K., Clarkson, P.J. and Eckert, C.M., "Signposting: an AI approach to supporting human decision making in design", Proceedings of the ASME 20th Computers and Information in Engineering Conference, University of Maryland, Baltimore, USA, 2000.

[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 for computer-aided geometric design systems", in J.S. Gero and F. Sudweeks (eds.), Artificial Intelligence in Design '96. Kluwer, Dordrecht, Holland, 1996, pp. 623-639.

[6]

Bly, S.A. "A Use of Drawing Surfaces in Different Collaborative Settings" another line for this.

[7]

Tang, J.C., "Listing, Drawing and Gesturing in Design: A Study of the Use of Shared Workspaces by Design Teams", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1989. Xerox PARC report SSL-89-3.

[8]

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

[9]

Neilson, I. and Lee, J. "Conversations with graphics: implications for the design of natural language/graphics interfaces", International Journal of Human-Computer Studies. Vol. 40, pp. 509-541, 1994.

[10] Stacey, M.K. and Eckert, Cooperative Work, in press.

C.M.,

"Against

Ambiguity", Computer

Supported

[11] Stacey, M.K., Eckert, C.M. and McFadzean, J., "Sketch Interpretation in Design Communication", Proceedings of ICED'99. Technical University of Munich, Munich, Germany, Vol. 2, pp. 923-928, 1999. [12] Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis and Computing Solutions", Computer Supported Cooperative Work. 2001. [13] Eppinger S.D., Whitney, D.E., Smith, R.P. Smith and Gebala, D.A., "A Model-Based Method for Organizing Tasks in Product Development", Research in Engineering Design. Vol. 6, pp. 1-13, 1994. [14] Medland, A.J., "Forms of Communications Observed During the Study of Design Activities in Industry", Journal of Engineering Design, Vol. 5, pp. 243-253, 1992. [15] Eckert, C.M., Clarkson, P.J. and Stacey, M.K., "Information Flow in Engineering Companies: Problems and their Causes", Proceedings of ICED'0l. PEP, Glasgow, UK, 2001. [16] Minneman, S.L. and Harrison, S.R., "The DrawStream Station: a tool for distributed and asynchronous chats about sketches and artifacts", Proceedings of HCI'99, Munich, Germany, 1999. [17] Eckert, C.M., Kelly, I. and Stacey, M.K., "Generative systems for interactive design: an empirical approach", Artificial Intelligence in Engineering Design, Analysis and Manufacturing, Vol. 13, pp. 303-320, 1999. Martin Stacey Department of Computer and Information Sciences De Montfort University Milton Keynes MK7 6HP, UK Phone: +44 1908 834936 Fax: +44 1908 834948 [email protected] www.mk.dmu.ac.uk/~mstacey

Claudia Eckert Engineering Design Centre Department of Engineering University of Cambridge Cambridge CB2 1PZ, UK Phone: +44 1223 332758 Fax: +44 1223 332662 [email protected] www.eng.cam.ac.uk/~cme26

© IMechE 2001

448

ICED 01 - C586/516

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

MANAGING THE INTEGRATION BETWEEN DESIGN, RESEARCH, AND PRODUCTION IN THE AUTOMOBILE INDUSTRY H V de Medina and R M Navciro Keywords: design management, product planning, design integration, design teams

1

Introduction:

The way companies design products is widely recognized as crucial to their success. The companies are being challenged to achieve an integrated environment to develop their products and are acquainted that their success is strongly dependent on their ability to organize, to process and to learn from information that is related to the product development cycle. In fact the development of a new product is nowadays part of a global system of innovation that actually supports the ongoing industrial restructuring for the years 2000's. An integrated strategy for technical, social and cultural change inside the companies is promoting a revolution from the shop floor to the R&D bureau, based on new forms of designing management and work organization. The automobile industry has faced a complete restructuring process in recent years. Carmakers have merged forming conglomerates, R&D has been shared between car manufactures' and suppliers, and so the automobile has been reinvented, as it embodies an invisible set of innovations in materials, sensors, control devices, etc. At the production level, things have followed the same way. Companies are increasing third party work and reducing the supplier base, as well as enlarging the role of the first rank suppliers in the design of new products. Furthermore, partnerships between suppliers and carmakers are established since the launching of a new project, sharing part of the R&D costs and profits. In a global level, the strategies adopted by North American and European companies, for keeping and sustaining their market share, were focused on technical and organizational innovations, specially concerning the reduction of the time lag between conception and commercialization of new models. A wider range of options among standard cars and a great effort on improving the quality and reducing environmental impacts were the main goals. These objectives were reached by integrating research, design, and production as parts of different fields of knowledge, in a multidisciplinary system represented by the dissemination of simultaneous engineering methods for the whole company. By doing so the distance between research and production has been drastically reduced, avoiding back and forth efforts that usually take a lot of time and money from the governments, enterprises and society in general. A number of case studies on automobile industry were developed from the middle seventies up to the nineties. There are still many long lasting international research projects aiming to evaluate and enhance technological and organizational innovation such as the ULASB (ultra light automobile steel body), the PNGV (partnership for a new generation of vehicles), and the

ICED 01 -C586/400

449

EUROCAR (European car program for European Union). Besides, the largest Car Company in the world has its own research driving innovation named "Product Engineering for GM Advanced Technology Vehicles" which includes the EV1 project that reached 23 new patents. Buchholz [ 1 ] stated about it: "Design for assembly drives innovation especially with a new program. At the onset of $350 million EVl program 150 people -including GM engineers, manufacturing engineers, material engineers finance representatives, and suppliers - trained and practice over six months period on design for assembly dynamics. (...) Training time allowed product development teams to address assembly requirements up front (...) if we didn 't design for assembling considerations the EV1, than the plant layout would be radically different - probably twice as large and more complicated". The introduction of new materials in Renault cars followed this pattern: a team of material experts, product designers and production engineers have worked side by side in order to define the requirements for new advances in the materials field. This is the core idea claimed by the so called Concurrent or Simultaneous Engineering where a cross-functional group of experts from all relevant disciplines that affect the project, are supported by computer technology and communication systems. "Concurrent Engineering represents a way of conducting the design work where the various activities related to the product realization process are integrated and performed as much as possible in parallel rather than in sequence [2] ". Task overlapping is the main management method adopted, and its implementation is done through early release of partial design information within the team in order to allow downstream preliminary considerations just from the beginning. For materials producers, for instance auto-parts suppliers and automobile manufacturers the key factor for succeeding in the next century seems to be the continuous and larger cooperation keeping themselves side by side defining together requirements for new advances. And the coordination of this network during the development phase of such complex product as a car is a hard task. In the past, materials were selected from a "menu" where all available materials were listed. Materials substitution was done part by part, e.g. a plastic bumper replacing steel one. Research and development of new materials were done apart from their final applications; new materials used to appear in the market and carmakers selected them instead of the old ones. The shortcomings of this approach were that it did not profit from the functional integration opportunities enabled by new materials processes. During the late eighties carmakers had implemented the engineering approach, and took advantage in reducing the number of parts in a vehicle by integrating functions embodied in new parts. Boujut and Jeanet [3] give to us a good example of how hard is to involve suppliers from the beginning of a product development and how crucial is to create instruments to a cooperative type of coordination for the so called "interface actors". In fact this choice was enabled by a process of global innovation that can be defined as the results of an integrated system of car designing from R&D, to production level redefining all phases in parallel such as materials selection, electronic devices, new embodied technologies, new assembly line organization and techniques, the workers profile and specialization etc. From now on they do all that in partnership networks including materials suppliers, auto parts producers, electronic systems dealers, and, together, they have to rethink globally the conception of new cars balancing technical performance and environmental impacts, from the birth to the death of the new vehicle. In other words, they are supposed to do life cycle

450

ICED 01 -C586/400

analysis of the product during the project development. For instance, they have to go from the assembly to the disassemby specifications to enhance the recyclability of the automobile as a whole. And they have to do this as fast and as "innovatively" as possible in order to be competitive for the next century. This means that companies are being challenged to achieve an integrated environment - what they call "plateau project" in France - to develop their new products in order to compress the design cycle and improve project effectiveness. So the costs of the design phase seems to be increased by the incorporation of R&D activities as well as the investments done on pilot and industrial plants. Actually, design activities were enlarged including, in a broader view, from the first marketing idea till the end of car's life, passing by R&D, prototypes; vehicle engineering, up to final assembly, "disassembling" and recycling. Furthermore, they have to pass through all those phases together with their partners and always keeping the final client in mind, as the Clio project schematic view shows to us [see the picture at the end of this article].

2

The Automobile life cycle: Designing for innovation

In the last twenty years, the automobile industry established a new pattern of innovation and production management that incorporates systematic and continuous technological advances and that enables organizational evolution as well. As a result, the innovation process is getting more and more integrated enhancing a synergic view of product and process design, R&D, and manufacturing. In other words, by means of Simultaneous engineering and beyond it the design activity was enlarged in order to cope with innovation requirements from product research to the industrialization phase. Moreover, technological and organizational change is now part of the same process of global and continuous innovation supported by flexible new car's projects. In this context, technological and organizational learning is enabled, by means of this integrated environment, where design activities are developed and managed simultaneously [4]. In this scenario partnership is a key word. Different kinds of knowledge are shared by the automobile designers and suppliers, and a multidisciplinary know-how has been created as a result of team work in "plateau" at the development of projects for new and innovative cars. Furthermore, the way automobiles are being conceived and manufactured by the end of their first century also changes the concept of the most representative product of our era. What is really a car nowadays? Is an automobile just a means of transportation? Or is it a better way of life, a place to live in, to work in, or a tool for leisure? For the MIT definition a car is "a four wheeled, internally powered personal transport apparatus for road use, designed to carry a driver and a few passengers. " But in fact a car is an hybrid object that is recognized by its shape but not by its technological and social complexity. We would say that it is not one product but multiproduct conceived and assembled as a jigsaw puzzle. And this grysaw puzzle is not a regular one, which is formed by articulated parts, because in the case of the automobile these parts are not only articulated but also integrated in a synergic way so every little detail affects the final result [5]. In this sense Clark and Fujimoto [6] have a better definition: "a car is a complex 'fabricated-assembled' product, comprising a large number of components, functions, and process steps. " These authors have pointed out the diversification of automobile models that provides to consumers, more than ever, a growing different range

ICED 01 -C586/400

451

of options. In their words: "Twenty years ago, the American car buyer had to look long and hard to find a model with anything but a traditional V-8 engine with rear-wheel drive. Today, the variety of engine-drive train combination is large - 4, 5, 6, 8 and 12 - cylinders, multivalves, front-wheel drive, and four wheel drive. Looking at other parts of the car, we find new technology in brakes and suspensions, engine control systems and materials and electronics "[9, page 8]. This is a good picture of a two-decade effort in speeding innovations to bridge the technological gap of car industry compared to the high-tech sectors, such as for example aeronautic, space, and electronics. These sectors were the pioneers in the use of new materials. They took advantage of technological developments that came from physics, chemistry and materials science itself to generate all sorts of product and process innovations. Quoting Bragg [7] on the role of these advances for automobile industry: "Now, more than ever, materials research and development is critical for satisfying customers. Now, as from the dim beginning of this proud industry, the role of materials people is often backstage. The automobile designer will always be creative. Many ideas and design have been spawned, only to wait until materials development made the dream a reality. " So the automakers are nowadays redefining their product according to the consumers' expectations, reaching to improve the engine performance as well as to rend new models more comfortable, safer, easier to drive, and environmentally friendly. To meet these needs, the industrial project of a new model has to be «alive» in order to incorporate the continuous technical advances that can provide new functionalities to the car. This is achieved by means of an integrated design environment where simultaneous engineering methods are the key management tool employed. This new pattern is no more a top car makers issue, as it used to be two decades ago, it is now widely spread throughout automobile world companies as a philosophy of work organization to keep their competitiveness by means of continuous innovation strategy. The redrawing of the project coordination as well as its physics and organizational basis allowed the car companies concentrating on what differentiates them competitively. This strategic choice that demands a hard job on coordinating internal and external partners-actors' contributions, as can be confirmed by the Renault Clio project and the Technocentre story that we have studied.

3

Managing the Designing Integration for the New Renault Clio

This successful story was written by 600 persons that have shared an integrated engineering environment called "plateau-projet", physically located at Renault Technocentre and supported by updated technology in communications that enabled cooperative and simultaneous work. The design group was formed including people of inside and outside Renault, such as partners like GE Plastics and Omninun Plastiques. GE was in charge of the development of a new composite for car's wing use. So it is also the story of the Noryl 974, a new polymer-based composite developed during the project result of the partnership between Renault, GE and Omninun Plastiques, which would be the wing's producer. The New Clio was designed at Technocentre Renault, considered by SIA -Societe des Ingenieurs Automobile- the most advanced research center for automobile R&D. By all the indicators of technical and economical evaluation this project overpassed the Renault millestones and the project leader's best expectations[8]. This successful team was due to the
452

ICED 01 -C586/400

In fact the Technocentre represents a summit of experts coordinated by Renault, by means of a pool of sponsors and permanent collaborators who believe that working together in tight networks is the only way to do the best job they can. The architecture of the Technocentre was conceived to permit people to work as they were playing together,e.g. acting as synchronically as possible. They are functionally placed in order to get easily all the information or collaborations needed in all phases of a new car project. Everything was planed to facilitate everyone's job and to increase overall efficiency. The three main blocks of this complex are sited in order to put the progressive phases of the development of a new vehicle side by side or in the same sequence they are suppose to follow to. So engineers, managers, technicians and highly skilled workers combine all their competencies working on researches, designers, product/process, quality, information etc. and purchase all the specialists needed for car development. The first building contains the advanced engineering and design units; the second one at the heart of the Center houses the project department and the project platform teams, surrounded by the Vehicle Engineering and the Research Department as well as the Purchasing Department; the third is the Prototype Building Center where a new product development ends by having the project specifications validated at manufacture level. Other facilities such as laboratories for materials certification and quality control are also part of this Research-Development and Engineering (R&D&E) complex. In a word, the Technocentre is a tool designed to aid research, as defined by Renault corporate communication in the special issue of Renault Magazine R&D. The same source states what we had already seen during the time we had been there: "The concept of this Center was Renault response to the key strategic challenge of reducing the development time for new vehicles to 36 months by 2000 and 24 moths subsequently, and ultimately saving at least 1 billion French Francs (150 million Euro) on the development costs of each new vehicle. The Technocentre is home to an 8500 strong workforce, including 2,000 non-Renault employees (partners and suppliers involved in project development)."[9] Even the shop-floor workers from Flins, the largest Renault production plant, came to Technocentre to work on the prototype and to assemble the first 30 cars at the mini plant they had installed there. In short, they participated in the assembly systems selection. Moreover, some of them went to the suppliers' industrial machine plants to be in touch with the new automated systems for welding and final assembly uses. The New Clio was launched simultaneously in three plants in Europe: Valladolid in Spain, Novo Mesto in ex-Yugoslav, and Flins in France, in October 1998 and one year later in Airton Senna plant in Sao Jose dos Pinhais near Curitiba in Brazil. It comes in 7 versions concerning the engine specifications and the fuel systems adopted: four gasoline versions (1.0 -only for Brazil- 1.2; 1.4; e 1.6) 8 V.; two diesel versions (1.6 16 V and a turbo-diesel direct injection); plus one electric version for urban uses. And this year, 2000, Renault is planning to have a new 1.0 16 V for Brazil market, which associates a 1.6 regular engine performance to a lower gasoline consumption. [14] Besides in Brazil Renault is also doing some high tech research on fuel cells in partnership with the Hydrogene Lab of COPPE/UFRJ since 1999. So the New Clio results are the best evidence of Renault's global innovation strategy that, coordinated by the designing activity, has been promoting an integration of R&D between auto makers and suppliers and also promotes new forms of flexibility for industrial innovation once for all. And even more than that we can say that this project is still alive. We mean that it

ICED 01 -C586/400

453

is still being improved in order to incorporate new advances in industrial process, engine systems and materials to meet new environmental requirements as well as to make it more performance and cost effective. While the discussion at the European Parliament to establish European Directive on end of life Vehicles was still taking place the New Clio was launched in October 2000 already conceived to be 95% recyclable. Table l:The New Clio in Numbers Compared to the old one

Investments:

Indicators

Results

Designing phase

3,3 billions of Francs

Industrialization phase

4,2 billions of Francs

Production Costs reduction

12%

Reduction of Industrial area in the plant

25%

Downsizing of the assembly line

19%

Reduction of time production (IMVP)

6 hours

Reduction of auto parts to be assembled

25%

Reduction of welding operations

20%

Reduction of the steps for the engine check in

37%

Reduction of fuel consumption

15%

Reduction of CO2 emissions

12%

Change rate: USS 1.00 = 6.00 FF Source: Medina 2000 [2]

These successful results were obtained by means of a new style of project management the so called the "plateau project" where all the groups in charge of each automobile systems worked together at the conception, design, prototyping and assembly line. Outside partners shared even the patents obtained as was the case of the Noryl 974 for the Clio wings. And as mentioned before, this project is still alive and is now being improved by an international group including Argentine, Turkish and Brazilian engineering teams that had joined the French team at Technocentre.

4

Concluding Remarks

Managing design for innovation was the main strategy adopted by the world car companies regarding all these requirements integrating activities such as R&D, design, prototyping and industrial production. Although different actors are affected to this context the coordination of internal and external partners is crucial to the success of the project. The best trajectory for keeping competitive market share is to work in simultaneous parternships for R&D, design, and engineering activities up to the industrial level. Working in network partners share risks and profits and also get more innovative solutions to reach the sustainability of the automobile for one more century.

454

ICED 01 - C586/400

This is surely a great opportunity for the less developed countries' automotive plants to get into design activities, which up to now have concerned only the headquarters bureau employees. Especially for Brazil we think that is important to get into new projects designing from the very beginning to participate at the materials selection as well as the research for innovative technical solutions. The only way we have to do so is to establish long term R&D partnerships with the carmakers, as Renault and COPPE/ UFRJ have been doing since 1999 concerning materials for fuel cells engines. References 1. Buchholz K., «The Hiden Design Advantage: Manufacturing Input» in Automotive Engineering. SAE, pp. 57-59, August, 1997. 2. Medina, H.,V., (2000), O proieto e a difusao de novos materiais na industria automobilistica. PhD. Thesis in Production Engineering at COPPE/UFRJ, fevereiro 2000. 3. Boujut J-F, Jeantet A., «Involving Suppliers in early product Development : a Challenge for the purchasing and engineering functions», Proc. ICED' 99, Munich August 24-26, 1999, pp. 1001-1006. 4. Bellgran M., and Aresu E., «Different Design Preconditions in Simultaneous Developement ofProducts and Production Systems, Proc. ICED' 99. Munich August 24-26, 1999, pp.325- 328. 5. MEDIA TECH, (1998) publication des ressources humaines editee par Renault, N 13, mai 1998 6. Clark K.B., Chew. W.B. and Fujimoto T., «Manufacturing for Design: Beyond the Dichotomy Production/R&D», in SUSMAN, G.I., (editor), Integrating Design and Manufacturing for Competitive Advantage. NY, USA, Oxford University Press, 1992. 7. Bragg R., «Materials Key to 100 Years of Automotive Progress», in Automotive Engineering. SAE, pp 93-99, dec. 1996. 8. SIA - Societe des Ingenieurs Automobile- "Le Technocentre an autout decisif pour lavenir Renault" site internet: http://www.sia.fr/actualites , 05/15/1999. 9. R&D The Road of Innovation, special issue, Magazine Renault of Research and Development, N 14, October 1999. 10. Birch S., «Design, development and globalization> in Automotive Engineering. July 1996, pp.8087. 11. Boyer R., Freyssenet, M., "The world that changed the machine: some conclusions; successful firms 1974 to 1992», in La Lettre du GERPISA. N° 117, nov. 1997, Paris. 12. Brindenbaugh P.R., "Strategically Integrated Partnerships for Materials and Auto producers", JOM Journal of Mining, pp 18-19, July, 1995. 13. Buchholz K., "Manufacturing, R&D Practices Vary Among Automakers", in Automotive Engineering. SAE, USA, October, 1996. 14. Buchholz K., <Simultaneous Engineering saves time and money», in Automotive Engineering. SAE, pp.97-99, November, 1996. 15. Freyssenet M., «Les transformations du travail en groupe chez Renault>, pp 185 a 197, em L'avenir du Travail en Chaine. sous la Direction de DURAND J-P; STEWART P., CASTILLO J. J., editions La Decouvert, Paris, 1998. 16. Freyssenet, M., Mair, A., Shumizu, K. and Volpato, G., "Conclusions : the Choice to be made in the Coming Decade" pp. 452-462, in FREYSSENET, M., MAIR, A., SHUMIZU, K. and VOLPATO, G., One Best Way ?. London, Oxford University Press, 1998. 17. lansiti M., «Real-World R&D: Jumping the Product Generation Gap». Harvard Business Review May-June 1993, USA. 18. Naveiro, R.M. and O'Grady, "A Concurrent Engineering Approach for Desing Assistence of Casting Parts", Proc. ICED' 95. pp.22-24, Praga, August. 19. R&D the Road of Innovation, (Jan.2000) Renault N 15 and (Jan.1999) Renault N° 8 e 11. 20. Sharif s. and PAWAR K.S., "Product design as a mean of integrating differention", Technovation. 16 (5), pp 255-264, printed by Elsevier Science Ltd. In Great Britain, 1996. 21. Shimokawa K., Juiirgens, U., Fujimoto, T., (1997) Transforming Automobile Assembly: Experience in Automation and Work Organization. Introduction, pp.1-16, Berlin, Springer Verlag.

ICED 01 -C586/400

455

Heloisa Medina ([email protected]) is Senior Researcher at CETEM and Ricardo Naveiro ([email protected]) is Professor of Product Design at Universidade Federal do Rio de Janeiro.

©With Authors 2001

456

ICED 01 -C586/400

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

RESEARCHING THE THINKING PROCESS IN DESIGN TEAMS - AN ANALYSIS OF TEAM COMMUNCIATION J Stempfle and P Badke-Schaub Keywords: Prescriptive models of the design process, thinking process, design teams

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 product development. A similar sequence is postulated for general problem solving processes in cognitive psychology [3]. Our research reveals, however, that the actual thinking process of design teams seldom matches the postulated step sequence. Despite the fact that the thinking process does not follow this postulated step sequence, regularities can nonetheless be observed that shed light on the "natural" thinking process of design teams. A two-processtheory of thinking in design is being proposed capable of explaining the thinking process we have observed empirically.

2

Theory

Team communication in design teams can be differentiated with regard to two communication focuses, content and process. With this differentiation we take into consideration that teams, in order to reach their objectives, do not only discuss the content of a given problem, but must also structure their own interaction process (for example, teams have to decide in what order subtasks are to be addressed). Content

Underlying Basic Thinking Operation

Process

Goal Clarification Exploration Solution Generation * Analysis

Planning ' Generation

1 Analysis

1 Evaluation *

- - - - - Comparison - -

1 Decision

Evaluation

1 Selection

Decision

+ Control *

Control

Figure 1. Steps in the design process and underlying basic thinking operations.

ICED 01 - C586/215

457

Social psychologists such as Morgan, Glickman, Woodward, Blaiwes and Salas [4] make a similar distinction when separating group activities in task-work and team-work activity. Under both of the two communication focuses of content and process a set of steps can be proposed. Each step is associated with one of four underlying basic thinking operations. Figure 1 depicts the steps in the design process and the underlying thinking operations. In the above model, we propose that content and process-related activity of design teams can be described in similar terms, with the same basic thinking operations underlying both process- and content-related activity. Concerning content, the above step sequence differentiates between actions focused on the goal space (goal clarification) and actions focused on the solution space (all of the remaining steps). Two of the four basic thinking operations proposed above, generation and exploration, are also stressed by creativity researchers Ward, Smith and Finke [5], who in their GENEPLORE model propose generative and explorative processes to be the main ingredients of creative activity. Both generation and exploration of ideas serve to enlarge the solution space. In order to work out a solution to a given problem, however, design teams must also carry out operations that serve to narrow the solution space. This narrowing of the solution space is done by comparing one or more solutions to each other and to the requirements of the task and by selecting the most viable option. The steps above are arranged in an intuitively compelling order that matches the step-models proposed in design methodology [1,2] and cognitive psychology [3]. We do not propose, however, that teams follow the steps proposed above in this fixed order, but expect teams to frequently interpolate between the different steps in various ways. The aim of this research is to investigate whether transitions between the steps are arbitrary, or whether systematic transitions can be found that frequently occur in design teams.

3

Research Methods

In this paper we present results from one field study and three laboratory studies. In the field study we have investigated a design process in a German automotive supplier. A team of four people working on a joint task has been observed over a period of six weeks. In the laboratory studies three student teams majoring in engineering have been presented with a complex design task that they were to solve in a one-day-period. The communication observed in the studies has been recorded and categorised by means of a multilevel coding system. The top two levels of the coding system correspond to the main communication focuses and the design steps that have been described above. Communication in the team has been analysed sequentially in order to investigate the underlying thinking processes of the team.

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 major communication focuses content and process.

458

ICED 01 - C586/215

Figure 2: Distribution of utterances among the two major communication.

In both, the field study and the laboratory studies, a similar distribution of utterances among the main categories results. This distribution can roughly be described by the "2/3-rule": In 2/3 of their communication design groups deal with the content whereas 1/3 of the group communication aims at structuring the group process. Similar results are reported from problem-solving groups in non-design contexts [6]. On the level of steps in the design process, the distribution of utterances among the steps is quite similar in the four groups as well, with a medium correlation between the distributions of .98 between the four groups. The following figure displays the average frequency of design steps in the four groups.

Figure 3: Distribution of utterances among the steps in the design process (average of all groups).

In the observed teams, most of the team communication is concerned with analysis of both, the content (42%) and the process (17%). The next frequent category is the evaluation of content (15%) and process (5%).

ICED 01 - C586/215

459

Regarding the pure frequencies of the communication categories, the observed design groups cannot be very much differentiated. On the other hand, differences in performance and style of the groups exist that apparently cannot be explained by the findings reported so far. The question that remains is how do groups go about in their design process? What are the similarities and the differences between groups?

4.2 Analysis of transitions between categories In order to conduct an analysis of the team design process, transitions between categories have been analysed. The question to be answered is: Is team communication "chaotic" in the sense that any sequence of categories is likely to appear or are there regularities, with one category systematically following after a specific other category? In order to answer this question, the transition probabilities between all of the categories have been calculated and then compared to the baselines of the categories. If, for example, content analysis occurs in 42% of all team communication, but after a content analysis in 65% of all cases another content analysis follows, this means that sequences of content analysis are highly likely to occur in team communication. The following figure displays transition probabilities between the two communication focuses content and process (average of all four groups). In the figure, a connection that ends with an arrow displays a transition that is significantly more likely to occur compared to the base rate (as calculated by a Chi2-test). A connection that ends with a straight line displays a transition that is significantly less likely to occur compared to the base rate. The first number behind the connection is the transition probability, the second number is the base rate probability:

Figure 4: Transition probabilities between the two major communication focuses (average of all four groups).

The transition probabilities displayed in the figure are significant for all four studies. In all four studies, transitions within the same communication focus are highly likely to occur whereas transitions between the two communication focuses are highly unlikely to occur. On average, teams spend 6.3 utterances on content-related communication before switching to process-related communication, whereas sequences of process-related communication have an average duration of 3.2 utterances before the group switches to content-related communication. These findings reveal that the design process in teams is best described by a constant interweaving of content-directed sequences with process-directed sequences, both of some - but different - duration.

460

ICED 01 - C586/215

In the following analysis of transitions between the design steps, we focus on content-related utterances only. For the calculation of transition probabilities, the four studies have not been "averaged", but instead the results of all four studies have been calculated separately in order to ensure that the results are not solely an artefact of data aggregation. The following figure displays transitions between the design steps in the four studies that are significantly more probable than expected given their respective baseline.

Figure 5: Transitions between design steps.

One interesting result is that for every design step except the step 'decision', a transition within the same step is highly likely to occur. The proposed design steps thus seem to be steps indeed in the sense that groups tend to spend more than one utterance on the same step before moving on to the next step. In the three laboratory studies, a feedback loop evolves consisting of analysis and evaluation, in the field study a feedback loop between solution generation and evaluation. The repeated interplay of analysis and evaluation thus seems to be at the core of the collective thinking process in the laboratory groups. While analysis enables the teams to widen the solution space, evaluation serves to narrow it down again. The constant interpolation of analysis and evaluation might enable the groups to keep the size of the solution space at an acceptable level.Of special importance is the fate of solution ideas. When a new solution idea is being proposed, the team's immediate reaction often decides on the acceptance or the rejection of the idea. Regarded from a methodological perspective, one would expect new ideas to be followed by a thorough analysis. What one would not expect is an immediate evaluation. In fact, creativity techniques such as brainstorming [7] explicitly prevent groups from premature evaluation. Our results show, however, that groups frequently do not follow such recommendations, but do evaluate solutions immediately without prior analysis. In three of four observed groups, a new idea is highly likely to be followed by an immediate evaluation without prior analysis. Only two (because the lab group 3 shows both loops) of four observed groups frequently progress from solution generation to analysis. From a theoretical viewpoint, an immediate evaluation of a solution idea without prior analysis must be regarded as problematic. Two errors are likely to occur. One is premature rejection of a solution because it does not seem to fit the constraints of the task structure. Oftentimes, however, a solution that does not fit at first sight can be transformed in order to produce a fit with some effort. Indeed, most creative solutions are not intuitively compelling

ICED 01 - C586/215

461

at first sight, but must undergo several transformations before their usefulness becomes obvious. A second error that is likely to result from a premature evaluation of solution ideas is the premature adoption of a solution that proves problematic later on. A complex design task is comprised of many different requirements and constraints, often too many for people to keep in mind. Thus, a crucial constraint may be forgotten, with a false positive evaluation of a solution idea resulting. Both errors are grave. In the first case of premature rejection of a solution idea, an ingenious idea may be discarded and lost for the group. In the second case of premature adoption of a problematic solution idea, groups may spend considerable time working out a solution only to find out later on that the solution does not work. Given the proposed negative effects of premature evaluation of solution ideas, how can we explain the proceedings of the three of four observed groups?

5

A second look at the step-by-step-paradigm: A two-processtheory of thinking in design

We do, in fact, propose that the observed sequence of solution ideas being followed by immediate evaluation is not simply an error committed by some teams, but that this process represents the "natural" thinking process teams adopt by default. We will thus call the sequence of solution generation - evaluation process 1. As a reason for this proceeding of teams, Ehrlenspiel's [9] construct of "cognitive economy" can be cited. Decision researchers [see e.g. 9] have long shown that when faced with decision tasks of various kinds, humans do not strive to find the best of all possible solutions, but rather strive to find a workable solution with minimum effort. In a first, quick screening process, the number of possible alternatives is thus immediately reduced to a few remaining options. In the same manner, the premature evaluation of solutions in design teams may serve to a priori limit the solution space to a handful of promising alternatives. This behaviour can thus be explained by the tendency of teams to spend minimal cognitive effort on the problem. We do not propose that teams strive for cognitive economy consciously. A limited memory capacity and the fact that our conscious thinking works in a serial, not in a parallel mode, forces us to reduce problems to small chunks and to limit the number of options we consider. In problem spaces of little or moderate complexity, process 1 will frequently be quite successful. In problem spaces of high complexity that require numerous transformations before a solution can be adopted, however, process 1 is likely to fail oftentimes. Nonetheless, in two of the observed teams (lab group 3 realised both processes) a proceeding different from process 1 has been observed. In these teams, solution ideas were frequently followed by analysis before an evaluation took place. We will call the sequence of solution generation - analysis process 2. Out of four observed teams, two teams frequently employed process 2 (lab study 2 and 3). The performance of these two teams has been rated substantially higher by independent design experts, who had no knowledge of the hypothesis presented in the paper, than the performance of the two teams who primarily employed process 1 (field study 1 and lab study 1). Process 2 violates the principle of cognitive economy, since teams using process 2 will most likely spend time on the analysis of solution ideas that are later on being discarded. If this is the case, why do some teams still adopt process 2 at least some of the time? We believe that several factors may cause teams to switch from process 1 to process 2.

462

ICED 01 - C586/215

Failure of process 1: Once a team has discarded a considerable number of solution ideas without coming up with a workable solution, the team may be forced to re-analyse the solutions that have already been discarded for the lack of alternative solution ideas, thus switching from process 1 to process 2. Beach [9] has observed a similar process in decisionmaking tasks, with subjects conducting a second screening process with a relaxation in the constraints if the first screening failed to produce an acceptable alternative. The lack of new solution ideas may thus lead to a re-analysis of already existing ideas. Disagreement and challenging of ideas: As has been observed in one of the observed groups, disagreement and the challenging of ideas can lead to a careful analysis of solutions. In one of the groups one team member frequently contested solution ideas that others had already accepted. This stance of challenging lead to a careful re-analysis of the solution idea, oftentimes with new and important insights evolving. In the same manner, the same group member kept uttering one solution idea repeatedly although the team had already decided to drop the idea. After the fifth re-analysis of the solution idea, however, the idea was finally accepted by the team. Disagreement thus seems to enhance analysis, a result that is already implemented in the well-known method named the devil's advocate. Adoption of a methodology: In the four teams we have observed, only one team (lab study 2) tried to structure the design process by use of a methodology. This team actively used creativity techniques such as brainwriting, thus consciously separating the processes of solution generation, analysis and evaluation. This approach enabled the team to avoid premature judgements. Many creativity techniques suggest suspending judgement, thus allowing oneself to explore even "off-the-wall"-ideas. The use of such techniques may help to transgress from process 1 to process 2. Self-reflection: We agree with Schon [10] in stating that self-reflection is the key to successful design for both individuals and teams. Self-reflection may lead teams to consciously realise that they are stuck in a process-1-approach. From this point, teams can alter their proceeding. We do not agree with Schbn, however, in that individuals and teams do self-reflection by themselves. Speaking about the teams we have observed so far, we have not yet met a single "reflective practitioner". On the contrary, genuine self-reflection occurred very rarely in the teams we have observed. The teams seemed to be rather reluctant to criticise their own actions and thinking. This may be caused by the fact that if a group member criticises the team's approach, this may be perceived by others as a threat to the team as a whole. In the few instances where we have observed such criticism in the observed teams, the reactions of the team have been unfavourable. We therefor conclude that if self-reflection is to occur in teams, it must be actively encouraged.

6

Conclusions

The results and interpretations presented in this paper have important implications for the education and training of designers. While we agree with Schon [10] that conventional design methodology [1,2] with its strongly scientific approach is counterintuitive to many practitioners and therefore difficult to employ in practice, we are convicted that sole reliance on the natural "artistry" of designers will produce errors that can be prevented. Our research reveals a tendency in design teams to spend minimal cognitive effort on the design task. Solution ideas are often quickly being evaluated without careful analysis, a premature narrowing of the solution space seems to be a common phenomenon. We have

ICED 01 - C586/215

463

called this proceeding process 1. While process 1 may be effective for the resolution of simple tasks, it will create problems when dealing with tasks of high complexity. For such tasks process 1 should be replaced by process 2. Solution ideas should be analysed carefully before evaluation takes place. In order to achieve this end, we suggest educating design teams in the active and conscious use of self-reflection and in a new way of using design methodology. Teams should not use any methodology "by the book", but should be capable of flexibly using any method or technique suitable to their momentary needs. What we observe is that it is not knowledge that is lacking, but competence. This competence can best be perceived as "meta-knowledge", the knowledge about how to use what you know. Self-reflection and meta-knowledge should become prime objectives in the future education and training of design teams as it is elaborated for the critical-situation approach by Badke-Schaub [11]. References: [1]

Pahl, G. and Beitz, W. "Engineering design". London, Springer, 1984, 1995.

[2]

VDI Design Handbook 2221, "Systematic Approach to the Design of Technical Systems 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 in Gruppen" [A method for the analysis of interaction processes in problem-solving groups], Gnippendvnamik. 25, 1994, pp. 149-168.

[7]

Osborn, A. F., "Applied Imagination - Principles and Procedures of Creative Thinking". 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, San Diego, Academic Press, 1993.

[9]

Ehrlenspiel, K., "Practicians - How they are designing? .. and Why?" Proceedings of the ICED '99. Miinchen, 1999, Vol. 2, pp.721-726.

[10] Schon, D. A., "The Reflective Practitioner: How Professionals Think in Action". New York, Basic Books, 1983. [11] Badke-Schaub, P., "Group effectiveness in design practice: Analysis and training by a critical-situation-approach", Psvchologische Beitrage. 41, 2000, pp. 338-355. Dipl.-Psych. J. Stempfle Dr. P. Badke-Schaub University Bamberg, Institute of Theoretical Psychology, Markusplatz 3, D- 96045 Bamberg, Germany, Tel.: ++49 (0)951 8631864, Fax: ++49 (0)951 601511, e-mail: [email protected] ©J Stempfle 2001

464

ICED 01 - C586/215

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

TOWARDS A SCIENCE OF ENGINEERING DESIGN TEAMS A Mabogunje, K Carrizosa, S Sheppard, and L Leifer

Keywords: Design Teams, brain imaging, video observation, computer simulation

1

BACKGROUND AND OBJECTIVES

The last few years have witnessed a renewed interest in various typologies to classify the dominant or preferred behaviors (cognitive and social) of engineering designers during the product development process. See for example research on p-designers (high experience and little or no training in formal design methodology) and m-designers (low experience with training in formal design methodology) conducted by Gunther et al [1]; research on the relationship of individual styles of problem solving to representations in the design process by Eisentraut et al [2]; research on the relationship between the diversity in the personality of team members and design performance by Wilde [3]; study of how individual particulars such as theoretical education and demand for quality affect the outcomes of critical situations in industry by Frankenberger et al [4]; behavioral and electrophysiological study of effect of experience (novice vs. expert) on design problem solving by Goker [5]. Coincidentally, this renewed interest comes at a time when new technologies, which increase our capacity to observe designers in action, have become widely available. Among the new technologies that have come into recent use by researchers are the video camera, the functional magnetic resonance image scanner, and the computer. Furthermore our ability to process the observed data has also improved, such that we can better determine the relevance and predictive accuracy of these typologies. These improvements in the instrumentability of design teams suggests that in future we will be able to build better models of the workings of design teams and formulate hypothesis which can be readily tested and validated. This paper is conjectural and represents an attempt to plan future research by building on past empirical work in the context of modem tools. Today we compose teams primarily based on the background experience in a given field of knowledge and the task requirement. For example we may compose a team consisting of two electronics engineers and one mechanical engineer. This kind of composition, based on domain knowledge, in addition to other structural factors like the organizational arrangement, communication tools, and computer tools is analogous to the "physics" of teams. On the other hand a composition that considers the cognitive style of the individual members, their temperament, their response to stressful situations, and the pattern of interaction with other team members is analogous to one based on the "chemistry" of teams. The objective of this paper is to explore a future scenario in which such a science can be applied to real world situations. A priori this exploration will be based on three key ideas. First is to select a commonly observable design phenomenon. We believe this will keep us grounded in design practice and help in prioritizing our research questions. Second is to build on the "observeanalyze-intervene" research methodology [6]. This methodology is a form of action research that emphasizes intervention as an important way of understanding complex systems. The

ICED 01 - C586/477

465

third idea is to use computer simulations as an integrating tool in our work. We intend to draw on the results of empirical studies we have done and other related studies in coming up with testable hypothesis. Based on our previous work [7,8] we were struck by the high number of concepts and variables that need to be considered by researchers when studying design teams. Computers give us the ability to externalize our evolving understanding of design teams into symbolic models, which can then be easily shared and manipulated. We believe this approach will make it much easier to consolidate our findings and develop our understanding. In the rest of the paper we elaborate on each of these ideas using concrete examples. We will then conclude by reflecting how such a science of design teams as we propose could be applied to future design scenarios.

2

Classic design problem: "Requirements Deviation"

Our first idea is to choose a commonly observable design phenomenon. We believe this strategy will appeal to practicing engineers and thus make it easier for us to find subjects within this population. Furthermore we believe that grounding our theories in practice will give us an important criteria for prioritizing our research questions. Figure 1 illustrates a common problem we believe most designers are familiar with. This is a problem in which over the course of time the request of the client becomes transformed into an artifact that fails to meet the client's needs.

What the client requested Day 1

What marketing thought the client requested Day 10

What engineering thought marketing said the client requested Day 15

What production manufactured for the client Day 30

Figure 1. An illustration of the requirements deviation problem

We believe a science of design teams will enable us to estimate the likelihood of this deviation or "creep" from the original intent. In other words we would like to make predictions of the form described below: When a design team D with properties Dl, D2,... working in an environment E with properties El, E2, ... in a market M with properties Ml, M2, ... is assigned a design problem P with properties PI, P2, ... in time T with properties Tl, T2, ... the result will be 0 with properties Ql, Q2 ... As seen above, there is a high number of variables necessary to make any good predictions about the performance of design teams. We believe our research approach using a combination of multiple observation methods and simulation-based analysis is the necessary and sufficient situation to address such a complex issue. We will elaborate on the specific elements of this approach in the next two sections.

466

ICED 01 - C586/477

3

Research Methodology

The "observe-analyze-intervene" method is an iterative approach to research that emphasizes the development of interventions as a way to perturb a system and test underlying assumptions. Illustrated in figure 2, the method begins with the observation phase whereby a real world phenomenon is observed and recorded. In the next phase, the data collected is analyzed and interpreted. This interpretation is then used in the third phase to inform the design of new tools and methods that will impact the behavior observed in the initial real world situation.

Figure 2. The Observe-Analyze-Intervene methodology, through its intervention step allows a complex system to be perturbed and reveal hidden assumptions.

The cycle is then repeated in such a way as to deepen one's understanding of the real world phenomenon and, refine or change the tools and methods that were earlier introduced. The method has been very useful to us in the design of computer and communication tools to support design work and we believe it offers a practical way to develop a science of design teams. As we discussed and thought about the new technologies mentioned earlier (video camera, functional magnetic resonance scanner, and computer simulation) we realized that essentially all three, in addition to the more traditional social science tools of interviews and surveys, allowed us to access the design process from different perspectives and each had its limitations. For example video/audio recordings were useful for observing external actions and audible utterances, but were of limited use when it came to knowing anything about the nature of the designer's thought process. Brain imaging would allow observation of the internal cognitive activity of the designer but tell us nothing about the designer's beliefs, motivations, and attitude. Interviews and questionnaires will allow us to leam more about a designer's beliefs, motivations, and attitude, but nothing about what the designer actually does in practice. We shall now describe each of the three primary observation methods in turn using illustrative examples from empirical work.

3.1 Video Observations Effective communication between engineering design team members is essential for high performance in product development. In turn effective communication depends on successful transfer (sending, receiving and processing) of information. This information may range from data and facts to creative ideas. Previous work by Felder and Silverman has shown that individuals differ from one another in how they prefer to receive and process information [9]. They referred to these preferences as learning styles, and developed a set of five dimensions, each consisting of a pair of poles (shown in parenthesis), that could be used to describe individual preferences. We believe these dimensions namely Perception (sensing, intuition); Information Reception (visual, verbal); Information Processing (active, reflective); Information Sequencing (sequential, global) and Information Organization (inductive,

ICED 01 - C586/477

467

deductive) will be of particular importance to understanding communication difficulties in design teams. Figure 3a shows a sample profile for an individual in the information reception dimension.

Figure 3. a) A sample profile of an individual with a moderate preference to receive information visually, b) Team learning style distributions. Team 1 was formed such that its members, on the average, strongly preferred to receive information visually. Team 2 had a moderate preference to learn visually. Both Team 3 and Team 4 had a mild preference to receive information visually.

In a recent study we looked at the relationship between individuals' preference for receiving information and their methods of sending information. It was initially anticipated that each individual's mode of presenting information would match his or her preferred mode of receiving information, and that this match would result in improved communication. To study the congruency (or incongruency) of how individuals prefer to receive information and how they go about sending information an experiment was designed and conducted. The experiment consisted of four teams of engineering educators engaged in a design exercise which was videotaped. Their information reception preferences are shown in Figure 3b. Results based on analysis of the video tapes and individual Learning Styles Inventories showed that most participants preferred to receive information visually and engaged in drawing very little during the design exercise. If the definition of "visual communication" was expanded to include using drawings, communicative gesturing (i.e., using hand gestures to describe a physical object or action), using hardware, and referencing hardware, visual communication went from comprising an average of 3.8% of the design time to an average of 21.1% of the design time. This means that a large majority of the communication was mismatched with the preferences of the receivers [8].

3.2 Interviews and Questionnaires Since there is only so much we can learn from externally observable events, the use of interviews and questionnaires to complement our video-based observation is imperative. From the types of data that could be gathered through these methods we can learn more about individual attitudes and beliefs. Not only will this be important in explaining behaviors we observe, it could also lead to new ways for understanding design.

3.3 Brain Imaging There are several techniques to image the brain, and two of the primary constraints have been the degree of resolution (2D versus 3D) and the invasiveness of the technique. Goker, M. at Darmstadt University for example conducted an electroencephalography study to compare brain activity of novice and expert designers while they were solving simple design problems, Goker [5]. A major breakthrough came with the development of the functional magnetic resonance imaging (fMRI) technique, which is non-invasive and has high 3D resolution. FMRI is based on two key ideas: 1) during brain activation the oxygen content of venous blood increases in the region of activation; 2) when a human is placed within a magnetic

468

ICED 01 - C586/477

resonance field, the increased blood flow causes an increase in magnetic resonance signal intensity. The resulting techniques of brain imaging essentially allow us to explore structure-function relationships in the brain i.e. how activities in distinct neural processing come together to perform complex tasks such as reasoning, reading, remembering, and visualizing. In recent years, a number of physiological studies, which have shown strong implications for design performance, have been reported in the literature. In a more recent study at the Stanford Cognitive Neuroscience Laboratory, the researchers were able to identify specific brain activities that differentiated between visual experiences, or images, that were later remembered well, remembered less well, or forgotten (Brewer et al. [10]). As an illustration, this latter finding can be adapted to the requirements creep problem by assuming the subjects are representatives of the marketing department. Consider therefore the situation in which we recorded the brain activity of the subjects during the design exercise, where they are generating and refining a space of images that describe a potential solution to the design problem, and a week later, we have them describe this space of images to another set of participants representing the engineering department. Brewster et al's work should potentially enable us to know the strength of the memory of the images for each marketing representative. Conceptually then, this will enable us to predict which representatives will have a higher probability of relaying incorrect information.

4

Computer Simulation

We see from the foregoing that the number of variables that would be required in a science of design teams could be very large. We would definitely make simplifying assumptions but even when we do this, we still need to keep track of the variables we eliminate, and the rationale for each assumption. In earlier work, we used a computer simulation program named virtual design team (VDT) to model and simulate the project performance of an engineering organization [11]. While VDT was not specifically written to study small size design teams, we believe it can be conceptually adapted for this purpose. In order to understand our adaptation we will review a few of the basics of VDT.

4.1 The virtual design team (VDT) In general, the conceptual model in VDT seeks to explain how actor variables, task variables and organizational variables affect the duration and quality of an engineering project. Actor variables include elements such as the skill of the actor with respect to a particular task, her preferences for using certain communication devices during task execution and her position within the organizational hierarchy. Task variables include a description of the level of complexity of a task and the degree of uncertainty associated with the task activity. Organizational variables include such variables as the structure and communication policy. The relationship among these variables is based on a combination of Galbraith's theory of information processing in firms [12] and heuristics for estimating the duration of tasks and quality of decision making during the execution of a project. These heuristics focus on the process by which the first line actor handles exceptions. In general, there are three options: doing nothing (default delegation), reporting to a colleague (lateral communication) or reporting to a supervisor (vertical communication). In communicating with the colleague or supervisor, a further choice is made with respect to the communication medium to use, memo, fax, telephone, e-mail, or face-to-face meeting. These choices are constrained by certain

ICED 01 - C586/477

469

factors and have consequences. They are constrained by the organizational structure and the communication policy within the organization. The consequences relate to how the choices affect other members of the organization and ultimately the total time to execute a given task. In a short form, the total time to complete a task T is the sum of: 1) The nominal time (time it will take an average actor uninterrupted) 2) The communication time (when an exception occurs this is the time interval between sending a message to one's supervisor or colleague and getting a reply) 3) The rework time (if there is a problem, this is the time it takes to fix it). In addition VDT predicts the project quality based on the number of unanswered communications and number of uncompleted rework. When these numbers are high, quality of work is judged to be poor. For our purposes, we define a product development process as a series of team meetings inter-spaced with individual work and in the next section we will describe a hypothetical situation in which we combine our three observation methods to estimate the likelihood of the deviation in the requirements creep problem.

4.2 Image Communication Model Consider the different possible variables in a simple communicative transaction in which a person A wants to communicate an image to a person B. The send mode could be words, gestures, or sketches; the receiver may be inattentive, half attentive, or fully attentive; the image invoked in the receiver's mind could be the same as the senders, very different, or the receiver may draw a blank; the receiver may decide to verify correct reception or not, etcetera. We have illustrated this in the model shown in Figure 4. Assuming that each of the variables has an attribute of quality, we can proceed to explore how quality can be measured in each case. Transmission, verification, and confirmation quality could be determined by comparing the input image with the output image. Alignment is found by comparing the mode in which the information is sent by person A with the preferences for reception of person B. For example, reception preferences lie along the continuum from visual to verbal. Send modes are speech, sketches, communicative gestures, using hardware as a simile, referencing sketches, and metaphoric speech or some combination of two or more of these modes which can be classified along a continuum from visual to verbal. Based on this model we expect to be able to estimate the accuracy of the image being communicated using a factor that is the product of the qualities of transmission, attention, reception, alignment, verification, and confirmation. Using the same model we can also estimate the time it takes to communicate an image as the modified sum of the transmission the reception time, the verification time and the confirmation time. We expect individuals will differ in terms of their likelihood not only to expend time in these areas but also to iterate through the process until confirmation is achieved. Armed with these estimates we can for example estimate the number of meetings it would take for a given team to successfully communicate a given set of images. We can similarly estimate the failure rate we can expect given their likely behaviors as observed from their interview and questionnaire data, brain scan recording and video recording, thus predicting the likelihood of the team to deviate from the client requirements. Figure 5 shows how computer simulation can be used in the analysis phase of our work and in so doing complement our observation methods and lead to more informed interventions.

470

ICED 01 -C586/477

PERSON A

PERSON B

Figure 4. Model of a simple communicative transaction in which person A attempts to communicate an image to person B. The basic steps are: transmission-alignment-reception-verification-confirmation.

Figure 5. Video observation, brain imaging, and surveys provide three perspectives for observing the design activities. Computer simulation provides a way to analyze the data, develop a better understanding of the interactions, and make more informed decisions about interventions.

5

Summary

As we mentioned in the beginning, our aim was to make a sketch of future research by building on past empirical work in the context of modern tools. In so doing we have described a scenario whereby the improvements and availability of better tools to observe the workings of design teams will lead to an increase in the accuracy and reliability of our models of design and hence our predictions of design performance. Working from first principles, such a science of design teams will not only enable us to develop new strategies for managing design teams it will also make it possible to develop better environments to support the process. In this future, it appears to us that the quality of the outcome will be judged by both process and product variables - that is both the quality of the final product and the design team's subjective experience of the process, including the quality of their communication.

ICED 01 - C586/477

471

References [1]

Gunther, J., Ehrlenspiel, K., "How do Designers from Practice Design? What can Design Methodology Leam from Them? How can Design methodology Support Them?," in Designers - The Key to Successful Product Development, Frankenberger, E., Badke-Schaub, P., Birkhofer, H., (eds), Springer-Verlag, 1998.

[2]

Eisentraut, R., Gunther, J., "Individual Styles of Problem Solving and their Relation to Representations in the Design Process," Design Studies 18, pp 369-383, 1997.

[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 proceedings of the International conference on Engineering Design, Tampere, Finland, August 1921, 1997.

[5]

Goker, M.H., The Effects of Experience during Design Problem Solving," Design Studies 18, pp 405-426, 1997.

[6]

Tang, J., Leifer, L.J., An Observational Methodology for Studying Group Design Activity, Research in Engineering Design, v2, pp. 209-219, 1991.

[7]

Leifer, L.J., Design Team Performance: Metrics and the Impact of Technology, in Evaluating Organizational Training, Brown, S.M., and Seider, C., (eds), Kluwer Academic Publishers, Netherlands, 1998.

[8]

Carrizosa, K., and Sheppard, S., "The Importance of Learning Styles in Group Design Work." Proceedings, Annual Frontiers in Education Conference. ASEE/IEEE, Kansas City, T2B 12-17, 2000.

[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., "Making Memories: Brain Activity that Predicts How Well Visual Experience Will Be Remembered," Science 281, 5380, pp 1185, 1998. [11] Mabogunje, A., Leifer, L.J., Levitt, R.E., and Baudin, C., "ME210-VDT: A Managerial Framework for Improving Design Process Performance", Frontiers in Education Conference, Atlanta, Georgia, 1995. [12] Galbraith, J.R., Organization Design: An Information Processing View, Interfaces,4,2836,1974 First authors name: Ade Mabogunje Institution/University: Stanford University Department: Center for Design Research, Department of Mechanical Engineering Address: 560 Panama Street, Stanford, California 94305-2232 Country: USA Phone: 1-650-725-0150, Fax: 1-650-725-8475, E-mail: [email protected] © IMechE 2001

472

ICED01-C586/477

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

DIMENSIONS OF COMMUNICATION IN DESIGN C M Eckert and M K Stacey

Keywords: Design teams, collaborative design tools, computer supported cooperative work, design information management, taxonomies, ethnography.

1 Introduction In industry designers interact and collaborate with each other in many different ways, often on the same day. Many of these different types of interaction can be supported effectively with computer tools - but a tool must meet the needs of the situation it is used in. However research on collaborative designing and on design groupware often focuses exclusively on one interaction paradigm. This paper explores the variety of interaction in design by developing a set of dimensions for classifying design scenarios. It discusses a number of important interaction scenarios we have observed in our studies of design practice, and their implications for the development of computer support tools.

2 The Problem The term design covers a large number of different activities. Designing as a mental process is the generation of a description of a new product, through a repeated cycle of reformulating the problem, synthesising a potential solution, evaluating it, and reformulating the problem again. However, design in its broader cultural sense includes all activities involved in the generation of a complex product. Many of these activities do not contribute directly to generating the product description, but instead to establishing the requirements it must meet or testing its properties. At present there is no complete taxonomy of different design tasks. Frost [1] provides a useful classification of design products, which can be used to assess characteristics of their design processes. While there are many attempts made to describe engineering design in general in taxonomic form [for instance 2], detailed taxonomies address only particular issues. For instance Ullman [3] classifies decision problems in design; and Kaplan et al. [4] are concerned with the information requirements of tasks requiring interaction between designers. In contrast to Kaplan et al. [4], we are looking at communication activities within large design processes, where the mode of collaboration is not necessarily predetermined by the task rather than by the organisational set-up. Medland [5] classifies communication activities into four types: delegation, reporting, awareness, and problem handling (for resolving conflicts between design elements or constraints).

3 Research on Design Communication How designers communicate, and how designers could communicate, has been studied from a variety of different angles and intellectual perspectives. But discussions of collaborative

ICED 01 - C586/518

473

designing usually consider only a handful of activities; and support systems for cooperative design are developed for specific scenarios, when consideration of a wider range of uses could reveal a broader range of requirements and potential pitfalls.

3.1 Groupware for Engineering Design A variety of computer technologies enable designers to collaborate effectively across long distances or when involved in large projects. Information management systems that support communication through record-keeping are one important strand of development, especially important in applying methodologies such as SSADM to software development. Other developments include systems for enabling participants in face-to-face meetings to share software and computer representations of information; and support for transmitting a variety of material including video messages through time and space to colleagues working separately, to replicate for message passing the resources available in meetings [6]. There has been extensive research on computer support for collaborative designing by remote designers using shared workspaces simultaneously. Systems are in commercial use that support video-conferencing, and working collaboratively on shared CAD models across the Atlantic. Successful research systems have provided a face-view video channel as well as voice, and allowed remote users to share sketches [for instance 7], and also desktop views and near-screen hand gestures. Research on shared workspace systems has both driven and been driven by experimental and observational studies of design meetings [notably 8, 9, 10].

3.2 Studies of Communication in Collaborative Designing Research on design collaboration has largely focused on team meetings. Many studies have given a group a design brief and analysed the resulting design activities [see 11 for twenty detailed analyses of the same episode of collaborative design by various different researchers]. Design conversations almost always employ sketches, drawings, prototypes or other visual referents (but these can sometimes be imagined [12]). Communication in joint designing is multi-modal: speech, drawing and gestures are used in combination, with each channel used to explicate and disambiguate what is expressed in the others [8, 9, 10]. This multi-modal communication involves the use of argumentation strategies and rhetoric [10, 13, 14, 15], and subtle modulation of the degree of commitment with which a proposal is put forward [10, 15]. Minneman [10] points out that describing the design itself is just one aspect of design discourse. He classifies the content of design communication according to a 3-by-3 matrix: Communication can be about an artefact, or a process, or a relation (between individuals or groups, or between people and tools, rules, representations etc). It can describe the state (that something is now in), or how and why something got to be the way it is (making sense), or how something might or should develop (framing the future). There has been extensive research on how using computer technology influences how people interact in meetings. One important finding is that people will exploit ways to communicate that don't exist in conventional face-to-face interactions. For instance by drawing or gesturing in the same place at the same time in a virtual workspace [7]. Another is that using group support systems influences what happens in meetings, but how they change what happens depends on both the technology and the purpose of the meeting; for instance decision-making is different from idea generation [see 16]. Minneman [10], Bucciarelli [13] and Henderson [14], among others, have studied large-scale engineering processes as participant observers. They report that complex designs are

474

ICED 01 - C586/518

developed largely through social processes of argumentation and negotiation. They view designs as arising through a process of negotiation between participants, where information is activity communicated and actively made sense of, rather than seeing it as passively flowing through an organisation. However this view downplays the role of designers working on their own and needing to communicate actively to pass on the results of their work. Henderson [14] shows that graphic representations play a critical role in structuring the design process and conveying information between people with different knowledge and responsibilities. Designers' learned representation-specific interpretation skills determine how and how much they understand - representations mean different things to people with different expertise.

3.3 Our Research on Design Communication Between 1992 and 1997 we carried out an ethnographic study of design processes in over 25 knitwear companies in Britain, Germany and Italy, which was originally intended as a requirements analysis for an intelligent design support system. This found that the communication between knitwear designers and knitting machine technicians was a major bottleneck, and identified a variety of factors contributing to communication breakdown [17]. The most important were the difficulty of expressing designs clearly and unambiguously in the available representations, and failure to recognise communication problems. These findings have informed our studies of engineering design. In 1999 we interviewed 23 experienced designers and design managers in a study of the customisation process in helicopter design [18]. In 2000 we conducted a series of interviews in an automotive company studying design planning. Communication was not the primary target in any of these studies, but the aspects of design we studied depended on communication. While knitwear design is far less complex than engineering, with smaller teams and a much simpler product, it exhibits many of the characteristics of engineering design [17]. In knitwear design we could observe all aspects of the design process and see people communicating in different situations. It was only possible to talk to a small fraction of the participants in the engineering processes, who were all specialists in their fields. None communicated with colleagues in as many different situations as did the knitwear designers. In all the organisations we studied designers did some joint problem solving with other designers. For example all the knitwear designers in a company jointly work out a colour scheme for each season. But they develop conceptual designs for garments independently, and hand them over to technicians in the form of inaccurate, incomplete and inconsistent specifications; they only negotiate over the design when the technicians perceive that they cannot interpret the specifications accurately [17]. In the engineering companies we have studied, designs are handed over to colleagues with different technical expertise. The handovers are discussed in formal meetings, but often only by the bosses of the people doing the designing; if people knew each other, conflicts were sometimes resolved through local negotiation, but communication across organisational fields was always problematic [see 19]. What aspects of design the researcher studies is not independent of how a design process works. What gets done individually and what is done in meetings depends on the particular problem, but also on the structure and culture of the organisation. In large organisations and complex products, the complexity of the process inevitably leads to more handovers and information transmission between people who don't know each other. We have studied design cultures in which passing on specifications and other asynchronous communication is important. Had we looked solely at communication or at processes where the major participants design together in meetings, our study would have used methods more similar to the sociological studies mentioned above and come up with more similar findings.

ICED 01 - C586/518

475

4 Dimensions of Communication Situations The situations in which designers interact vary in a large number of ways. The dimensions of variation we list below are not orthogonal: common situations have related values along a number of the dimensions. These different situations can create different types of communication breakdown; they influence how designers behave and what they need in the way of computer support for their collaborative activities. Form of Communication o Place: Participants are face-to-face vs participants are geographically remote. o Time: Communication is interactive in real time vs communication is asynchronous. o Size: Interaction between pair - interaction between many. o Identity: Recipients are known (conversation, private notes) - recipients are unknown (record keeping, subcontractors to be found, open audience). Form of Task o Objective of task: Generation of ideas or alternative solutions vs convergent problem solving vs decision making from alternatives vs acquisition or imparting of pre-existing information. o Division of decision-making: Joint problem solving - negotiated handover - sequential problem solving. o Hierarchy of decisions: Different participants' tasks are of equal importance - some tasks are subordinate to others. o Duration: Interactive or communicative activity is brief - activity is extended. o Information type: Facts, proposals, specifications vs opinions or judgements or prognoses vs problem-solving strategy advice (see section 3.2). o Time pressure: Task is time critical - task is not urgent. Subject Expertise o Equality of expertise: Participants have equal levels of expertise - Some participants are more knowledgeable than others. (One important interaction type is apprentice consults more experienced colleague.) o Balance of Expertise: Participants have shared expertise (and use the same concepts and can interpret each other's terms and representations) - participants have complementary expertise. o Mental representations: Participants conceptualise topic in similar terms - different terms. o Familiarity: Participants know each other - participants cannot make assumptions about others' knowledge. o Context: Participants share contextual information - participants have different (or no) knowledge of the context. Tool Expertise o Competence with groupware: Experienced frequent user (skilled and comfortable with using the medium) - novice or infrequent participant. Organisation o Hierarchy: Participants at same level of hierarchy - participants have different status. o Interest: Participants inside same company - participants working for different companies.

476

ICED 01 -C586/518

o Security: All information can be shared - some information must not be shared (for instance in dealings with suppliers, or with people without security clearance). Representation of information o Medium: Speech, gestures, hand drawn sketches, hardcopy printouts of text files or CAD models, web pages, shared files, physical objects such as prototypes... o Form of information: Text, data plots, tables, diagrams, code, photographs. . . o Notation: Some fields have alternative notational conventions for the same information.

5 Interaction Scenarios Some of these dimensions determine most of the characteristics of an interaction situation. They define common interaction scenarios, which turn up in many different industries. These scenarios reflect typical work situations, which require their own computer support. One way to classify scenarios is by the way that the inputs to the tasks of the participants are related. •

Handover. One person undertakes a design task and finishes it is far as possible, then passes on the design to another specialist in a different aspect of the design, through a written or oral specification. The expectation is that the next person will do what is required within the specification rather than advancing the design by changing the specification. The participants are often co-located but communication is asynchronous. Later tasks are often seen as subordinate, so that two-way negotiations are excluded. For example, knitwear designers give their technicians specifications, without much discussion unless problems occur [17]. Such over-the-wall sequential design processes are still quite common in engineering, especially when designs are handed over to suppliers or contractors.

•

Joint Designing. A group of people work on one problem together. Typically they work at the same time in the same room. Individuals might work on parts of the problems, but they have easy access to each other and discuss issues as they occur. Joint designing is typically done by groups of people with similar expertise, who are solving a problem that concerns all. The team members usually share a lot of background knowledge and awareness of context, and often get to know each other well. They can talk to each other spontaneously and get rapid feedback on their communication acts [see 8, 9, 10, 15]. For example knitwear designers work out colour schemes as a group, because they all use the same colour scheme. In engineering designers often work jointly during conceptual design when even a complex problem is addressed by a small group.

•

Interface Negotiation. In concurrent design various people from different fields of expertise work on a design at the same time. Their tasks have mutually dependent inputs. To achieve full concurrency, they need to work with estimates of parameter values and negotiate to achieve mutually consistent solutions to their individual problems. In reality most processes give priority to some tasks and decisions, and stagger the beginning of the tasks. It is well recognised that concurrent design processes work best with colocated dedicated project teams. Communication occurs informally, through one-to-one conversations as well as in meetings.

Episodes of interaction can have a variety of purposes, even within a meeting with a different primary purpose. The types of discussion listed below can be about most of Minneman's nine classes of subject matter (see section 3.2).

ICED 01 - C586/518

477

•

Request for information. Designers frequently find they need more information, and usually their main source is their colleagues. Pure information request is more likely to occur in design handover or concurrent situations than in joint designing sessions.

•

Negotiation for clarity and negotiation of constraints. The participants in a discussion must make sure that they understand each other's positions - that is, achieve compatible interpretations of the situation. This often requires understanding the constraints the others must meet, to understand what the constraints on their own activities should be. So negotiation for clarity often leads to a negotiation over constraints. This is particularly important when designs are handed over (not necessarily in a linear process) from one specialist to another who is doing an equally important task independently.

•

Idea generation. In many design process that are essentially sequential, idea generation is undertaken as a joint activity in a meeting, because designers need each other's input before committing time and resources to any particular solution. Designers often reuse ideas from past designs or other sources; how much they refer to visual props depends on how much they need to explain ideas with reference to their sources.

•

Conflict resolution. Meetings are often set up to resolve conflicts between elements of a design. This is typically done through real-time discussion. Conflict resolution situations vary according to whether there is an authority capable of arbitrating or imposing a decision on conflicting parties.

•

Decision making. Much design comprises an exploration of possibilities followed by a decision on which avenue to follow. Decisions need to be made about what trade-offs to make, and often in conflict resolution, as well as about concepts. If individuals make decisions on their own, they have to justify them (see below). In meetings decision can be made jointly or by individuals higher up in the hierarchy.

•

Justification. Designers must often justify their solutions or decisions, either orally in meetings or in reports. The recipient cannot be assumed to have the same knowledge as the person who has to justify the solution. Justifications may be made to equals, bosses or outsiders; and the explanations must be pitched to the recipients' understanding. Specific justifications are often necessary in handover activities.

Each individual engages in most of these communication situations as part of their normal work, possibly with the same people. Designers use different channels on different occasions to convey different kinds of design information. For example a designer might engage in joint problem solving with his boss in a face to face meeting involving conversation and sketches, when they are negotiating over the constraints on a particular problem. The designer then works on his own using a CAD system. When he has a question has sends an email message or picks up the telephone. Later he has to return to the boss to justify the design that he has come up with in another face to face meeting.

6 Implications for Engineering Groupware No single approach to supporting communication is sufficient to handle the richness and variety of possible communication acts. Hence we should be suspicious of any assumptions that supporting formal meetings, or record management and transmission, or real-time interaction, is going to meet all the information transmission needs of a distributed organisation. However we can draw some lessons from studies of design communication.

478

ICED 01 -C586/518

•

As almost all design conversation refers to visual props, shared workspace systems are vital for distributed communication. Such systems should support sketching and gesturing as well as the use of formal documents and CAD models.

•

Much communication centres on contextual information, especially about past designs and competitor products, and relies on all participants being familiar with this context. Support for rapid retrieval and display of archive information could make shared workspace systems much more effective. Here support for communication overlaps with long-term information management.

•

Quick, casual, low-effort interactions are at least as important as organised meetings and formal information management - restricting them is potentially catastrophic. Hence it is essential for meeting support systems to support easy and rapid initiation of brief unscheduled interactions, especially if integrating informal interaction with information management activities is a desired objective.

•

Graphic representations and models not only communicate information across divisions of expertise and responsibility, but also play an important role in structuring design processes [14]. Access to and control of representations through information management systems will affect the design process. If using a particular model or representation is essential, how can it be used in communication scenarios for which the system was not designed?

The range of alternative situations in which designers interact indicates that there is scope for computer support for cooperative designing that goes beyond efficient document retrieval or video conferencing technology and shared workspaces. Important issues include translation between alternative notations and graphic representations, enabling the less-informed members of a group to establish the context of the discussion quickly and efficiently, supporting awareness of other participants in remote interactions, and maintaining security. Acknowledgements The authors are grateful to the EPSRC, GKN Westland Helicopters Ltd and Lotus Engineering Ltd for their support of this project, and to the engineers who participated in it. References [1]

Frost, R., "A Suggested Taxonomy for Engineering Design Problems", Journal of Engineering 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 and Support Systems, Artificial Intelligence in Engineering Design. Analysis and Manufacturing. Vol. 9, pp. 427-438, 1995.

[4]

Kaplan, S.M., Tolone, W.J., Bogia, D.P. and Bignoli, C., "Flexible, Active Support for Collaborative Work with ConversationBuilder", Proceedings of Computer Supported Cooperative Work '92. ACM Press, Toronto, Canada, 1992, pp. 378-385.

[5]

Medland, A.J., "Forms of Communications Observed During the Study of Design Activities in Industry", Journal of Engineering Design. Vol. 5, pp. 243-253, 1992.

ICED 01 - C586/518

479

[6]

Minneman, S.L. and Harrison, S.R., "The DrawStream Station: a tool for distributed and asynchronous chats about sketches and artifacts", Proceedings of HCI'99, Munich, Germany, 1999.

[7] Bly, S.A. and Minneman, S.M., "Commune: a shared drawing surface", Proceedings of the Conference on Office Automation Systems, Boston, MA, 1990, pp. 184-192. [8] Bly, S.A., "A Use of Drawing Surfaces in Different Collaborative Settings", Proceedings of Computer Supported Cooperative Work '88, ACM Press, Portland, OR, 1988, pp. 250-256. [9]

Tang, J.C., "Listing, Drawing and Gesturing in Design: A Study of the Use of Shared Workspaces by Design Teams", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1989. Xerox PARC report SSL-89-3.

[10] Minneman, S.L., "The Social Construction of a Technical Reality: Empirical Studies of Group Engineering Design Practice", PhD Thesis, Department of Mechanical Engineering, Stanford University, Stanford, CA, 1991. Xerox PARC report SSL-91-22. [11] Cross, N.G., Christiaans, H.H.C.M. and Dorst, K. (editors), Analysing Design Activity, John Wiley, Chichester, UK, 1996. [12] Eckert, C.M. and Stacey, M.K., "Sources of inspiration: a language of design", Design Studies. Vol. 21, 523-538, 2000. [13] Bucciarelli, L.L. "Designing Engineers", MIT Press, Cambridge, MA, 1994. [14] Henderson, K. "On line and on paper", MIT Press, Cambridge, MA, 1999. [15] Brereton, M.F., Cannon, D.M., Mabogunje, A. and Leifer, L.J., "Collaboration in Design Teams: Mediating Design Progress through Social Interaction", in [11], pp. 319341. [16] Huang, W. and Wei, K.K., "Task as a moderator for the effects of group support systems on group influence processes", European Journal of Information Systems. Vol. 6, pp. 208-217, 1997. [17] Eckert, C.M., "The Communication Bottleneck in Knitwear Design: Analysis and Computing Solutions", Computer Supported Cooperative Work. 2001. [18] Eckert, C.M., Zanker, W. and Clarkson, P.J., "Aspects of a better understanding of changes", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001. [19] Eckert, C.M., Clarkson, PJ. and Stacey, M.K., "Information Flow in Engineering Companies: Problems and their Causes", Proceedings of ICED'Ol. PEP, Glasgow, UK, 2001. Dr Claudia Eckert Engineering Design Centre Department of Engineering University of Cambridge Trumpington Street Cambridge, CB2 1PZ, UK Phone:+44 (0)1223 332 662 Fax:+44 (0)1223 332 662 Email: [email protected]

Dr Martin Stacey Department of Computer and Information Sciences De Montfort University Kents Hill Milton Keynes, MK7 6HP, UK Phone: +44 1908 834936 Fax: +44 1908 834948 Email: [email protected]

© IMechE 2001

480

ICED 01 -C586/518

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

A STATISTICAL STUDY OF HOW DIFFERING LEVELS OF DIVERSITY AFFECT THE PERFORMANCE OF DESIGN TEAMS A G Carrillo Keywords: Diversity, empirical study, design teams, design projects

1

Introduction

In recent years, diversity has become a popular area of interest. Today's business practices require multidisciplinary work groups in a constantly changing environment. The work force has also experienced a growth of ethnic diversity in its composition and that ethnic presence is expected to grow in the coming years. It is believed that the diversity of these groups will have positive affects on group creativity and performance [2]. Unfortunately, the effects on group process and performance are hard to measure and quantify. However, team diversity is considered a valuable resource [2] that has been under utilized and difficult to implement. Diversity can be defined as any attribute that can be used to differentiate one person from another [9]. Diversity includes demographic diversity, psychological diversity and organizational diversity [3]. Significant research in the last 40 years has explored how these differences affect the process and performance of work teams and how it affects those who manage these work teams. The majority of these studies are based on three basic theories. The theories are social categorization, similarity/attraction and informational diversity and decision making [9]. The results of this research have had mixed outcomes. Williams and O'Reilly have helped to summarize a large number of the findings in the area of demography differences within teams and its effects on team process and performance. In the paper's findings, group heterogeneity appears to have negative effects on group process while having mixed results on group performance. The effects on process include communication difficulties, task conflicts and group dissatisfaction. There has been no clear trend on its effects on group performance. Unfortunately, most of the work that supports diversity in performance has been conducted in the laboratory or classroom [9] Many diversity studies look at a single attribute of the team composition and investigate how that characteristic may have contributed to any differences in team performance. Additionally, studies look at the final results and may not look at how diversity may have influenced the performance of the team over time. Therefore, it is important to try to understand how diversity may influence the progress of the groups as well as the end effects on performance.

2

Purpose

The purpose of this study was to contribute to the research done in the study of diversity and its affects on team performance. It was also an attempt to explore multiple diversity

ICED 01 - C586/587

481

characteristics and see if these differences would have varying affects on the teams' performance and present those differences in a quantitative manner. Since engineering projects can last for such a varying length of time, how the teams progressed was also studied. It was important to try to understand the effects of time and if any trends could be uncovered that would not have be seen with a single measurement.

3

Method

Since the backgrounds of work team members are becoming more diverse, it is important to understand how varying diversity variables may in fact change the outcome of a team's performance. In an effort to understand these influences, a study was conducted to monitor a team's diversity and track the group's performance over time. For the academic years of 1994-95, 1995-96 and 1996-97, design teams in a Stanford University's mechanical engineering graduate design course were observed. The class studied is a three quarters long project based course with industry sponsorship. This format allowed for multiple performance checks with equitable time milestones and real life projects. Due to the duration of these projects, the team composition was team selected, allowing students to choose whom they worked with during the project. Team heterogeneity was encouraged but not enforced. Different criteria were established in order to provide a means in which to study the teams. The criteria were size of the team, the diversity of the team and grades as a measure of their performance. In an attempt to quantify a team's diversity, 6 different criteria were identified and the requirements to meet each criterion were established. The students were asked to take a brief sampling of the MBTI (Meyers-Briggs Type Indicator) questionnaire in an attempt to identify the student's "Preference Group [8]." The remainders of the group's diversity characteristics were identified using information provided by students at the time of project selection and from end of quarter documents written by the design teams. The teams' grades were recorded and kept throughout the year. The grades were used as the measure for team performance. An analysis was then performed to determine if the teams' performance was affected by the diversity of the group.

3.1 Team size In an effort to limit variability amongst teams in this study, a team size criterion was established. The class had roughly 45 students per year, with teams averaging 3-4 members per team. Teams started off with 2, 3, 4 or even 5 members at the beginning of the fall quarter. Due to outside influences, teams sometimes lost members during the year and so these numbers changed. Sometimes people were added to teams and some groups combined with other groups. In order to ensure sufficient team dynamic influences and resources, a team had to finish the course with 3 team members at the conclusion of the spring quarter. Additionally, all members had to be a part of the team for at least 2 quarters, allowing for change but requiring sufficient team unity. There were on average 12 teams that met this criterion each year. Any team with 5 members was not included in this study.

3.2 Diversity points In an effort to quantify the teams' diversity, each team was given a diversity point value/score. Six different diversity variables were identified. Each team was given a score of 0 or 1 depending on whether or not they met a variable's criterion. The team's total diversity

482

ICED 01 - C586/587

was then calculated by summing up the individual points. The minimum value was 0 and the maximum was 6. The variables and the criteria are as follows. Gender Due to the continually growing impact of women in engineering, it is important to understand how gender may affect the performance of work teams. This class had a limited number of women that participated in the class, so a team was considered to demonstrate gender diversity if at least one member of the team was a woman. However, at least 1 male must also be on the team in order for a team to receive this diversity point. In this study, it was rare for a team to have more than one woman. Ethnic Background The ethnic background criterion is a common demographic diversity factor. The students were categorized using the same ethnic categories that are used by the university's admission application. The main focus in this variable is that students have different backgrounds. Therefore, students from other countries were considered to be different from other ethnic backgrounds. For a team to meet this criterion, every member had to be from a different racial category or be from another country. Personality Preference In an attempt to address the psychology diversity influence, the personality preference questionnaire (brief sampling of the MBTI questionnaire) results were used to categorize the students into different preference groups. With Doug Wilde's direction and use of his personality preference scheme, the students were categorized into 4 distinct groups. They were labelled North (PG IV), South (PG III), East (PG II), and West (PG I) personality types [8]. The East and West styles are described as having almost polar working styles while the North and South styles are portrayed as having mediating qualities. In order for a team to receive the personality preference point, the team had to have an East and a West personality type on the team and a North and/or South group member. Distant Membership Stanford University has created a program, Stanford Instructional Television Network (SITN) (http://scpd.stanford.edu). that allows technical professionals to participate in Stanford classes while remaining offsite. This class has included several off campus/remote students from this program. Students from other universities have also been encouraged to participate in the class as fully functional teams, or team members. Distance can cause unique working difficulties for work groups [1]. To receive this diversity point, one member of the team must have been an SITN student or from another university for the duration of the project. Work Experience In order to address the differences in tenure/experience, work experience was included as an area of diversity. For the team to receive the work experience diversity point, at least half of the team must have had prior work experience. For a team member to claim prior work experience, the person must have worked full time for at least 1 full year. A person working 4 summers for the same company was not considered to have met the requirement. Although the experience is very valuable, it was not considered equal to a full year of work experience. School/Education Each team member must have attended a different college or university. If any two members attended the same college or university for their undergraduate schooling, the team did not

ICED 01 - C586/587

483

receive the school diversity point. It is assumed that by attending different schools, the team members will have different educational experiences and will bring different technical skills.

3.3 Grades In academics, grades are a common measure of performance. Therefore it was important for this study to ensure that the grades received were indicative of a "team's" performance and that all students had a similar grade motivation. Students may participate in this course in a credit/no credit basis. For a team to be included in the study, all team members had to receive a grade in the course. This was to ensure that all members would be equally affected by the outcome of the project and the grade received by the team. In the first quarter, there are two parts to the course. The industry projects are introduced in the second half of the first quarter and only these grades were included in the study, so the fall quarter grades are indicative of 5 weeks of work by the teams. Grades are measured with a 5 point scale breaking down to: Table 1. Breakdown of grade scoring

4.30 = B+ 3.30 = C+ 2.30 = D+

5.00 4.00 3.00 2.00

=A =B =C =D

4.70 3.70 2.70 1.70

= A= B= C= D-

The teams' final grades are weighted averages of grades on the physical hardware constructed by the teams, and the documentation of their design and the design process. The final step of the study was to gather all the information about the design teams and determine which criteria they met. The teams received a 0 or 1 for each criterion. The team was then given a diversity score by summing up the individual scores for each criterion. Each team's grades for the autumn quarter, winter quarter and spring quarter were calculated. The winter quarter's grade was not a major point for this study since the instructor used the winter quarter's grade as a progress report to the team. In fact, the instructor retroactively changed the winter grade to the same grade received by the team at the end of the project.

4

Results

Due to the small number of teams per year and the length of the projects, it is difficult to get a large sample size. However, some promising trends were identified. The teams were broken up into 3 categories: high, medium and low diversity. Groups with high diversity had diversity scores of 4-6 (14 teams). Low diversity groups had diversity scores of 0-2 (11 teams). The medium diversity group consisted of teams with a diversity score of 3 (5 teams). This group eventually had the most interesting outcome.

4.1 Fall Quarter Results In just 5 weeks of work, there was an obvious difference between the performances of the teams. Table 2 shows the descriptive statistics for the groups' grades at the end of the fall quarter. Based on the mean scores, the high and low diversity groups were roughly equivalent in performance. However, the high and low diversity groups outperformed the middle

484

ICED 01 - C586/587

diversity group substantially. The results can be better displayed with box plots as is shown in Figure 1. Table 2. Summary statistics of the diversity groups and the fall grades

Figure 1. Box plots of the diversity groups vs. fall grades

To look at the data more closely, the individual group scores were split into their respective 06 categories and new box plots were created. Figure 2 demonstrates an obvious trend. As the diversity scores approach the center of the diversity range, the average scores begin to drop. Only the groups with diversity scores of 4 do not follow this trend.

Figure 2. Box plot of individual diversity scores vs. fall grades

4.2 Spring Quarter Results To see if time changes the results, the groups' spring grades were calculated and a new analysis was performed. The summary statistics for the categories are represented in Table 3.

ICED 01 - C586/587

485

For the spring, there was now a noticeable difference between all the groups. The high diversity groups showed the highest mean score, followed by the low diversity group, with the middle diversity group once again performing lower than the other two groups. Another interesting result is that the standard deviation of the high diversity groups was half the standard deviation of the other two categories by spring quarter. The middle and low diversity groups both showed an increase in standard deviation by the spring quarter while the high diversity groups actually decreased. The results can be better visualized in box plots shown in Figure 3. Table 3. Spring Grades, descriptive statistics

Group High Medium

Low

n 14 5 11

Mean 4.41 4.06 4.22

SD 0.20 0.45 0.41

Figure 3. Box Plot of the diversity groups vs. spring grades

The distribution of the high diversity groups was much narrower in comparison to the other twocategories. The individual groups' scores were once again grouped into their respective 0-6 categories to see if there was a discernible pattern. For the spring results, there was no obvious pattern as seen in the fall. In order to present the progress of the teams in a more understandable form, a graph was created that plots the mean grades of the diversity categories and maps the grades over autumn, winter and spring quarter (Figure 4).

Figure 4. The progress of the groups from fall quarter to spring quarter.

486

ICED 01 - C586/587

As the graph shows, there was a definite improvement by the high diversity groups over the low diversity groups. Although the two categories started off at a similar performance level in the fall quarter, by spring quarter the high diversity groups outperformed the low diversity groups. Another interesting observation is how the middle and high diversity groups improved roughly the same amount. Unfortunately, the low diversity groups started off so much lower than the other two categories that they never caught up.

5

Discussion and conclusions

The first conclusion is that the degree of diversity may strongly influence a team's performance. For both the fall and spring quarters, the teams with middle diversity scores performed poorly with respect to high and low diversity groups. This may have strong implications on how diversity should be implemented. If there isn't a strong push towards high diversity at team formation, it may actually decrease the performance of the team. As Lau and Murnighan introduced, faultlines may be responsible for the differences in performance. Both low and high diverse groups may have a smaller number of faultlines within the group, reducing the existence of subgroups that lead to group conflicts [4]. This may be extremely important in ensuring that the benefits of diversity can be fully utilized. Another benefit of high diversity groups is the reduction in the standard deviation of that category. The high diversity groups not only outperformed the other two groups, but they demonstrated a smaller variation within the group. It is difficult to know exactly how diversity influences this outcome, but the benefits of this outcome can easily be seen. Time may also be a critical aspect of diversity studies. If the diversity study had ended after the fall quarter, it would have shown that there was no performance difference between the high and low diversity groups. However, after 2 and a half quarters, there was a noticeable difference between all three groups. This particular outcome may have much bigger implications. For shorter timed projects, team diversity may not be beneficial. In fact, if high diversity is not implemented, it may actually hinder teams. In summary, diversity influences the performance of a team. However, it may not always be positive or noticeable. It is important that high diversity be strongly encouraged and fully implemented and supported. Time may also be a factor in how effective that influence may be. Short term projects may benefit more homogeneous groups. Long term projects may benefit more from team diversity. Using these six variables to study work teams would be problematic in industry. These diversity factors are salient in a classroom setting, but difficult to identify in an organization. Additionally, the work environment is constantly changing, unlike the controlled environment of the classroom. Student team members did not work together throughout the day, limiting their interaction with one another. Finally, it is extremely difficult to measure team performance outside the classroom. This paper does not address motivation and group skills. These are important factors that have definite effects on team performance. These variables are difficult to measure and evaluate, but their influences should be considered in future work.

ICED 01 - C586/587

487

6

Acknowledgements

I would like to thank the students for their help in this study. Professor Larry Leifer's support of this study made it possible. I also thank Professor Doug Wilde for his help in determining the personality preferences for the students and in understanding his methodology. References [1]

Armstrong, D. J, and Cole, P. "Managing Distances and Differences in Geographically Distributed Work Groups". In S. E. Jackson and M. N. Ruderman (Eds.), "Diversity in Work Teams: Research Paradigms for a Changing Workplace" Washington, DC: American Psychological Association, 1995 pp. 187-215.

[2]

Eigel, K. M., Kuhnert, K. W., "Personality Diversity and its Relationship to Managerial Team Productivity". In M. N Ruderman, M. W. Hughes-James & S. E. Jackson (Eds.), "Selected Research on Work Team Diversity". Greensboro, NC: Center for Creative Leadership 1996 pp. 75-98.

[3]

Jackson, S. E. and Ruderman, M.N., "Diversity in Work Teams: Research Paradigms for a Changing Workplace". Washington, DC: American Psychological Association, 1995.

[4]

Lau, D.C. and Murnighan, J.K., "Demographic Diversity and Faultlines: The Compositional Dynamics of Organizational Groups", Academy of Management Review. 23, 1998, pp. 325-340.

[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 Relational Demography on Teamwork: When Majorities Are in the Minority", Research Paper Series, Graduate School of Business, Stanford University, 1999.

[7]

Ramsey, F.L. and Schafer, D.W., "The Statistical Sleuth: A course in Methods of Data Analysis". 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: A Review of 40 years of Research", Research in Organizational Behavior. 20, 1998, pp. 77-140.

Mr Andrew G. Carrillo Mechanical Engineering Department, Center for Design Research, Stanford University, Bldg 560 Panama Mall, Stanford, CA 94305-2232, USA, Tel: 650 723 3795, Fax: 650 725 8475, email: [email protected] © IMechE 2001

488

ICED 01 - C586/587

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

REQUIREMENTS ENGINEERING - LAYING THE FOUNDATIONS FOR SUCCESSFUL DESIGN G A Thomson

Keywords: Structure of requirements, customer satisfaction, concurrent engineering.

\

Introduction

The aim of this paper is to review Requirements Engineering techniques, which originate from the Systems Engineering domain, and describe their adoption within mechanical engineering design projects. The motivation for using these techniques is to provide improved recognition of customer and end user needs at the outset of a project and then to manage and control the use of requirements information throughout the project lifecycle. The techniques offer benefits particularly to projects with high levels of complexity and concurrency and can assist in supply chain management. The paper outlines the Requirements Engineering process, from the front-end requirement development activities through to the management and change control of requirements. A key benefit of these techniques is to establish traceability from the original customer need and system specification through the project lifecycle to the completed deliverables and acceptance criteria. This provides a method for rigorously assessing the impact of change to a project's requirements. The techniques have been successfully implemented in the design process for projects in the aerospace, defence and general equipment sectors.

2

The Importance of Requirements

The processes by which customer requirements are converted into a tangible outcome - the product - may not always be well defined, understood or managed. Development and agreement of requirements that properly reflect a customer's need is a skilled process that may be underestimated in terms of the degree of difficulty or investment required. In addition, problems often occur with the definition of adequate acceptance criteria, identification and control of change and the introduction of unnecessary or over-specified requirements. Failure to address any of these issues leads to degraded customer satisfaction and possible cost, schedule and performance penalties. Whilst there is considerable anecdotal evidence that this is true, published analyses of project under-performance related to requirements deficiencies are difficult to obtain. This is partly due, perhaps, to an historical under-recognition of the importance of this aspect of the engineering process or perhaps unwillingness by many organisations to reveal potentially sensitive commercial information. However, the following examples provide evidence of how poor requirements processes result in a detrimental impact on project performance.

ICED 01 - C586/177

489

The Standish Group's "Chaos" report [1] is oft quoted as an example of how badly captured and managed requirements in software projects lead to poor performance. The report contends that, during the early nineties in the US, a staggering 84% of software projects failed to achieve their budget or schedule and of this number more than a third were cancelled outright. The three most significant reasons determined for this by the research were lack of user input in developing requirements, incomplete requirements and changing requirements. Hooks [2] suggests that there is a correlation between the effort (or lack thereof) expended in developing a good project definition, including an adequately documented requirements set, and the likelihood of the project to suffer cost overrun. Moreover, the increased costs are directly attributable to the large number of requirement changes that occur late in the project lifecycle. Analysis of the history of a number of NASA programmes supports this assertion and is illustrated in Figure 1 which shows the relationship between poor requirement definition and likely project overrun.

Figure 1. Relationship Between Poor Requirements and Project Overrun

A corollary to the argument that late changes to requirements lead to project cost overruns (the worst case usually being post-production changes) is the potential to reduce programme risks and costs by developing a detailed a requirement specification as early as possible in the project or product life-cycle. Obviously, the ability to produce a refined requirement set is also dependent on the nature of the project and is bound to issues such as technical risk and other external factors. These problems are exacerbated in design projects involving high levels of complexity. However the best possible definition of requirements at the earliest stage and their subsequent refinement is a potent risk reduction process.

3

Requirements Engineering

3.1 Systems Heritage Systems Engineering is a discipline that has emerged from the need to manage the development and integration of complex systems. In the 1960s, the design of increasingly sophisticated technological systems was plagued by difficulties in achieving cost, schedule and performance targets. This was particularly true of software projects, defence equipment and spacecraft design [3]. Systems Engineering provides a structure for managing and implementing complex technology programmes throughout their lifecycles [4]. It can be described as a structured approach to product development that recognises the importance of requirements, system integration, planning, organisation, testing and acceptance processes [5]. These principles are equally relevant in concept (if not in detail) to development projects from

490

ICED 01 - C586/177

the very large and complex down to a relatively small scale. The effective application of System Engineering is a skilled discipline and requires a committed organisational investment to achieve. A key process in system design is verification (i.e. confirmation of the user and system requirements and the detailed design by test). Verification (sometimes called validation) demonstrates that the system "does the right thing" as envisaged by the stakeholder requirements. Recognising that this must take into account the different levels of system design and integration gives rise to the system "V" diagram as shown in Figure 2.

Figure 2. Systems "V" Diagram - Matching Requirements to Test

A recent example of how a failure of the requirement process can have a serious impact is the ESA/NASA Cassini mission to Saturn [6]. The spacecraft was launched in October 1997 and is due to arrive in the Saturnian system in 2004. An important science element is the Huygens probe, which is designed to separate from the Cassini orbiter and then descend through the atmosphere and land on the surface of the moon Titan. Unfortunately, more than two years after launch, it was discovered that the communications link between the probe and the Cassini orbiter had insufficient bandwidth to return all of the mission data. This was due to an effect due to Doppler shift between the two spacecraft. The reasons for this error stem, to great extent, from a failure to assess the impact of a design change on subsystem requirements and to link these requirements to an appropriate test.

3.2 Definitions The systems approach recognises the need to generate good quality requirements and the need to manage this information throughout the project lifecycle. This has given rise to Requirements Engineering which aims to develop a rational methodology for undertaking these processes. Note that there is confusion over the use of this term as some authors refer to the overarching requirement process as Requirements Management and Requirements Engineering has a different and more specific connotation. Wiegers [7] proposes a logical definition, which is adapted from IEEE conventions. This is that Requirements Engineering encompasses the entire domain of activities related to system requirements and it is divided into Requirements Development (the activities to create requirements) and Requirements Management (the activities to manage and control requirements). This is a useful distinction as it reflects the two broad ranges of activities that are required to establish an effective requirement process, see Figure 3.

ICED 01 - C586/177

491

Figure 3. Requirements Engineering Definition

3.3 Requirements Quality Requirements Engineering is fundamentally a communications activity. Most of the difficulties in producing good requirements are related to getting this communications process right. This is bound to often very subjective issues related to interpretation, semantics, opinion and individual viewpoint. Resolving this requires the development of requirements data that is objective, well structured, concise and relevant to the level of detail of the system component being considered. Several key quality attributes of good requirements can be identified. These include: Lack of ambiguity - requirements must be understood in the same way by all project participants. Failure to achieve this leads to incorrect or wasted effort. Necessity - requirements must exist to ultimately fulfil the top-level user needs. If not, they are simply adding extra cost. Testability - fulfilment of requirements must be confirmable by some type of objective test otherwise it is impossible to demonstrate acceptance of the system. This implies that requirements must be reduced to single ("atomic"), testable statements of fact. Attainability - requirements must be attainable not only within the constraints of the laws of physics but also the business environment and time frame of the project. It is commonly stated that an important aspect of good requirements is solution independence. In other words, the requirement should not embody the design. This is not to say that preexisting design solutions shouldn't be taken into account (either as constraints or as templates for further requirements extraction) but they must not be built into the requirements set. As an aside to this, it is actually quite important to refer to candidate solutions during the requirement development process, as it is only possible to cost designs, not requirements. It is also possible to gather quality metrics (e.g. level of decomposition, linkage to test etc) during the requirements development activity to ascertain progress towards achieving a robust and high quality requirements definition.

3.4 Requirements Development Producing quality requirements is a skilled process yet it is often the case that personnel involved in writing documentation such as a system specifications do not have any special skills or training to undertake such an activity. An effective Requirements Development process requires the extraction of requirements information from source documentation and domain knowledge experts using experienced facilitators. The raw requirements information

492

ICED 01 - C586/177

can then be analysed and structured into an effective requirements definition. Such a process is shown in Figure 4 and consists of the following phases: Capture - Sometimes called "elicitation", the collection of requirements information from the stakeholders (an important sub-set of which are the DKEs) and other relevant source data. Techniques such as brainstorming, interviews, questionnaires, scenario generation, QFD and Use Case can be used to assist the process. Analysis - The process by which the raw data captured in the first phase is converted into objective requirements statements. This involves reduction to atomic statements, assigning attributes, classification, sorting and determining priorities. This process requires further interaction with stakeholders and may use trade-off and technical studies to assist in refinement. Structuring - The final step is to structure and validate and the requirements. This can be supported by modelling techniques, for example Functional Modelling, to ascertain relationships and dependencies. Performance constraints can be added and quality metrics assessed.

Figure 4. Requirements Development Process

3.5 Requirements Management Requirements Management is the complementary process to Development. As requirement information is developed, it becomes necessary to manage the resultant data to ensure that its integrity is maintained. The main Requirements Management processes are: Configuration Management - The process by which the current version status of the requirements data is identified and controlled. Usually each requirement is assigned a unique identifier (sometimes called the Project Unique Identifier or PUID). When the requirements data achieves an agreed level of maturity it is frozen or "baselined". Change Control - Requirements provide fundamental information by which a project will be ultimately accepted by its customer. Also change, particularly late in the project cycle, equals cost. It is therefore imperative that a Requirement Management system can prevent

ICED 01 - C586/177

493

uncontrolled change to baselined requirements data. It is also useful to be able to maintain a change history of the project. Traceability - A key requirement management activity whereby linkages are made between requirements at different levels (i.e. the high level need, user and system) to the emergent design requirements, standards and tests. This provides the capability to assess the impact of change. These activities can be implemented in different ways. For relatively simple projects, it is possible to use paper or word processor based systems and spreadsheet traceability matrices. However for many projects the evolving requirements data becomes too complex for these approaches and it is necessary to use a specialised database tool.

3.6 Tools There are a large number of commercial tools available to support Requirements Engineering process. In fact Achrafi [8] identifies at least 35 different tools. They can be broadly classified into tools that support Requirements Development, Requirements Management or both. Development tools tend to provide process modelling capability (e.g. CRADLE, Rose and GMARC) whereas Management tools concentrate on maintenance of requirements data and are usually based on a database system (e.g. RTM, DOORS, Caliber, RequisitePro). It should be remembered that establishing a good requirements process is fundamental and should precede any decision regarding tool adoption.

4

Requirements in Mechanical System Design

4.1 Overview The systems heritage of Requirements Engineering has been outlined above. Whilst the techniques are relatively generic, their promotion within mechanical engineering projects (with the exception of large defence hardware programmes) has thus far been limited. However, there is increasing recognition of the importance of systematic processes within the wider design community particularly through the adoption of Concurrent Engineering and modern Project Management techniques. A major user (and developer) of Requirements Engineering techniques is the Defence Procurement Agency via the Smart Procurement Initiative [9]. All new defence projects must have a properly managed requirements process. Another organisation adopting the techniques is Airbus which is adopting Requirements Engineering on its new aircraft projects including the A380 and A400M. The techniques are gaining recognition in other sectors including telecoms (e.g. mobile phone design) and consumer products. There are implementation issues that need to be considered for adoption within mechanical design environments. These include: gaining recognition for the up front requirements development work that must be done demystifying the jargon recognising the differences in the design processes between hardware and software systems.

494

ICED 01 - C586/177

4.2 Project Examples The following examples are from the author's recent experience [10] and are provided to illustrate how requirements related techniques are being adopted. Aircraft Research Programme A European Commission funded fifth framework research programme to develop new construction techniques and technologies for future aircraft. The programme involves a relatively large number of partners and work packages from different organisations and European countries. One of the partners has used requirements management techniques to control the high number of requirements within their workpackage. This has improved project control and provided traceability between the project deliverable requirements, interfaces to other partners and verification tests. Safety Requirements Development A project involving the development of a nuclear site safety case at an existing defence facility [11]. The organisation responsible for developing the safety case introduced a requirements engineering process into their safety case development team. This was done via a seminar/workshop training programme and followed up by consultancy support. They elected to use a commercial requirements management tool to control the large number of safety requirements developed during the project. This approach established an audit trail through the safety case development activity, produced safety requirements that were testable and linked to regulatory acceptance, produced a systematic way of decomposing and evolving safety requirements and captured the thought process behind the safety case development. Technology De-risking Programme The conceptual design of a technology demonstrator to de-risk a proposed aircraft launch system that proposed the use of novel technologies. This project used a formal approach including Requirements Development activities to define User Requirements and System Requirements documentation linked to a proposed future development programme. This approach was designed to be compliant with the MoD Smart Procurement Initiative.

5

Conclusions

Requirements Engineering techniques offer significant advantages in terms of improving project performance and customer satisfaction. In fact, for the success of complex technology development activities, it is essential that an effective process to establish and manage requirements is established. Moreover, the use of requirements traceability offers the possibility of improved change control and impact analysis. This provides the design project manager with the ability to control cost and reduces the project lead-time. The techniques also allow improved communication within concurrent teams and design projects within complex supply chains. The techniques have been adapted from their software and systems heritage and are now being successfully used within general mechanical design projects.

ICED 01 - C586/177

495

References [1]

Standish Group, The, "CHAOS Study", The Standish Group International Inc, January 1995.

[2]

Hooks, I. F., "Managing Requirements", Issues in NASA Program and Project Management, 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, "Systems Engineering - A Way of Thinking", International Council on Systems Engineering and the 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, INBIS Technology Ltd and Integrated Chipware UK Ltd, 2000. [11] Cooper, D., "Safety Requirements Management Using a Database Technique", NNC Ltd, 2000.

G. Thomson INBIS Technology Limited 1 The Brooms Emersons Green Bristol BS16 7FD United Kingdom Telephone: +44 (0)117 987 4000 Fax: +44 (0)117 987 4040 Email: gthomson(5),inbis.com © INBIS Technology Limited 2001

496

ICED 01 - C586/177

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

THE ORGANIZATION AND MANAGEMENT OF ENGINEERING TENDERS G Barr, J H Sims Williams, S C Burgess, and P J Clarkson

Keywords: Competitiveness, Cost-estimation, Design reviews, Product planning, Risk analysis and management

1

Introduction

This paper outlines the current tendering practices of companies operating within the engineering industry and identifies potential areas where current methods can be improved. A tendering methodology is proposed which can potentially identify and evaluate the technical risks that engineering companies possessing stable product architectures are exposed to. As demonstrated by a case study, adopting the methodology will enable companies to re-use knowledge established during historical projects and employ that knowledge when evaluating risks inherent in tendering opportunities. The origins of many project risks can be traced back to defective decisions made during the tendering phase. Troublesome project issues can potentially be mitigated with improvements to the tendering process of engineering companies. There are many problematic issues that arise within the tendering phase, such issues are the scarcity of resources (either human or mechanical hardware), costing shortfalls, project over-runs, non-performances by in-house or sub-contracted resources or an inadequate detailing of the project scope. Models have been made of the tendering practices employed by engineering companies' [1][2]. Many of the methods proposed capture the specific tender process of a company and implement a rule-based method to capture the commercial decision-making activities. However, the study of capturing and evaluating technical data has not been widely covered. There are many approaches to evaluating the level of risk to which an engineering company is exposed during the preliminary stages of a project [3]. The two main questions that engineering companies are required to be confident of answering are: Can the project be delivered on time? Can the project be delivered within the cost budget? These two factors, time and cost, are inextricably linked. In general, the more resources that are assigned to a project the higher the project cost. However, assigning more resources to a project does not guarantee a project will be completed on time. The aim of evaluating the amount of uncertainty present in a project is to provide a method that aims to estimate and then deliver a project to budget and on time.

ICED 01 -C586/336

497

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 was elicited from company representatives with extensive experience of their company's internal tendering practices through semi-structured interviews. Table 1' details the industrial sector and operational roles of the companies interviewed. By pursuing this evaluation process, the type of companies that would benefit most from employing a risk-based model incorporating the re-use of historical technical data for analysing tender uncertainty can be identified. It is intended that the method proposed can be adapted to suit the practices of many engineering sectors. Table 1. Studied Engineering Companies

® ®

® ®

©

® ®

®

Company Elect-Mech-1 Elect-Mech-2 Elect-Mech-3 EngConsum ConPro ConDes-1 ConDes-2 ConDes-2

Industrial Sector Marine Power Systems Power Systems & Materials Mechanical Bulk Handling Engineering Consumables Construction Construction Construction Construction

Operational Role Electro-mechanical Designers & Contractors Electro-mechanical Designers & Contractors Electro-mechanical Designers & Contractors Mechanical / Electronic Design Consultants Civil Project Managers Civil & Structural Design Consultants Civil & Structural Design Consultants Civil & Structural Design Consultants

The studies were needed to understand not only the tendering practices of the companies but also to appreciate the market sector in which the companies work. By studying the operational role the company performs, the tendering operations and rationale of the company can be better understood. Modelling of the tendering mechanisms were made with respect to the company's: Operational Environment - Depicting the constraints of the engineering market in which the company operates. Tendering Practices - Depicting the operations of the company during the tender phase and subsequent project phase. The companies were assessed against ten subjective factors for each of the two models, on a scale2 of 1 to 5 with 1 = 'Very Low' and 5 = 'Very High'. The results of the evaluation process for each engineering company are relayed through presentation on two spider plots, displayed in Figures 1 to 4. The graphical plots demonstrate the tendering practices employed by the engineering companies balanced against their operational constraints. Similarities between engineering sectors and roles can also be identified through the use of the graphical representation. 1 The names of the companies involved have been disguised due to the commercial sensitivity of the subject matter. 2 The evaluation scale is further detailed with exact definitions attributed to 1-5 for each of the 20 factors however due to publishing constraints the exact definitions cannot be shown

498

1CED 01- C586/336

Figure 1. Operational Environment (Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 2. Tender Development (ConDes-1, ConDes-2, ConDes-3 & ConPro)

Figure 3. Tendering Practices (Elect-Mech-1, Elect-Mech-2, Elect-Mech-3 & EngConsum)

Figure 4. Tendering Practices (ConDes-1, ConDes-2, ConDes-3 & ConPro)

Conclusions from Current Practices The graphical plots (Figures 1 to 4) highlight many similarities between the tendering practices of the companies based upon the nature and type of business environment in which they operate. We will focus on the issues related to the companies' technical bias and subsequent understanding of technical risk. All companies are shown to possess a comparatively unstructured base of historical technical data. It has also been observed that the reuse of this data is not particularly high during the tender phase. Similarly, the methods employed for evaluating the uncertainty associated with potential projects can be seen to be relatively unsophisticated. There is therefore scope for historical technical information to be used if a method can be suggested which is appropriate and delivers beneficial results. The companies that are required to undertake a high degree of technical detailing during their tender operations would be most likely to benefit as technical information can be collated during tender proposals and project with relative ease if an appropriate system is set in place. This would be easier to achieve within organisations that possess relatively stable product architectures. Solutions that such companies offer to clients typically contain relatively low amounts of original engineering content and high proportions of variant / adaptive design. Parallels between historical projects can thus be established with greater ease. The engineering companies can be classed according to their operational nature; illustrated graphically in Figure 5. The 'Solution Experience' scale indicates how familiar the company is with solutions they typically generate. For example, a design consultancy will typically take the client's original solution requirements and produce an original solution to meet their brief; the designs they generate are therefore unique. Due to the high amount of original working undertaken by these design consultancies and their limited experience in generating the product solutions requested of them, they do not possess a significant amount of historical data which could be utilised in future designs. Companies that undertake little original working in their projects tend to include small amounts of technical detail in their tender documentation. The practices displayed by organisations noted in Figure 5 as © and CD are therefore unsuitable as the research is primarily aimed at reducing the technical risk exposure of engineering companies during the tender stage.

Figure 5. Classification of Engineering Roles

3

Industrial Case Study

The method of evaluating and documenting the technical risk present in the tendering practices of engineering companies is currently being tested with a large electro-mechanical company (previously noted as 'Elect-Mech-3') involved in the design and commissioning of large-scale bulk handling systems. As an approximation, the company typically tenders for about 10 projects per annum for its bulk handling system around the world. It will typically expect to win the contract to design and commission one or two of these projects. All systems of this nature consist of large sub-systems which must be designed and assembled to interact with each other. The sub-systems incorporated into the design of new tenders are mainly reused from previous projects. If a project contains an excessive number of elements which the company considers to be outside it's previous solution experience then the potential project will not be bid for. When tendering, the technical detail specified in the tendering submissions will be extensive. However, it has been noted that owing to tendering time and resource constraints there exists limited scope to fully assess the risks present within project bids.

4

A Risk-Based Tendering Methodology

Modelling cost and technical risk for engineering projects is complex and relies not only on explicit data but also on experience and judgement. Engineering companies must first decide whether to bid, and if so, then determine a suitable tender price. To proceed with a tender, an engineering company must have confidence that the uncertainties arising from the technical aspects of a project can be fulfilled. It is common practice within engineering companies to identify and evaluate the risks present within projects using a simple 'risk exposure' matrix. The probability of an event occurring and the impact of that event (should it occur) are used to highlight the 'acceptability' of a particular event. This method however can prove inadequate when modelling complex engineering projects. Firstly, project risks are separated from project tasks and objects making the correlation between risk and project models (e.g. work / product / organisational breakdown structures) difficult. Secondly, the similarities between project risks from one project to another can be hard to identify, thus reusing historical data can be troublesome. Crossland proposes a mechanism for the stochastic modelling of key design parameters during the conceptual stages of engineering design, particularly the modelling of project cost [3]. Historical technical data is used as the method inputs, however ensuring the accuracy of historical data is problematic. The method proposed here suggests that estimates used within the very earliest stages of design, in this case the tendering phase, should indeed be based upon historical data. The data should not however be used directly for input into an estimation tool, but as a recommendation to experienced designers as to the input values which should be used. In addition, the uncertainty associated with the estimate of cost for each task or object used in the estimation process should be based upon realistic evidence. A method is therefore proposed which identifies the tasks and objects (i.e. components, system assemblies, etc) that possess the greatest uncertainty. It is the aim of the methodology to facilitate the decision making process and ensure decisions are based on sound technical judgement. To accurately model technical information in a re-usable format, a system must be used which provides documentation of technical information in a form that compliments existing techniques and is applicable whether the project tasks or objects are related to design, manufacturing, assembly or construction, etc. Niwa states that the work in an engineering project can be broken down into 'work packages' [4]. A work package is defined in a two-

1CED 01 - C586/336

501

dimensional space which comprises standard project activities (i.e. procurement, installation, etc.) and standard objects (e.g. equipment or buildings, parts of the product model). It is proposed that the project modelling technique used by Niwa is modified and the concept of work package 'deliverables' introduced. Deliverables are a class of object which are produced when tasks are undertaken on objects to produce a product. Deliverables are not solely products that are deliverable to clients, they can also be internal deliverables and as such used again within the project model as objects belonging to a subsequent work package. During engineering projects, risk typically arises from the undertaking of project tasks in the physical creation or design of project tasks. A method has been developed which is effective in evaluating and ranking the complexity of each task and work package within a potential project. The method is centred on the work of Pahl and Beitz where work in engineering projects, in particular design work, can be said to consist of a combination of original, adaptive, variant or repeat content [5]. Project templates representing the company's range of solution configurations are used to create the initial project model. This model is then populated using information relating to common project tasks and interfaces from historical projects. The tasks from the model structure are studied and evaluated according to their original content and the strength of their interfaces with other project tasks. Risk profiles for each of the tasks within the project can therefore be produced in order to provide suitable preliminary information for the accurate stochastic modelling of project cost. The project tasks are ranked according to their effect on and sensitivity to other project tasks providing the technical team with an understanding of the risk of the proposed project. The difficulty in generating a solution for each individual task, described as the 'Solution Complexity', is evaluated during the tender by the technical team. The project tasks are assessed according to the originality of the task and classified according to the rating scale as follows: 1. Near 100% repeat working. 2. Low amount of adaptive / variant working. 3. Moderate amount of adaptive / variant working. 4. High amounts of adaptive / variant working. 5. Very high amount of adaptive / variant working. The interfaces between project tasks identified are initially modelled using a Design Structure Matrix (or DSM) [6]. The reason for using DSM's is the ability of the method to map complex relationships inherent in engineering projects. By using the method, the relationship between different project tasks can be seen to be defined as independent, dependent, interdependent parallel or interdependent coupled. The matrix is used to capture the task interfaces as demonstrated in the example detailed in Figure 6.

Figure 6. Example DSM of Elect-Mech-3 Hopper Design Tasks

502

ICED 01 - C586/336

Simply stating the interactions between tasks in the model is not enough. The interface between the tasks must be evaluated on two levels. These two criteria are the level of dependency that exists between tasks and the originality of the interaction. For example, when considering the case of interface originality assume that undertaking a design task, Task A, affects another design task, Task B, and both Tasks A and B have been performed many times before and essentially involve repeat working. The tasks are therefore linked (A-B). However, both tasks have never been undertaken together during the same project. Thus, there exists a potentially a high degree of risk associated with the interface between the tasks. The uncertainty concerning this interface must therefore be assessed in order that its affect on the project can be evaluated. The originality of the task interface is therefore evaluated on a scale of 1 - 5 with T equivalent to 'very low originality' and '5' to 'very high originality'. The strength of the dependency is essentially the measurement of reliance between the affected task and influencing task. The dependency which exists between the influencing and affected task is also evaluated on a scale of 1 - 5 with '1' equivalent to 'very low dependency' and '5' to 'very high dependency'. By using the evaluations given regarding the complexity of a task's predecessors and interface characteristics, the sensitivity of the task to its predecessors can be qualified. The task's sensitivity to previous solution derivations proving unsuccessful can be identified using Equation 1. This score is used to highlight how sensitive the particular task is compared to other tasks in the model. A list is established for all project tasks ranking their sensitivity in relation to the other project tasks. The location of uncertainty within the project can thus be identified. In a similar manner, the task's influence on other tasks in the project can be qualified using Equation 2 and a ranking of the influence of project tasks established. This list will highlight the tasks with the potential to generate risk within the project. Equation 1:

Equation 2:

Where: T, = Sensitivity Rating of Task Tf = Influence Rating of Task T0 = Originality Evaluation of Task T'a= Originality Evaluation of Task Influencing the Task under consideration Td = Task Dependency Evaluation 10 = Interface Originality Evaluation T'd= Task Dependency Evaluation of Task Influenced by Task under consideration I'0 = Interface Originality Evaluation of Task Influenced by Task under consideration m - Number of Tasks Influencing Task under consideration n = Number of Tasks being Influenced by Task under consideration

The levels of risk present within work packages can also be derived from studying the risk of each of the tasks within a work package. Comparisons can therefore be made with other work packages within the current project and also with the levels of risk noted in similar work packages from historical projects. The primary benefit of using the evaluation methods are realised when attempting to quantify the estimated project cost using stochastic methods. The methods of working and technical detailing employed by the studied company during tendering have been found to be consistent with the project modelling configurations proposed. The study of applying the methodology on a historical tender for a rail-based bulk handling design has been undertaken and their design process mapped onto the work package structure. In addition, the risk evaluation method is noted to provide considerable benefits in

ICED 01 -C586/336

503

generating a cost and risk profile for bulk handling projects without compromising the organisation's limited time and resources.

5

Conclusions

This research paper identified the key areas where engineering companies can improve tendering practices. It was observed that engineering companies which design systems with stable product architectures can be aided by employing a risk evaluation method as a basis for addressing the costing of their projects. By identifying the technical interfaces present within engineering projects when tendering, the risk exposure of a company can be reduced at an early stage. It has been noted that the primary means to reduce tendering uncertainty however requires organisations to store tendering information in a re-usable format. The developed methodology provides a valuable evaluation means for engineers to report their perception of the risk levels present in the tendering opportunity back to those making the commercial tendering judgements. It is anticipated that the research will enhance the risk management procedures employed by UK engineering companies and improve their relative competitiveness. Additionally, by improving the efficiency of the tendering process, the risk levels to which companies are exposed is reduced, thus aiding long term organisational competitiveness. References [1]

Phythian, G.J. and King, M., "Developing an expert support system for tender enquiry evaluation: A case study", European Journal of Operational Research. Vol. 56, 15-29, 1991.

[2]

Fayek, A., "Competitive Bidding Strategy Model and Software System for Bid Preparation". Journal of Construction Engineering and Management. Vol. 124, No. 1, 110,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 in Human-Computer Co-operative Systems", John Wiley & Sons :New York. ISBN 0471-62893-X, 1989.

[5]

Pahl, G. and Beitz, W., "Engineering Design: A Systematic Approach", The Design Council :London. ISBN 0-85072-239-X, 1988.

[6]

Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D., "A Model-based Method for Organizing Tasks in Product Development", Research in Engineering Design. Vol. 6, No. l, pp. 1-13, 1994.

Gordon Barr Design Information Group, University of Bristol, 83 Woodland Road, Clifton, Bristol BS8 1US, Tel: +44 (0)117 9288914, Fax: +44 (0)117 9288912, E-mail: [email protected]. © IMechE 2001

504

1CED 01 - C586/336

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

MODIFICATION OF A METHODOLOGICAL DESIGN TOOL FOR THE DEVELOPING COUNTRY SCENARIO - A CASE STUDY IN PRODUCT DEFINITION K M Donaldson and S D Sheppard

Keywords: Product definition, developing countries, sustainability, economic viability of new technologies, SMEs

1

Introduction

Product design for developing country markets sees additional and different constraints than the parallel process in an industrialized economy. This paper examines the donor-driven model of technology development by evaluating a DfX (Design for "X") product definition methodological tool, the Product Definition Assessment Checklist as implemented by an EastAfrican non-governmental organization (NGO). The modifications necessary to make the Product Definition Assessment Checklist applicable are discussed along with lessons that can be taken away for donors and product designers in both industrializing and developing countries.

2

Background

2.1 The Product Definition Phase Product Definition, in this paper, will be defined as the first phase of the product development process based on the works of Ullman [4] and Ishii and Kmenta [3]. Wilson defines this phase as "the product development effort between the start of the project and the review meeting when the organization decides whether or not to invest in developing the product" [7]. At all stages of the design process methodological tools exist to assist designers. The standard output of the product definition phase is typically a list of specifications based on user needs. The product definition phase, however, can be academically reduced to subphases: need-finding, bench-marking, and priority setting; each with appropriate methodological tools that leads designers to the product definition statement. Wilson argues that a complete product definition should outline the product risks, the process development plan, the product channel plan, and the support plan of the company [6,7]. The product development organization must also recognize risks due to and constraints in the current market and in its own institutional structure. An effective product definition statement should then set forth the project priorities by identifying the goal(s) based on internal and external constraints, comprehensively defining the user need, and delineating the value to be delivered in the product [3].

ICED 01 - C586/410

505

2.2 Characterizations of a Developing Country Manufactured household products sold in developing countries typically arrive at the market by one of the following four product development modes. The product is: 1. reverse-engineered and crudely reproduced by roadside artisans (the informal sector), 2. designed and produced in small quantities by medium- to large-sized manufacturing firms (the domestic formal sector), 3. imported (designed and produced outside of the country), or 4. designed by a donor-funded NGO (non-governmental organization) then passed off to local manufacturers to be produced. In the first two cases a full execution of the design process is impossible or unreasonable due to the dearth of capital and inadequate entrepreneurial and technical skills, resulting in a limited product variety that inadequately meets customers' needs. Locally-made products in countries like Kenya face stiff competition from and displacement by imported products from India and China (case 3) that subsidize their domestic manufacturing sectors to ensure competitive advantage in foreign markets. These cheaper imports are understandably less suitable at fulfilling needs, but nonetheless find a ready market in a society where comfort ranks far lower in terms of customer priorities. The abbreviation of the design process due to lack of resources most often occurs at the front end: the product definition and the conceptual design phases are skipped; imports are reproduced, typically without modification to address local consumer needs. The reason is comprehensible — there are no resources to risk on an "unproven" or "original" product. In contrast, designers and engineers in industrialized economies, however, recognize the importance of the product definition stage where the voice of the customer, needs, and specifications are captured. Inappropriate decisions resulting from a poorly defined product significantly increases costs and risks the product's viability [4].

2.3 Donor/NGO Technology Development Model The fourth case of product development is presently limited, but is the most encouraging path of product development because resources exist to permit the full design process necessary to produce a product that meets the local users' needs. The donor/NGO model of product development resembles the product development firm in an industrialized economy. Because small- to medium-sized manufacturers (SMMs) often lack the capital and skills to determine customer needs, northern1 aid or donor organizations provide resources to specific southern NGOs for market research and technology development. This parallels the heavy initial capital investment in market research that an industrialized firm makes at the start of the product development process. In past donors have also engaged in technology development themselves, but with highly-publicized dismal results, and the growth of locally-situated southern NGOs, the development efforts have been shifted from the donor to the NGO. This "corporate" product development model represents a fundamental shift in foreign aid thinking: for a product to sustainably improve the lives of the consumers, it must be marketdriven. Once a product is developed by the NGO, it is then passed off to local manufacturers, "Northern" corresponds to industrialized societies; "southern" to developing countries or newly emerging economies.

506

ICED 01 -C586/410

distributors, and retailers. If the product is economically viable (i.e., affordable and offering value to the user), its production and market are sustained although the donor and NGO have exited the project. Although NGOs (with donor assistance) and donors have the resources to implement and are in the position to influence local manufacturers by proving the benefit of a market-driven product development process, this is infrequently effectively accomplished. NGOs typically lack technical personnel with formal product development and design process experience.

2.4 Definition of "product" A product is defined as a physical artifact and/or a service, or no action. Following some need-finding scenarios, it may be determined that no action is the best solution at the current time given the possible ramifications from all other options.

2.5 Methodological Design tools and PDAC-1 Methodological tools to assist designers and encourage the success of manufacturing enterprises can be broadly categorized as DfX (Design for "X") tools. DfX tools2 such as those falling in to Design for Manufacturability (DfM), were developed (implicitly) for firms operating in industrialized economies, where success is increased profits by providing better value to the customer through increased economic efficiencies in production and design. Given the constraints of engineers and manufacturers in developing countries, why would it be desirable or useful to employ methodological tools? Considering that DfX tools are not without drawbacks, this is a particularly pertinent question. DfX tools are attractive to southern design situations for two reasons. First, DfX tools particularly assist designers who lack formal design experience, and are removed from the consumer (not just geographically, but also culturally, economically, and educationally). Second, the nature of the NGO and donor relations is such that the NGO must account for all resources to ensure continuity. The Product Definition phase of the design process is the appropriate phase to examine methodological tools for usefulness to the southern scenario as affordable products there poorly address consumer needs. Wilson mapped the processes that successful and unsuccessful project teams used to create and manage their product definitions. The Product Definition Assessment Checklist (PDAC-1) resulted with a list of fourteen3 critical factors [7] for design teams to consider and address in the product definition phase: 1. Strategic Alignment: the design team understands the objectives of the project. 2. Project Priorities: the feature set, retail cost, and time to market are determined to be constrained, optimized (given the constraint), and accepted. 3. Resources: Necessary staffing and funding is available. 4. Management Leadership: Management hierarchy is supportive and unified. 5. Dependencies: External and internal project dependencies are functional. 6. Competitive Analysis 7. Product Positioning: The product offers value to the intended market.

3

This paper considers only methodological tools The checklist items are reordered from Wilson's original listing.

ICED 01 -C586/410

507

8. Core Competencies'. Necessary core competencies are identified and accessible 9. Understanding Users' and Customers' Needs 10. Risk Management: the design team understands the risks being taken. 11. Localization: the design team understands variations in needs and compliances 12. Compliances: compliance standards are recognized 13. Business Model/Financial Analysis: The financial and project plan is complete. 14. Market Channels: Appropriate channels for distribution exist.

3

Hypotheses

This paper puts forward two hypotheses: Methodological design tools are applicable (with modifications) and potentially useful to the donor-driven product development process in developing economies. The modifications necessary to make a tool applicable will highlight considerations for design teams developing products working in both industrialized and developing scenarios.

4

Application of PDAC-1 to a Developing Country Scenario

The Product Definition Assessment Checklist (PDAC-1) was evaluated for a developing country scenario by applying it in the product definition stage in the design of a product to assist rural farmers in central and Southwest Kenya access groundwater. The development organization is an East African NGO, headquartered in Nairobi, Kenya, with the purpose of promoting sustainable employment and economic growth by researching, developing, and promoting technologies appropriate for small-scale manufacturing enterprises in East Africa. Funding for the project is provided by a European bilateral aid organization. While this NGO is a forerunner in its field, this project is representative of the donor/NGO model where product research and development is donor-supported with the technology then passed off to the private sector for manufacture, distribution, and sale. The NGO design team4 was composed of four engineers: 3 expatriates and 1 Kenyan. All of the engineers hold advanced degrees in mechanical engineering with a range of experience (315 years) in product design and development in developing and industrialized countries. Team members were asked to rate the usefulness of the checklist items for applicability as is (no change to factor required), some applicability (minor change to factor or extended meaning required), non-applicability (factor may be ignored), and completeness (additional items required). A modified PDAC, PDAC-2, for the developing scenario resulted. The NGO design team evaluated the PDAC-1 individually then discussed it with the primary author and other members in a group setting. The exercise was structured in the context of 4

The NGO design team is not representative of most product development teams in the donor/NGO model. A typical team may have one engineer with limited to minor technical experience in a developing or industrialized country. Other team members may be "handy" individuals with vocational skills and/or social scientists.

508

ICED 01 -C586/410

the stated needs of the rural farmers. The team had previously completed the preliminary stages of the product definition phase. Each PDAC-1 item's level of usefulness was determined by informal group consensus intermixed with general discussion. The exercise lasted approximately 2-1/2 hours with roughly equal participation by all team members. The notes for each checklist item were then synthesized to create the modified PDAC-2.

5

PDAC-1 to PDAC-2

Although the discussion of PDAC-1 was framed within the context of a specific project, the design team's recommendations for modifications resulted primarily from their experiences working on past product development projects. Team members' responses differed based on their varying past professional experiences: whether they had worked primarily in a developing country, an industrialized country, or both. Engineers with the less overall experience tended to notice discrete differences (e.g. "the bolts are in English and everything else is in metric!"). The more experienced engineers noted larger-scale issues and differences (e.g. "it is impossible to predict the resources we need for a project before we do market research and we can't afford to market research before we get the resources...").

Figure 1. Constraint groupings of PDAC-2 checklist items

Following discussion and recommendations for modifications, checklist items were mapped to three constraint groups: institutional, design team, and/or local. Institutional constraints are those related to the design team's support structure and funding source(s); however, external to the team, but philosophically influencing their operations. Institutional constraints in an industrialized scenario may be production schedules set by management to be consistent with corporate goals. Design team constraints are those internal and inherent to the design team, such as lack of experience. Local constraints are those external to design team and institution, which include the customer, and the industrial, economic and cultural environment(s). As shown in Figure 1, most checklist items overlapped.

5.1 Three Checklist Items For each checklist item item, the original PDAC-1 question [5] was first listed, followed by the synthesis of the NGO design team's discussion, then if necessary, the modified PDAC-2 checklist item [2]. For this paper, three checklist items (boldface in Figure 1) were selected from each of the groupings: project priorities, core competencies, and localization. 2. Project Priorities PDAC-1: Does the team have an agreed upon hierarchy of measurable priorities based on the required positioning? 1 (None) 2 3 (List established) 4 5 (List used)

ICED 01 - C586/410

509

Wilson uses a priority matrix in Figure 2 for the design teams to set the project priorities. The product feature set, retail cost, and time to market are prioritized with the determination of which should be constrained, optimized (given the constraint), and accepted. In the industrialized scenario, the design team's project priorities are typically determined by the corporate strategy for developing and marketing the product. However, in the developing scenario, priorities dictated by the donor-approved project plan may not match those that best serve the end user. Two matrices are therefore necessary to recognize the possibility of differing priorities. In the southern customer scenario, cost is almost always the constraining factor, followed by features that are optimized, and accepted time to market (within reason, of course). Donors funding technology development will constrain time to market because of the project length specified in the project proposal. Cost and features are then optimized with cost often losing out to features that are set and met with user-based specifications. Figure 3 shows the inherent mismatch.

Figure 2. Priority matrix

Figure 3. Design team priority matrices

8. Core Competencies PDAC-1: Are all the core competencies, required for successful deployment of your project, identified and accessible? 1 (Not at all) 2 3 (To some extent) 4 5 (To a great extent)

Core competancies required to successfully deploy a project in developing economies or countries may be inaccessible. Steel sections are a good example. Design team members know that the available (locally-made) mild steel sections may vary as much as 5% in any dimension. Internal and external diameters varied unpredictably. Angles assumed to be 90° were noticeably not. Local manufacturers could arguably produce sections to higher tolerance, but this would result in a prohibitively expensive product. The NGO then shifted their focus to the composition of their design team, recruiting members with the experience and skill to be able to design a robust product with expectations of supplier variance. 11. Localization PDAC-1: Are the variations in user needs and compliances understood by geography? 1 (Not at all) 2 3 (To some extent) 4 5 (To a great extent)

The societies of industrialized countries tend to be far more homogenous than those of developing countries. The existence and development of technology, among other things, promotes a "melting pot" culture of assimilation, but countries with poor infrastructures and low technology usage maintain isolated pockets with "mosaic" cultures. The population of Kenya is composed of over sixty tribes, each with distinct languages and cultures. Traditional gender roles, for example, may vary over a small region resulting in vastly different user needs. Whereas number 2: "Understanding the User and Customer Needs" stresses the importance of understanding user needs, this question reminds designers that it is likely that there is a high degree of variance amongst the target population. PDAC-2: Are the variations in user needs understood by geography and culture?

510

ICED 01 -C586/410

5.2 Overview of Main Findings Implementation of the PDAC1 in the developing scenario resulted in findings in two different areas. First, (1) following the characterization of the donor-driven product development model; there is clearly an inherent conflict of goals as it presently exists. Secondly, (2) assumptions made during product development processes in industrialized scenarios do not necessarily hold true in developing scenarios, and additional considerations are necessary. (1) In mapping project priorities, donor resource allocation and timeframe are potentially in direct conflict with the product customer. Most donor organizations are allocated money by a government or governing body on a yearly basis. Projects then have set timeframes and budgets that dictate their activities to be completed within a fiscal year (or years) framework. (2) The PDAC-1, like most methodological design tools, makes the assumption that the design team has a high level of control over the eventual sustainability, and economic viability of a product. In a developing scenario, this is often not the case; the actions of the design team are only one of several factors influencing the product's success. External factors such as supplier reliability, skewed market forces, and government corruption will also influence the market success of a product.

6

Conclusion

Methodological design tools and techniques such as the PDAC-1 can be applicable with modifications. While tools such as PDAC-2 may also be useful, they are rarely used. The modifications necessary to make the PDAC-1 applicable to the Kenyan scenario highlighted considerations, constraints, and limitations for design teams developing products working in both industrialized and developing scenarios. Table 1 summarizes the modifications to and applicability of PDAC-1. Table 1. Summary of PDAC-1 Modifications and Applicability 1

2

3 4

5 6

7

8

PDAC-1 Strategic Alignment: Does the team understand the strategic objectives, the boundary conditions within which they need to operate, and the target market for the product? Project Priorities: Does the team have an agreed upon hierarchy of measurable priorities based on the required positioning? Resources: Does the project have the staffing and funding needed to make the project success? Management Leadership: Does the management hierarchy collectively support the project and provide unified guidance for making decisions? Dependencies: For all functional areas, are both internal and external dependencies established and working well? Competitive Analysis: Has the team identified the product's top three competitors and projected what they will be offering at the time of your product's release? Product Positioning: Does this project have a clear and compelling benefit-based positioning based on user and customer needs and competitive advantages for each market segment? Core Competencies: Are all the core competencies, required for successful deployment of your project, identified and accessible

ICED 01 -C586/410

PDAC-2 Philosophical and Action Alignment: Does The team 's strategy address and align the donor and customer objectives, their boundary conditions, and the target population of the product? (No change in wording.)

Applicability HighMedium

(No change in wording.)

Low

(No change in wording.)

High

(No change in wording.)

Medium

"Competitive" Analysis: Has the team distinguished between and identified foreign competitors, indigenous producers, and traditional practices? Product Positioning: Does this project have a clear, compelling, and immediate benefit-based positioning based on user and customer needs and competitive advantages for each market segment? (No change in wording.)

HighMedium

Medium

Medium

High

511

9

10

11 12 13

14

7

Understanding User and Customer Needs: Has the team verified the target market segment, its attractiveness in terms of size and growth rates, and identified the fundamental needs of the market, e.g. productivity, cost effectiveness, ease of use...? Risk Management: Based on the business objectives and project priorities, does the team understand the level of risk it is taking?

Localization: Are the variations in user needs and compliances understood by geography? Compliances: Has the team identified all relevant compliance standards? Business Model/Financial Analysis: Is the project's cradle to grave financial and project plan complete and accurate? Market Channels: Will the appropriate market channels of distribution be established prior to the market release?

Understanding User and Customer Needs: How has the project team identified the target populations? Are the fundamental needs and their respective drivers of the markets understood?

HighMedium

Internal Risk Management: Based on the strategic objectives and project priorities, does the team understand the level of risk it is taking? External Risk Management: What are the potential (non-obvious) risks of introducing a new product to this market? Localization: Arc the variations in user needs and compliances understood by geography and culture? (No change in wording.)

HighMedium

Exit Strategy: Is the project's exit strategy and plan realistic, complete and viable?

High

Market Channels for Sustainability: Will the appropriate manufacturing, distribution, maintenance, and marketing channels be established prior to the completion of the product?

HighMedium

High Low

Acknowledgements

The authors would like to thank ApproTEC in Nairobi, Kenya. This work was supported by the 1999 New Century Scholars Program and the United States Engineering Research Program of the Office of Basic Energy Sciences at the Department of Energy. References [1]

Atolagbe, S.O., 1989, "Product Design and Development: A Developing Country's Experience", Proceedings from the 6th International Conference on Engineering Design, Harrogate, UK

[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 and Functional 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" in ME217A Course Reader, DfM: Product Definition, Stanford Bookstore, pp3.1A.l-2

[6]

Wilson, Edith, 1993, "Product Definition: Factors for Successful Design," Design Management Journal, Fall, pp.62-68

[7]

Wilson, Edith, 1990, "Product Definition Factors for Successful Design," M.E. Thesis, Stanford University, Stanford, CA

Krista M. Donaldson Center for Design Research, Stanford University, Stanford, CA, 94309 USA, Tel: (650) 723-7908, Fax: (650) 725-8475, E-mail: [email protected] © IMechE 2001

512

ICED 01 -C5 86/410

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

AN APPROACH FOR STRUCTURING DESIGN SPECIFICATIONS FOR COMPLEX SYSTEMS BY OPTIMIZATION C Grante, M Williander, P Krus, and J-O Palmberg

Keywords:

1

Product planing, complexity management, complex design task, costestimation, product design specification

Introduction

Today's products are becoming increasingly complex with more and more features and functions. This complexity makes it difficult to determine which features to include in the design specification and which to exclude. Late implementation of features during the design process can be fatal, if not impossible, with impact on quality, lead-time, and cost. Most products have one specific function: the "primary" function that they are designed for. Other features are often added. For instance, a car is designed for travelling on roads, in addition to this, it has features such as safety and entertainment systems. By introducing electronics and computers to control mechanical products (mechatronics), many additional features, such as active safety systems emerge. The products, and thereby their design, becomes more complex in comparison with traditional mechanical systems. These features can often use the same implementers in form of actuators and sensors which makes the selection of features to include extremely complex. Research has been done in the field of engineering design leading to design processes. Making use of the design process designers can structure their work and instead of facing a large disorganised complex problem they are able to break it down into sub-parts. In design methodologies, eg, Pahl and Beitz [1], and Suh [2], the design process starts with the requirements (product design specifications). With the increasing complexity of products, the complexity of design specifications also increases, often making it too complex for the human brain to deal with. See Backlund [3]. Consequently, there is a lack of methodology in design processes for structuring design specifications that can consider different features using the same implementers for complex systems. This paper fills the existing gap by helping the designer to structure design specifications for complex products by finding "one" optimal feature set: the one that provides maximum customer value in the given cost constraints (product cost and development cost). Features selection is influenced by customer value, complexity, and additional cost. This method is for specifying these features and functions set and not for describing other requirements, eg, environmental or legislative requirements for products that Schachinger and Johannesson [4] have described.

ICED 01 - C586/428

513

2

Method

The four-step approach to research: Criteria, Description I, Prescription, and Description II, Blessing, Chakrabrit and Wallace [5], is used in this paper. The problem is described in Criteria, in the introduction of this paper. Measuring an improvement is described in Description I, our solution to the problem is in Prescription, and evaluation of methods in Description II.

2.1 Parameters for measurement of success, Description I Success of this method is achieved if the use of it improves the conditions for the company using it. Improved conditions are: increased profitability or decreased loss, increased market share, etc. Measures for these parameters are doomed to fail since the environment (all other parameters) does not remain constant. Instead the simplest and most effective measure is to compare selections previously done with the tools selection system and compare differences in cost and customer value with history and this selection method. We do not achieve any ultimate validation, but we can measure if the current method can select an improved combination of complex systems or not. To see if the method affects parameters that not are directly linked to profit, the number of design changes, time to market, and customer desire of features, were also investigated by interviews with several people who used the method in the Chassis department at Volvo Car Corporation (VCC). A simple scale containing negative effect, no effect, and positive effect was used.

2.2 Definitions All products provide the customer with one primary function and in most cases several additional features. Technical functions are needed, ie, be electronically controlled to implement features/functions such as brakes, radar sensor, and airbags in an active car safety system. One technical function can be used by several customer functions and features. See Figure 1.

Figure 1. Each ellipse represents a customer feature and each dot a technical function. If a technical function is needed to realise a customer feature it is inside the ellipse. The shared technical functions inside the overlapping segments need only be implemented once to achieve customer features.

2.3 Prescription In structuring design specifications, decisions concerning which function(s)/feature(s) to provide the customer with and how to implement them are made. The aim is to get as high a customer value as possible at a given cost. Design specifications should contain customer

514

ICED 01 - C586/428

features and technical functions that have the highest concept value in accordance with (I) and still keep within the limits stated. concept value = E(value of customer features) - (cost of technical function implementing the customer functions) (I) Mathematical model Where the value of concept customer functions = EM (Bk,i*Vj) i k M Bk,i Vi

= integer representing a specific customer feature = integer representing a specific concept = the total number of customer features possible to implement in the product = one if the customer feature i is a part of the solution k and zero if it is not = the value of the benefit that the customer feature i will provide

and the cost of the technical function for implementing customer functions

j = integer representing a specific technical function Ai,J = the coupling matrix, see 2.4, is to the value of one if the customer feature i uses the technical function j and zero if its not Rj = the cost of the technical function j x = the value of a technical function N = the total number of technical functions U = union function [6] e = member of function [6] V = all function [6] The union function is used since the customer functions can share technical functions and thereby the cost. This means that if a technical function is used more than once in a solution it still does not cost more to implement. Different limitation factors are considered by using a utility factor a. Using a, the customer features scale varies in relation to the technical cost scale. Using this approach different cost budgets can be modelled. This gives the following function:

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 is coupling that makes this method unique. Choosing which customer features to implement depends on customer value, added product cost and if different customer features can be realised using the same technical functions and thus sharing the overall cost. In the Ai,j matrix a 1 represents a customer feature using a technical function and a 0 that its not, see the

ICED 01 -C586/428

515

example in Figure 3. Note that if a customer feature is chosen to be in the solution all technical functions using it must also be implemented. Customer Function We have used two different approaches, par comparison and customer price, to generate the value of customer functions Vj. Par comparison is a subjective comparison of the customer functions in a relative scale. It was found that the evaluation matrix, Figure 2, was the best tool for this comparison. Evaluation tools using data such as the Pugh matrix [7], and the Kesselring matrix [8], lead to inconsistencies between the numerical scale created and our perception. The evaluation matrix does not have this problem since each customer feature is compared with all other features. It is also easy to use since it requires less input then second approach. The disadvantage is that it is less accurate and that many comparisons have to be made, (n2-n)/2 where n is number of customer functions.

Figure 2. Evaluation matrix. The functions A, B, C, and D are compared. Minus one (-1) in a row means that the feature in the column is preferred and vice versa for 1. Zero (0) means that none of the features are preferred above the other. Each row is added up and a relative numeric scale describing the relative importance of the features is created.

The second approach is to compare a customer desire for a feature based on the amount the customers are prepared to pay. In this case, the numerical scale is the actual price. The major advantage with this approach is the absolute scale using zero, which is not used in the evaluation matrix. Using this approach the number of "decisions" only aspects increases in a linear manner with n and also provides the possibility to predict product earnings at an early stage. The disadvantage is the difficulty in making estimations when dealing with functions that are new and have never been on the market. It is significantly easier to say if a feature is desired more or less than another one is is, than to estimate how much a customer is willing to pay for it. Technical functions The creation of a numerical scale for the cost of the technical function uses two similar approaches to the ones used for customer features. The approach that was favoured is the estimation of the cost of each technical function. In the estimation the development cost of the technical function, part cost, and product volume is considered. The other approach is comparison evaluation. It is the same technique as for the evaluation of the customer features with different evaluation criteria in the form of the complexity of the technical functions. The complexity was chosen as it was considered to be the cost driver. This second approach is used in cases where cost of technical functions has been difficult to estimate.

516

ICED 01 -C586/428

2.5 Optimisation Computations of formula (II): to find which combination of customer features is the best, increases in a linear manner with the number of technical functions and with C, see (III).

C n k

= the number of calculations for the value of concepts, ie, number of computations of (II) = the number of possible customer features - the number of customer features chosen

For small problems it is possible to calculate all combinations of customer functions but when the problem increases in size the number of computations increases rapidly, thus making it impossible for current computers to calculate within a reasonable time-frame. In order to solve these problems optimisation is used. In order to use effective optimisation techniques the problem is reformulated and is seen as continuous rather than a discrete optimisation problem. Fuzzy logic approach is used where technical functions and corresponding customer features can have values in the interval [0.1]. Since the system is linear between the optimum, the extremes are always within either 0 or 1. The COMPLEX algorithm The problem is to maximise the function:

F(X1, x 2 ... 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 the COMPLEX-RF [10] algorithm based on the COMPLEX optimisation algorithm by M. J. Box 1965, since it is suitable for this kind of problem. An initial complex of k points is generated, typically k = 2 N. The variables at each point are generated using random numbers.

j is an index that indicates a parameter set in the complex and i an index that indicates a variable, rij is a random number in the interval [0.1]. If the implicit constraints are not fulfilled, a new point is generated. The number of points k in the complex must be such that k > N + 1, where N is the number of independent variables. The object function is evaluated at each point. The point having the lowest value is replaced by a point reflected in the centroid of the remaining points by a factor: a.

Box (1965) recommends a= 1.3. If a point is repeated as the lowest value on consecutive trials, it is moved one half the distance to the centroid of the remaining points.

ICED 01 - C586/428

517

The COMPLEX-RF algorithm The main difference is: additional randomisation of new search points, this prevents the COMPLEX from collapsing prematurely. The second is: the introduction of a "forgetting factor" that gradually removes the influence of old parameter sets in the complex.

3

Example

This paper contains an example in order to understand the method more easily and it also contains an insight into a large industrial example conducted at Volvo Car Corporation. The example has four customer features and illustrates how the method works. The features and their technical functions are: Anti-lock Braking System (ABS), which prevents the wheels from locking during braking. ABS uses the technical functions Controlled Brake and Wheel Speed. Traction Control System (TCS), which interacts with the engine and brakes to prevent the wheels from spinning during acceleration. The TCS uses Controlled Brake, Wheel Speed, and Driveline Torque Estimation. Brake Assistant (BA) [11], which helps the driver to apply additional brake force in a critical situation. The BA uses Controlled Brake and Brake Pedal Position. Electronic Stability Control System (ESP) [11], which prevents the vehicle from skidding by interfering with the brakes. The TCS uses Controlled Brake, Driveline Torque Estimation, and Yaw Rate Sensor. The coupling matrix for the example, value and cost is shown in Figure 3. Note that this is an example and the values and cost are invented.

Figure 3.

Example of a coupling matrix.

In this case, using a budget of less than 2000, BA is chosen for implementation since it has the highest profit margin (2000-1000-500=500). If the budget is increased to 2500, ABS and TCS should be chosen to be implemented since they will be even more profitable (2000+2000-1000-1000-250=1750). With a budget of 3000 ABS, BA, and TCS will be most profitable with (2000+2000+2000-1000-1000-500-250=3250). The above is visualised in Figure 4. Of course all features can be implemented with a high enough budget and then this method does not serve any purpose. Unfortunately this is seldom the case. Using this example it is relatively easy to find the combinations of customer features that provide the highest profitability for limited development budgets. For a real project this is impossible because of all the combinations possible, then this method is useful. A project concerning active safety features for VCC can be seen in Figure 5, which uses the same kind

518

ICED 01 - C586/428

of visualisation as in Figure 4. The Volvo case has more than 9 x 1015 possible combinations of features that could be chosen.

Figure 4.

The optimal set of customer features using different budgets. The black marking indicates the use of the customer features. The same visualisation can be done for technical functions.

Figure 5.

Overview of an industrial application at Volvo Car Corporation. It is the same kind visualisation as Figure 4 but is for the more complex problem.

4

Result

The results of the example at VCC is shown in Figure 6 where active safety features for a car model have been selected using the current method and the method presented in this paper. The current method uses skilled people who make the best possible selection using the same criteria as this new method. The comparison above shows an average increase of 100% in customer value with sustained cost using the method presented. An interesting result is that the old method keeps selecting functions although the total profit decreases.

Figure 6.

ICED 01 - C586/428

Feature selection using current method at VCC compared with this method.

519

There are also other influences on the parameters. One positive aspect was the number of design changes. A reduced number of design changes were made in the project. There was no measurable effect on time to market and it had a positive effect on customer desire of features that were implemented in the product. Other results that could be seen: the designers found it positive to focus on the technical functions instead of the customer features/functions, which they do at present.

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 method had an effect on other parameters that not are directly linked to profit. It was found to have a positive effect on a number of design changes and customer desire of features, but changes in time to market could be seen. By using this structure when making product design specifications for complex systems it is possible to choose an improved set of features and functions to be implemented in product design specifications. This will lead to a reduction in late changes, products of greater value for the customers, and higher profit margins for the manufacturers. References [1]. Pahl and Beitz (1996), Engineering Design, Springer-Verlag, London [2]. Suh (1990), The Principles of Design, Oxford University Press, New York [3]. Backlund (2000), The Effects of Modelling Requirements in Early Phases of BuyerSupplier Relations, Department of Mechanical Engineering, Linkoping University [4]. Schachinger P. and Johannesson H. (1999), A Method for Computer Based Specification of Products, Department of Machine- and Vehicle Design, Chalmers University, Goteborg [5]. Blessing , Chakrabarit, and Wallace (1998), Designers - the Key to Successful Development, pages 56-70 , Springer-Verlag, London [6]. Wordsworth (1996), Software engineering with B, ISBN: 0-201-40356-0, Addison Wesley, United Kingdom, [7]. Pugh,(1990), Total Design, Addison-Wesley, Workingham [8]. Ulrich and Eppinger (1995), Product design and development, McGraw-Hill, New York [91. Hayter 1996, Probability and Statistics, PWS Publishing Company, Boston [10]. Box (1965), A new method of constraint optimisation and a comparison with other methods, Computer Journal 8:42-52. [11]. Isermann (2000), Diagnosis Methods for Electronic Controlled Vehicles, AVEC'2000, Ann Arbor Christian Grante, Dept. 92410, PVH 31, Volvo Car Corporation, S-405 31 Goteborg, Sweden. © IMechE 2001

520

ICED 01 - C586/428

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

AN ENGINEERING APPROACH FOR MATCHING TECHNOLOGY TO PRODUCT APPLICATIONS J B Larsen, S P Magleby, and L L Howell

Keywords: Systematic product development, innovation methods, design management, economic viability of new technologies, product planning

1

Introduction

Most formalised product development processes are oriented towards an initial focus on the customer of the product. These processes are often categorised as "market-pull." This customer-orientation is generally justified as starting development from the customer side provides a basis throughout the process for evaluation of design alternatives and assessment of product performance. Common wisdom among marketers and product developers is that the market-pull approach yields more "successful" designs than alternatives. This singular view of product development processes neglects the strategies and needs of organisations that create and/or own technologies that they wish to capitalise on by making them an integral part of a product. Product development processes that are oriented towards an initial focus on the product embodiment of a technology are often categorised as "technology-push" [1]. Most companies do not pursue this type of development in a structured way because of the lack of defined processes and risks of missing market needs. Despite the market-related risks of executing this type of development, if well done it can present enormous benefits to an organisation. Besides helping ensure successful development of a technology, it also facilitates the creation of lucrative new markets and spreads research costs over a broader product base. While there has been much work done on topics that are related to development of new technologies and the associated need for innovation, there has been relatively little discussion on the technology-push product development process from an engineering point-of-view. Development of such an engineering design process is not trivial as it presents a number of challenges not inherent in the market-pull approaches [2]. The objective of this paper is to develop and present a practical process for accomplishing "technology-push" product development. The key aspect of the process that will be explored is how to find a focus for the viable product options that could embody the technology. This will be accomplished by first reviewing past research in relevant areas. Then the flow of information through the two types of product development processes discussed above will be decomposed. Based on this information flow, a generic technology application selection process is formulated. Finally, a method for evaluating the appropriateness of a given product application for a technology is presented.

ICED 01 -C586/643

521

2

Background and Literature

There are four major fields of study the authors have found that impact and provide a background for definition of a technology-push product development process. This section briefly addresses design processes in general, research directions in innovation, technology transfer as an activity, and a field called Technology Integration.

2.1 Design Processes While there are a wide variety of design processes presented in literature, most all of them are initiated with customer/market data. Take for example the widely recognised process presented by Ulrich [3]. In their Concept Development stage, the first step they propose is to "Identify Customer Needs." All subsequent steps build on this foundation of customer needs, establishing a coherent development direction based on the voice of the customer. Despite the potential effectiveness of developing a product in this way, often companies have a technology they wish to embody in a product(s), without foreknowledge of the customers. A structured, engineering process for accomplishing this is not available in current literature.

2.2 Innovation Innovation can be defined as the creation of a new concept and making it commercially viable. Technology-push product development can be considered a subset of this broad field of innovation. While much has been written about different methods for innovating, little has been written on this particular category of innovation. Other forms begin with a sensed need or target customer and look for a technological solution. This form begins with a specific technology and searches for customers who have a corresponding need.

2.3 Technology Transfer Recognising the importance of technology as an input to the product development process, most companies seek to develop new technologies internally. Because the processes for technology development versus product development are so dissimilar, the two are usually organisationally separated from each other. To make the transition from technology development to product development, many have engaged in technology transfer, a method for taking the knowledge generated in the former stage and embedding it in a development team that can take it to market. The problem with this, however, lies in the fact that the development is usually targeted to one product, prematurely narrowing the application options and stimulating biased evaluation of the technology feasibility. Despite the applicability of technology transfer concepts, technology transfer does not preclude the need for a formalised application selection process prior to full-scale development for technology-push projects.

2.4 Technology Integration Recent studies by Marco lansiti of the Harvard Business School [4] support the idea that a distinct process is needed to manage the integration of technology from research into development. lansiti even recommends the establishment of a separate organisation to hold responsibility for technology integration. This article supplements lansiti's strategic, organisational insights with a practical, executable engineering process.

522

ICED 01 -C586/643

3

Information

The product development process deals with a myriad of information. The "process" itself is simply a way of creating and arranging this information so it is available to facilitate decisions at appropriate times [5]. The technology-push process can best be understood through an analysis of the input information and how it is used throughout. This section decomposes the general information types, explains how information flows through the process, and contrasts this with market-pull development.

3.1 Information categories An analysis of the development process shows that information involved in the process can be grouped into four basic categories associated with the following: 1. Customer - the intended purchaser or user of the product and other stakeholders 2. Needs - the specific objectives a customer(s) seeks to fulfil with a product and desired attributes of the product 3. Product - technology embodiment, intended to satisfy customer needs 4. Technology - the application of scientific knowledge Based on these designations, product development could be defined as "the realisation of a product through embodying technology in a manner meant to satisfy customer needs." Technology-push product development is "the realisation of a product through embodying a specific technology in a manner meant to satisfy customer needs." Market-pull is "the realisation of a product through embodying technology in a manner meant to satisfy needs of a specific customer set." The fundamental difference between market-pull and technologypush is not the type of information dealt with, but rather the informational starting point and thus how it is processed.

3.2 Information flow Essential to understanding how this information is processed is the order in which it is encountered and utilised. While information from each of the categories shows up throughout the process, most of the major steps can be classified by the category of information primarily dealt with. Using the information categories, the flow of information is outlined below. A market-pull project begins with a set of target customers. From this customer set, developers ascertain the needs they intend to satisfy (step 1). Then using these needs they establish guidelines (specifications) and architectural concepts for the product (step 2). Technologies are identified to fulfil the concepts generated (step 3). Upon selection of the optimum architecture (technology integration), developers design the product and production processes (step 4), evaluate the product against customer needs (step 5), and deliver it to the customer (step 6). Figure 1 gives a graphical representation of the first three steps of this process, with the steps being numbered. For the sake of this article, we will focus only on these steps as this is where initial information in all four categories is obtained. Consider, on the other hand, how information should flow through the preliminary stages of the technology-push process. The order is significant primarily as it relates to the ease of progression. The end objective is to have sufficient knowledge about each information type to be able to decide whether or not to pursue full-scale development of an application. Below is

ICED 01 - C586/643

523

outlined the flow that seems the most executable and logical to obtain the information necessary for such a decision.

Figure 1. Information flow in a market-pull product development process

Rather than starting with a set of customers, technology-push begins with a given technology. From the functionality and characteristics of the technology, the developers can derive needs that it satisfies (step 1). They then are able to choose a product embodiment of the technology to meet the needs (step 2). Next they identify customers who possess the needs and thus would desire the product (step 3). Now that a suitable customer has been identified, development can continue much the same as if the project were market-pull. The project has transitioned from being technology-push to market-pull.

Figure 2. Information flow in a technology-push development process

3.3 Information management As has been demonstrated, the two processes both deal with the same types of information. However, technology-push seems to be significantly more difficult to complete. This variation in difficulty level lies in the way information is evolved. The steps in market-pull are discrete and executable, while those in technology-push are comparatively vague and uncertain. Marketers have methods to find the needs of a given customer base, but lack repeatable ways to find potential customers given a certain set of needs. Given a product architecture, designers can find technologies that correspond to their needs, but identifying suitable product applications given a single technology is more difficult. Another way of saying this is that each of the "queries" in a market-pull process is more clearly bounded than in technology-push. Needs are bounded by the customer base and technologies are bounded by the product needs. For technology-push, on the other hand, product applications are bounded only by generic characteristics of the technology and potential customers are bounded only by generalised needs. Given a set of customers, it would

524

ICED 01 -C586/643

be relatively easy to determine their primary needs for a product. Taking the same set of needs, though, it would be quite difficult to determine the customers that possess them. Nonetheless, the greatest obstacle for technology-push, its open-ended nature, also creates the greatest opportunity for those who can successfully execute it. Rather than limiting, it opens up the field of potential customers, allowing an organisation to leverage its current resources and capabilities for much greater profits. It also leads to revolutionary, not just evolutionary, products. It facilitates using a technology investment for many projects, rather than just the initial one it may have been intended for. It motivates people to explore technological opportunities and exploit all possible applications. The challenge lies in finding ways to quickly identify and evaluate application opportunities with an open-ended project.

4

A Generalised Technology Application Selection Process

The information presented so far lends itself to the creation of a process for technology-push product development. Our focus will be on matching technologies to product applications. This will be accomplished by presenting a technology application selection process that takes place before full-scale development. Following are the general phases that each project should pass through. These phases are illustrated in figure 3.

Figure 3. Technology-push product development process Transfer from Technology Development, Transfer to Product Development

The initial transfer into and final transfer out of the process require special considerations. This process boundary will not be explored in detail, but is a potential area for future research. The principles of technology transfer would likely apply well to these transitions. Technology characterisation

When an organisation has a technology to develop, they should begin by characterising it. This consists of not only understanding the basic scientific founding, but also translating the functionality and properties into needs the technology could satisfy. While this may start with generic descriptions of the technology, a development team should seek to evolve these into as specific categories as possible to ease the difficulties of being open-ended. Knowledge about the technology must be evolved into knowledge about the needs it can fulfil. Application identification

Using needs generated in the first phase, a team generates product ideas (technology application concepts). This should be an open-ended phase with focus more on quantity than quality. This should be a creative stage, where structure is undesirable, as it inhibits the creative process. The creativity of this stage makes it inherently difficult to systematise. The needs derived in the characterisation stage should lead to products that fulfil them.

ICED 01 - C586/643

525

Application evaluation Next the application concepts must be evaluated for viability. Note that while the traditional development process focuses on narrowing down concepts to make only one final product, the multiple concepts generated by this process should be evaluated and pursued separately. This is why objectivity is particularly important, but difficult in technology-push product development. This "application evaluation" phase is a milestone determinant of product development success. If only suitable applications are allowed to pass, the projects are likely to prove successful. If too many applications are denied, the organisation has foregone attractive opportunities. In evaluating the feasibility of a project, it is particularly important to ensure that it can transition from technology-push into market-pull. To do so, suitable customers must be identified and the concept must be evaluated based on their tastes. This phase is discussed in more detail below.

5

Application Evaluation

As mentioned above, the application evaluation stage has a particularly strong influence on the eventual outcome of a project. This section assesses different approaches for evaluating a given application.

5.1 Scoring A common way to simplify complex decisions based on various factors is by weighting and scoring. For design decisions, many people use concept scoring matrices to select the "best" concept. A designer would weight the various specifications or needs by importance and score each of the concepts for the different factors. These scores can then be compiled to give an overall rating for the product [3]. Scoring is particularly relevant to technology-push project evaluation because of the wide variety of considerations that come into play when assessing project viability. These issues include strategic, organisational, legal, market size/readiness, safety, environmental, competition, function, durability and many others [6]. While scoring is extremely useful for comparing a wide variety of alternatives using many criteria, technology-push projects should not necessarily be evaluated relative to other concepts, but rather for their independent viability. The purpose of application evaluation is not to select from multiple alternatives, but to assess the viability of each individual alternative. If ten concepts seem likely to prove profitable in the long-term, why should they be narrowed down to the top two or three?

5.2 Financial Viability The fundamental motivation for most organisations to limit investment is scarcity of capital. For this reason, viability is primarily determined by financial considerations. The most common management method for ascertaining financial viability is the Net Present Value (NPV) method. This uses the concept of the time value of money to determine if an investment is more profitable over time than other possibilities. To compensate for the inability to evaluate all other possibilities for the sake of comparison, a context-specific

526

ICED 01 -C586/643

discount rate (usually a weighted average cost of capital) is chosen to evaluate each project individually. In this way, a general alternative is used to which all possibilities are compared. Recognisably, many of the factors mentioned in the scoring section above largely govern the expected financial performance. The method's comprehensiveness is also its greatest weakness. The calculated value of a project is wholly dependent on the underlying assumptions; the overarching calculations merely propagate or accentuate any inaccuracies. Additionally, generating the values usually requires significant time and energy. In order to minimise the time and energy used to evaluate a concept while still getting a reasonable estimate for the viability, we delve into the factors that seem to govern performance. Specifically, we want to look at the functionality of a given technology in a certain product application.

5.3 The Function Gate Certainly, function would be a heavily weighted factor if we were to use a scoring matrix to select a potential application. An assessment of functionality would also determine many of the assumptions on which an NPV analysis would be based. These perspectives, however, lump functionality in as a slice of the overall pie, failing to recognise it as a prerequisite for the pie. If a technology does not have the desired functionality for a certain application, it will not satisfy the customer needs regardless of how it is embodied. Distinguishing functionality as a prerequisite rather than simply a contributory factor, establishes several major benefits. Most importantly, it filters down the aspects to be taken into consideration, greatly simplifying the decision-making process. Secondly, it clearly delineates the benchmark product, making competition and customers much more explicit and the subsequent assessment more accurate. Thus it accomplishes the purpose of application evaluation as explained in the process section of this paper—it moves the team from product knowledge to customer knowledge. Finally, it builds on the information already developed in the technology-push process, which was founded on an understanding of the technology and how its functionality could satisfy customer needs. Recognising the function gate as the preferred method for initially evaluating a technology application, functional decomposition can be used to evaluate functional performance [7]. This can be done by first identifying the product "flows". Flows include energy, materials, or signals that go into and come out of the system. From these system-level flows, a function chain should be developed to represent the different transformations that take place within the system to accomplish the overall transfer function [8]. The precise functions accomplished by the technology should be mapped out to make the functional boundary explicit. It is also important to identify product constraints and distinguish them from flows. Constraints are holistic characteristics that apply to the whole product—such as cost or weight. Each part within the system contributes to the overall constraint characteristic. By characterising both the flows and system constraints, we gain a clear understanding of how a given technology functionally compares to the incumbent technology in a specific application. Functional decomposition establishes a clear delineation of the benchmark a technology is meant to replace. The difficulty of potential development is reflected in the level of complexity of the benchmark. If the technology simply replaces an existing component, and meets all interface requirements in the current architecture, development should be relatively

ICED 01 - C586/643

527

simple. If it replaces a system within a product, effecting a change in the product architecture, development will be more difficult. Finally if the selected application is a replacement of an entire product or is a new product altogether, the development will be more difficult than either of the two prior scenarios.

6

Conclusion

Various processes have been developed to systematise product development. Most of these focus on market-pull development because customer demand is necessary for successful commercialisation. Technology-push development begins with a technology rather than the customer, but the same categories of information are dealt with as in market-pull development. While the open-ended nature of technology-push development makes it more difficult to successfully complete, its unrestricted nature also opens many opportunities for leveraging technology development to access new customers and new products. Based on the flow of information through the development process, a generic process for technology-push development was presented. One of the crucial steps in this process is application evaluation. Methods for effectively evaluating the viability of technology applications were assessed, with the functional gate being the most fitting. References [1]

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 the View in Systems Development - Technology Development at the Fuzzy Front End as a Key to Success, Proceedings, 1999 ASME Design Engineering Technical Conferences, Las Vegas, NV.

[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 Dynamic World, Harvard Business School Press

[5]

Mistree, F., W. F. Smith, B. A. Bras, J. K. Allen and D. Muster (1990). Decision-Based Design: A Contemporary Paradigm for Ship Design. Transactions, Society of Naval Architects and Marine Engineers 98: 565-597

[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 Technical Conferences.

[8]

Kurfman, Mark A., Stone, Robert B., Van Wie, Mike, Wood, Kristin L., and Otto, Kevin N., 2000, Theoretical Underpinnings of Functional Modeling: Preliminary Experimental Studies, Proceedings, 2000 ASME Design Engineering Technical Conferences, Baltimore, MD.

Spencer P. Magleby Brigham Young University, Mechanical Eng. Dept, 435 CTB, Provo UT 84604 U.S.A., voice: (801) 378-3151, fax: (801) 378-5037, [email protected] © IMechE 2001

528

ICED 01 -C586/643

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

FINANCING INNOVATION IN CO-OPERATION PROJECTS P Link and S Spiroudis

Keywords: Industrial co-operation - investment appraisal - virtual enterprises

1 Introduction In Switzerland and Germany different Virtual Enterprises emerge. One of the main issue of such Virtual Enterprises is the production of goods one company alone is not able to produce. They are combining their competencies and capacities for production. One company acts as lead, makes the offer, negotiates with the customer and when it comes to the deal, takes all the risks. Sometimes certain development expenditure is necessary in order to be able to produce the product. There is of course a risk, mainly of technical nature, to exceed the agreed payment. Innovation projects are different. In innovation projects a company spends money before being sure how to sell the product at all or how to cover sufficiently the expenses. In collaborative new product development (CNPD) the costs and the gains, the risks and the reward need to be shared. CNPD therefore demands a high level of trust and familiarity with the partner and his skills. Existing Virtual Enterprises offer a highly interesting platform for collaborative new product development since there is a close personal relation and the partner's skills, capacities and competencies are well known. Combining the competences of the network, partners can create competitive advantages. Especially small and medium sized enterprises (SME) can benefit from chances which they could not realise alone, since really innovative projects require a lot of development work or even basic research. Bigger projects can be realised, when the partners can agree on the financing structure. There may still be a need for an external financing.

2 Financing innovations From a general financial point of view innovation projects must be financed with proprietary capital [1]. Credits are given only against sufficient liabilities. The required capital can come from inside the company (self-financing) or from outside in form of a participation capital. In this case the financing partners expect an appropriate participation in the project reward. Equity investment in young private companies is generally known as venture capital [2]. Within this chapter the classical capital sources, venture capital, private equity and business angels, are shortly described.

ICED 01 - C586/315

529

The typical attributes of venture capital are the following: Participation: The investors participate significantly. He bears the full risks. Management-support by the venture capitalist: The investor actively supports the enterprise. Most of the time he is part of the board. Shareholder contract: The participation is secured with different contracts (pre-emptive right, the power of veto for important decisions, monthly reporting etc.). Exit-regulation: Already at the beginning of the project the exit of the investor is planned. Usually a venture capitalist seeks to sell his shares (e.g. IPO) The venture capital market is rapidly growing in Europe (see figure 1).

Figure 1: Private Equity und Venture Capital Investments in Europe [3]

On one side private equity stands for investment in more mature, not stock quoted enterprises. On the other side, venture capital means investments in fast growing, young and innovative companies in an early stage [4]. In order to receive venture capital the enterprise must have a detailed business plan, sometimes even a prototype and seriously interested lead users. It is getting increasingly uncommon that venture capital is given in an earlier stage. People who invest earlier (seed stage) are called "Business Angels". They always have experience in the specific branch, experience (e.g. from a former own entrepreneurship) and money to invest. Business angels sometimes do not need a written business plan and are able to take their decision on a fast and informal basis [5]. They often have also a high personal interest beside the financial gain. 75% of the business angels invest between 15'000 and 150'000 Euro [6]. The business angel market starts to get better organised in continental Europe. Great Britain has a competitive edge in this field. Different financing stages or investment stages can be distinguished in a company's life cycle (see figure 2). Thereby the seed stage consists of the financing of the elaboration of a concept up to the prototype. In the start-up stage usually the enterprise needs capital for the market launch.

530

ICED 01 - C586/315

Figure 2: Comparison of financing source, financing stage and innovation stage

3 Financing innovation projects The classical project financing is only used for very large projects (investment > 10 Mio Euro). So-called "special purpose vehicles" are created [7]. All partners found a company together. It is not efficient founding companies for each project until it is not sure that the project will be realised. The classical characteristics of project financing are Cash Flow Related Lending and Risk Sharing [8]. These elements are also found in the financing of innovation projects. Figure 2 compares the financing sources both the financial and the innovation stages. The innovation process is based on the 5-stage-gate-process of R.G. Cooper [9]. The possibilities of financing innovation projects in early stages are limited. Business angels focus on new enterprises. In later stages there is a minimal investment. Below this the costs are higher than the possible revenues. There is a financial gap for small and medium sized projects (< 500'000 Euro) and for early stage financing of low-tech projects. 18% of the European manufacturers mentioned in a survey concerning innovation carried out by EUROSTAT that the lack of suitable financing sources lead to significant longer project duration [10]. The main issue is the 'chance/risk relation'. If this relation is unfavourable, there are not many possibilities of getting capital. Within low-tech fields the chances are often judged to be insufficient anyway. Early stage financing (pre-seed and seed money) is widely used for the fast growing industrial sectors biotechnology and health care. Even companies of the hightech and IT/Internet sector find it difficult to receive seed money. For the low-tech sector it is out of reach.

ICED 01 - C586/315

531

The finance institutes need to carry out some structural changes to be able to offer smaller venture investments. One way is of course the standardisation of the investment appraisal process, but these possibilities are rather limited. A second option is outsourcing. External partners execute the appraisement of the project. These partners may be paid only if the project succeeds. In this case they also participate in the project. These partners must bring in added value in form of branch experience, technical and/or market knowledge. In the following paragraph the idea of a financing network is presented. The industrial partners, different service providers, basically finance the investment [11]. The financial service provider coaches the financing process and of course participates in the investment (see figure 3).

4 Financing network 4.1 Basic idea The financial service provider could be a bank, a venture capitalist or an insurance company. It can be very useful to integrate both, banks and insurance in the network, depending if more support on the financing or insurance side is required. Insurance companies often have strong risk management skills. A venture capitalist can be included for the financing of the expansion stage. The differences between classical banks and insurances are getting smaller.

Figure 3: Financing Network

Within the network a "special purpose vehicle" is created similar to BOT (build-operatetransfer) projects [12], [13]. The network has the following characteristics: Participation of all partners (initiator, primary partner, technical, marketing and financial service providers) in the up- and downside risks (losses and gains) of the project Fair and transparent risk sharing agreements Revenues are related to the cash-flow Optimal know-how combination and added value generation Networking in a bigger network of economically independent companies Commitment and major interests of all partners resulting from participation in the project performance

532

ICED 01 - C586/315

Formation of the collaboration according to the requirements of the projects (see figure 4) Informal agreements are possible, a strong culture of trust exists

Figure 4: Financial network as a virtual enterprise

4.2 Tasks and responsibilities of the involved partners in the early innovation process In the idea filter (Gate 1 of the innovation process) the most interesting projects are chosen according to different criteria (e.g. success chances, strategical focus, feasibility, market attractiveness, competitive advantage). After a project has been chosen, the preliminary investigation begins. Different tasks have to be carried out by the partners in the network (see figure 5). Initiator

Financing SP

Marketing-SP/ Technical SP

Rough Capital Budgeting

Rough market analysis

Estimation of the expected earnings

Rough competition analysis

Formulation of the project objectives and strategies Intuitive Risk analysis Operative project management Preparation of the presentation

Characterisation of the market segments

Primary partner Determination of project-specific synergies Determination of complementary core competencies Preparation of the presentation

Evaluation of the technical feasibility Check the state of technical knowledge Preparation of the presentation

Figure 5: Checklist of the tasks in the first stage ("preliminary investigation") of an innovation process

The next stage according to Cooper's innovation process is the stage of building the business case. In this stage a detailed investigation takes place and the project is defined in detail. In

ICED 01 - C586/315

533

this stage a considerable amount of capital may be needed. The sharing of possible losses or gains is defined for the first time. From now on, at each gate, the risk and reward sharing agreement has to be reconsidered. Depending on the accumulated costs, the taken risks and the estimated further expenses the reward and risk sharing agreement may be adapted. It is important, that at any time of the innovation process the sharing agreement is clear. If a project needs to be stopped, the sharing of the accumulated costs are clear. Otherwise there will be discussions who has to cover which costs. Initiator Building detailed business case Specification of the project structure Detailed capital budgeting Creation of a risk factor list Operative project management Preparation of the presentation

Financing SP Coaching the making of: - planned income statement planned balance sheet cash flow statement - determination of capital need Determination of useful contacts Determination of suitable financing concepts Determination of potential investors (business angel, venture capital)

Marketing-SP/ Technical SP Detailed market analysis (size, growth, trends) Detailed analysis of competitors (market players, market share) Determination of appropriate marketing strategies Preparation of the presentation

Primary partner Offering the core competencies Determination of potential customers Determination of useful contacts Preparation of the presentation

Figure 6: Checklist of the tasks in the "detailed investigation" stage of an innovation process

Similar to the different financing rounds in a venture capital project, the value of the work already done has to be calculated (=pre money-value). For the estimation if the pre moneyvalue not only the cumulated expenses but also the value of the elaborated know-how is considered. In a financing round the investor brings in a certain amount of capital. The sum of this capital and the pre money-value is named post money-value. The participation is calculated based on the ratio of the postmoney-value. Different sharing philosophies are possible. Each company carries its own risk (no risk transfer), the risks are beard solidary, and some risks are shared according to a defined sharing rate. The total amount of the risks may be considered for the reward sharing. Another option is an incentive agreement where only parts of the risks are considered. At least one can say that the risk and the reward sharing are interdependent and have to be set together. The sharing philosophy must be clear and fixed from the beginning.

534

ICED 01 - C586/315

4.3 Requirements This concept can only be used in practice when the following requirements are fulfilled: High level of personal and system trust Collaboration experience of all partners Commitment of all partners Knowledge of the skills and capacities of the involved partners Participation in bearing the loss and sharing the reward Transparent and fair process

4.4 Advantages of virtual enterprises for the financial service provider Virtual enterprises fulfil most of these requirements. Every partner is known very well from a technical and cultural point of view. There is sufficient trust and experience between the partners. Trust can easily build up when a new project is started. Virtual enterprises combine the strength of a stable network by offering member companies a stable environment, the close and trustworthy co-operative culture of an internal network, and the flexibility and competitiveness of a dynamic network [14]. Existing virtual enterprises, which focus on production at the moment, could move forward and make a higher added value by offering own products and combining their competencies. For a financial service provider there are some obvious advantages as well: Simplified access to innovative projects (information advantage) Participation in attractive business Configuration of the project in early stages Possibility of participation or credit financing in a later stage with less acquisition effort Correspondence to the pay-off structure of a call option - Investment (participation) corresponds to the option-price (limited downside) - Future opportunities (unlimited upside) The financial service provider could also take the role of the house bank of an existing virtual enterprise or offer a platform for other enterprise networks.

5 Conclusion There are not only advantages of such a virtual enterprise including different service providers who participate in the gain and losses of innovative projects. The following difficulties remain: Complex contracts: The use of standardised contracts without a detailed specification. Definition of the project goals and risk sharing agreements: A transparent and clear process is required. Decision making with many partners involved: An independent co-operation manager or conflict mediator can help reaching an arrangement

ICED 01 - C586/315

535

Nevertheless such a financing concept allows to realise innovation projects, which are too big for a small or medium-sized enterprise (SME) and contributes therefore to economic wealth. Additionally, an interesting rate of return is offered for investors. At a later stage, a financial institute could even promote an investment fund, which invests in existing SME and their most innovative projects. At the moment there are efforts in integrating a bank in an existing virtual enterprise (consisting of only production companies) as a kind of a "house bank". References [1]

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); ,,Yearbook 2000," Vanden Broele Graphic Group, Bruges, 2000

[4]

European Council of Applied Sciences and Engineering; ,,Engineering and Venture Capital in Europe," Euro Case Venture Capital Steering Group, Paris, 1998

[5]

Lipman, Frederick D.; ,,Financing Your Business with Venture Capital," Prima Publishing, USA 1998.

[6]

LIFT; ,,Financing Innovation - A guide. Linking Innovation, Finance and Technology," Luxembourg, 2000.

[7]

Tytko D.; ,,Grundlagen der Projektfinanzierung," Schaffer-Poeschel, Stuttgart, 1999

[8]

Finnerty J. D.; ,,Project Financing," Asset-Based Financial Engineering, John Wiley & Sons, New York, 1996

[9]

Cooper, R. G.; Product Leadership. Cambridge, Perseus books, 2000

[10] Community Innovation Survey, "EUROSTAT: Theme 9 / Innovation," European Commission's Innovation Programme, Luxembourg 2000. [11] P. Letter and C. Luchetti; "Finanzierungscoaching fur KMU," Management & Qualitat, vol. 2, pp. 4-8, 1999. [12] F. Nicklisch; "BOT-Projekte: Vertragsstrukturen, Streitbeilegung," Betriebs-Berater, pp. 2-12, 1998.

Risikoverteilung

und

[13] M. Sosic, L. Albisser, W. Baumgartner and R. Baumgartner; "Project finance The added value of insurance," Swiss Reinsurance Company, Zurich, 11/99 1999. [14] U. J. Franke; "The virtual web as a new entrepreneurial approach to network organizations," Entrepreneurship & Regional Development, vol. 11, pp. 203-229, 1998. Patrick Link and Spyros Spiroudis Federal Institute of Technology Zurich (ETH Zurich) Department of Industrial Engineering and Management Zurichbergstrasse 18, 8028 Zurich, Switzerland Phone: ++41 1 632 05 47, Fax: ++41 1 632 10 45 E-mail: [email protected]. URL: http://www.innovatik.ethz.ch C Patrick Link 2001

536

ICED 01 - C586/315

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

PERFORMANCE MANAGEMENT AT DESIGN ACTIVITY LEVEL F J O'Donnell and A H B Duffy Keywords: Design Management; Design Development; Performance.

1

Introduction

The overriding aim of much of the engineering design research is to improve the performance of the design process, and consequently the product development process. Much has been written within the product development literature on the performance of the product development process [1]. This work has been largely focused on the analysis of performance at the project or program level. The ability to relate the different research and draw generic lessons from the results has been stifled by the lack of consistency on the meaning of performance both at a generic level [2] and more specifically in design/development [3]. For example, although product and process performance have been distinguished within existing work we are unclear on how these relate or may be managed effectively. This paper begins with a brief review of research in the area of performance, with particular emphasis on design/product development, highlighting the main weaknesses in work to date. A fundamental and generic model of performance, related to knowledge based activities in design, is then presented. The model describes performance in terms of its key elements, efficiency and effectiveness, and provides a basis for modelling performance across different process levels, i.e. project, program, etc.

2

Research in design performance

The research reviewed here forms part of the overall research in the area of performance of organisations. Some of the work is generic in terms of being applicable across all business processes while other work is aimed at more specific processes such as product development, design, manufacturing, etc. (Figure 1). Within such areas the type of research and focus may vary widely and include empirical studies aimed at determining relationships between performance in different processes, the design and implementation of approaches for measuring performance, the development of theoretical performance models, etc.

2.1 Trends in Performance Research There has been considerable research published in the area of performance, e.g. Neely [2] identified that between 1994 and 1996 some 3,615 articles on performance measurement were published. He refers to the growth in membership of accountancy institutes, and number of conferences on performance, as indicators of the increased interest in this area. However, in comparison to areas such as manufacturing, measuring the performance in product design is relatively undeveloped. For example, at the recent PM2000 conference in the UK there were

ICED 01 - C586/442

537

no papers focused specifically on the analysis of design development performance from a list of over 90. Many authors have recognised the particular difficulties in measuring the performance in design/development activities [4-6]. These difficulties arise from the less tangible nature of outputs from design activities, i.e. knowledge, the often long duration and wide range of influences from design to market launch, the difficulty in defining/measuring design quality, etc.

Figure 1. Areas and Types of Performance Related Research

The decline of management accounting as the only way to measure business performance is an indication of the move toward measuring less tangible aspects of performance, e.g. those related to knowledge intensive activities in design. Johnson and Kaplan [7] suggest that traditional accounting methods are unsuited to organisations where the product life cycle is short and research and development assume increased importance. Within the scope of this paper two areas of existing research in performance are briefly reviewed, i.e. the definition/modelling of performance and the relationship between design and design activity performance.

2.2 Defining and Modelling Performance The literature on performance is characterised by a lack of, and inconsistency in, definition of terms. Numerous works have been published which directly address the area of performance but do not explicitly define performance itself. Neely [8] in his review of performance literature suggests that "Performance measurement is a topic which is often discussed but rarely defined". Meyer [9] suggests that there is "massive disagreement as to what performance is" and that the proliferation of performance measures has led to the "paradox of performance", i.e. that "organisational control is maintained by not knowing exactly what performance is". That is, the lack of a comprehensive understanding of performance can often lead to ignorant acceptance of particular approaches, metrics, etc., proposed by senior management in an organisation. The authors defining performance in terms of its key dimensions (metrics) primarily describe those dimensions within the areas of Time, Cost and Quality. The dimensions of time and cost can be relatively easily understood and applied within performance measurement but the concept of quality is somewhat similar to performance itself in terms of its varied interpretation, and the alternative measures used in its evaluation. In some of the literature, dimensions such as Focus in Development, Adaptability and Flexibility have been used. These metrics do not measure performance itself, but rather act as influences on it. For example, flexibility is only appropriate within an environment where changes are required and

538

ICED 01 - C586/442

the capability for a process, such as design or manufacture, to change rapidly may add unnecessary cost/overhead in a stable environment. Flexibility will influence the performance, i.e. efficiency and/or effectiveness of an activity/process, but does not constitute a dimension of performance itself. In summary, the research in performance has been hindered by a lack of clarity on its meaning. In particular: The key elements of performance have not been consistently defined or agreed. Those defining performance as efficiency and effectiveness have not distinguished them clearly and/or related them within a formalism of performance. Many of the measures used in the research relate to influences on performance and not performance itself.

2.3 Design and design activity performance Design activity modelling has received significant attention over the years aiming at the development of both descriptive and prescriptive models. This has resulted in the development of models offering different viewpoints of the design process such as the prescription of the activities/stages in design and their logical sequence, others focused on the cognitive nature of design and those relating design within an overall model of product development. These models are aimed at increasing our understanding of design (descriptive), and/or providing a framework (procedures, guidelines, etc.) in which to carry out design (prescriptive), so that the level of performance may be maintained or improved. However, performance in design requires continued attention to both the design (artefact) and the activities involved in producing that design. That is, both design (DG) and design activity goals (DAG) exist within design development and performance in relation to these goals must be distinguished yet related to overall performance. Design goals relate to aspects of the design (artefact) such as its dimensions, its form, etc. while design activity goals relate to the activities in design development and consider aspects such as the time taken and cost of resources. There is a reasonable consensus within existing models on the types of activities involved in design, their sequence, etc., and the evaluation of the output in relation to the design goals is a key component of the models discussed. However, the analysis of performance in relation to the activities carried out in design is restricted to literature addressing the management of design at the project level, e.g. [10]. It is proposed here that management activities are carried out at every level in design and therefore there is a requirement to analyse performance in relation to such activities at all levels.

3

A design performance model - E2

Although there is widespread use of efficiency and effectiveness to describe performance there are a variety of interpretations of these terms when applied in design and development. Efficiency (n) and effectiveness (II) are presented here as fundamental elements of performance which may be used to fully describe the phenomenon. That is:

ICED 01 - C586/442

539

Design Performance = Efficiency (n) and Effectiveness (II)

A new model, E2, is presented here as a novel and unique means to clearly formalise the phenomenon of design performance and allow efficiency and effectiveness to be distinguished and related. Efficiency is related to input, output and resources, while effectiveness is determined by the relationship between output and goal(s). These elements are presented within the E2 model providing a fundamental representation of activity performance.

3.1 Efficiency In general, the efficiency of an activity is seen as the relationship (often expressed as a ratio) between what has been gained and the level of resource used. Assuming design as a knowledge processing activity (Ak) (Figure 2), the difference between the output (O) and the input (I) defines the knowledge gain from the activity (K + ). The cost* of the activity may be determined by measuring the amount of resource knowledge used (Ru). Therefore, the efficiency of this activity may be depicted as in Figure 2 and formulated as a ratio:

Where: n(Ak) I O K RU

: Efficiency (n) of an Activity (Ak) : Input (Knowledge) : Output (Knowledge) : Knowledge Gain : Resource (Knowledge) Used

Figure 2. Efficiency (TI)

This formalism assumes that a quantitative comparison of the input and output knowledge can be carried out that results in a description of the level of knowledge gained in the activity. Similarly, it is assumed that the level of knowledge used in the activity may be measured and that the relationship between both quantities may be expressed in a meaningful form. In practice a variety of metrics are used to determine efficiency, reflecting different aspects of the input, output or resource knowledge. For example the cost of using a designer within an activity may be measured to reflect the amount of financial resource used in utilising this knowledge source. Efficiency of an activity is considered here to exist irrespective of whether Cost is used here as a general metric to describe the level of time, money, material, etc. used in the activity.

540

ICED 01 -C586/442

it is measured or not, i.e. it is an inherent property of the activity. The selection and application of metrics to determine efficiency allow particular views of efficiency to be created, e.g. cost or time based efficiency.

3.2

Effectiveness

Activities are generally performed in order to achieve a goal, i.e. have a desired effect. However, the result obtained from performing an activity may not always meet the goal. The degree to which the result (output) meets the goal may be described as the activity effectiveness. Therefore, activity effectiveness, as depicted in Figure 3, can be expressed as:

Where: n(Ak) rc O G

: Effectiveness (n) of Activity (At) : Relationship (Comparative) : Output (Knowledge) : Goal (Knowledge)

This formalism assumes that the output knowledge (O) and goal knowledge (G) may be described in a manner which allows a direct comparison between them, and a relationship to be determined which indicates how closely they match.

Figure 3. Effectiveness (n)

In design, multiple goals are likely to exist with different priorities. Therefore the activity effectiveness with respect to a single goal will often represent only a partial view of effectiveness measured using a particular metric. That is, effectiveness may be described in relation to particular type of goals, e.g. cost goals, in isolation of other goals such as time, artefact aesthetics, etc. The determination of overall effectiveness for the activity in Figure 4, n(A), presents a multiple criteria decision making problem. That is, to fully evaluate the design proposal some value of overall effectiveness must be established. There are a variety of techniques that may be adopted to support optimisation although the nature of the design activity is such that obtaining values with which to carry out optimisation is difficult, e.g. determining values for aesthetic elements. The weighting method [11] presents one of the simpler approaches to this type of problem. For example if we consider the priority (or weight) of the life in service goal (G1) to be W1 with respect to that of the dimensional accuracy goal (G2 of W2, then we could say:

ICED 01 - C586/442

541

Figure 4. Establishing overall effectiveness

3.3 Relating Efficiency and Effectiveness Efficiency and effectiveness focus on related, yet contrasting performance elements. The efficiency is inherent in the behaviour of a particular activity/resource combination. It may be measured without any knowledge of the activity goals, although the goals may influence the behaviour of resources used in the activity and consequently the level of efficiency that results from their use. Effectiveness, in contrast, cannot be measured without specific knowledge of the activity goals. As is the case in measuring efficiency, the measurement of effectiveness involves the analysis of the activity output (O). However, effectiveness is obtained through analysing a specific element of the output knowledge, i.e. that which relates to the goal(s) of the activity. In certain cases there exists a direct relationship between effectiveness and efficiency. This relationship exists when the specific element of the output knowledge, which is evaluated to establish effectiveness, also describes an element of the resource used. For example, an activity may have a specific cost related goal of minimising the activity cost, i.e. Gj: C = Min. Therefore the element of the output knowledge (O) which must be evaluated is the cost knowledge (Oc). However, determining the cost based efficiency of the activity also involves the analysis of cost incurred (Ru-c) in carrying out the activity as part of the overall resources used (Ru). In this particular instance the element of output knowledge used to establish effectiveness is the same as that used to establish efficiency. Therefore, an increase in the cost based efficiency of the activity will also result in an increase in the cost based effectiveness of the activity, given an activity goal of minimising cost. In cases such as this one the efficiency of the activity can provide insight into why a particular level of effectiveness has been obtained. This type of calculation is an over simplification and in many cases the elements cannot be easily defined.

542

ICED 01 -C586/442

In other cases a direct relationship between efficiency and effectiveness is not evident. Such cases exist where the specific element of the output knowledge that is evaluated to establish effectiveness has no relationship to the resource knowledge used in an activity. For example where the goal of a design activity may be to maximise the dimensional accuracy of the artefact, G(S) = Max(s), the element of the output knowledge (O) which must be evaluated is the knowledge of the dimensional accuracy (O(s)). It is clear that this knowledge provides no indication of the resource knowledge (R) used in the activity. Therefore an increase in dimensional accuracy will give increased effectiveness with respect to this goal but there is no direct relationship with efficiency in this case.

4

Evaluation

The research presented in this paper has been evaluated as part of an overall PhD project and is detailed in [12]. A number of approaches have been taken in evaluating the work: The development of a worked example using information from previously reported protocol studies to illustrate the application of the E2 formalism within a practical scenario. A large number of metrics existing within the literature have been reviewed and analysed in relation to the formalism to determine if the key principles were violated. Experts in design, performance measurement and management, and risk management from industry and academia have critically appraised the E2 formalism. The evaluation results illustrated that the E2 model could be used to describe performance using protocol data and measures of efficiency and effectiveness were defined using the formalism. The metrics reviewed from the literature could be distinguished within the area of efficiency or effectiveness and further insight into these metrics was gained, e.g. those metrics measuring influences on performance were distinguished from those measuring performance itself. The critical appraisal provided support for the comprehensiveness of the formalism and the key principles were seen to reflect and clarify industrial practice.

5

Discussion and Conclusion

The treatment of design performance within existing research lacks clarity on the nature of performance itself as a basic foundation for work in this area. The E2 model clearly distinguishes and relates the key elements of performance, efficiency (n) and effectiveness (n). Further, influences on performance may be clearly distinguished, e.g. flexibility may be viewed as the ability of a designer to adapt to changing goals. This influences the performance of the activity but is not in itself a measure of performance. The boundary of this model may be defined at the level of a specific activity or at other levels within design development such as project or program with the key principles remaining valid. The model has been used to further formalise the process of performance measurement and management, distinguishing and relating the performance of the design (artefact) to that of the activities involved in its development (product and process) [13].

ICED 01 - C586/442

543

References [1]

[2]

[3]

[4] [5]

[6] [7] [8]

[9] [10]

[11] [12]

[13]

Brown, S.L. and K.L. Eisenhardt, Product Development: Past Research, Present Findings, and Future Directions. Academy of Management Review, 1995. 20(2): p. 343-378. Neely, A., The performance measurement revolution: why now and what next? International Journal of Operations and Production Management, 1999. 19(2): p. 205228. Montoya-Weiss, M.M. and R. Calantone, Determinants of New Product Performance: A Review and Meta-Analysis. Journal of Product Innovation Management, 1994. 11: p. 397-417. Brookes, N.J. and C.J. Backhouse, Measuring the performance of product introduction. Journal of Engineering Manufacture, 1998. 212(1): p. 1-11. Chang, Z.Y. and K.C. Yong, Dimensions and indices for performance evaluation of a product development project. International Journal of Technology Management, 1991. 6(1/2): p. 155-167. McGrath, M.E., The R&D Effectiveness Index: Metric for Product Development Performance. Journal of Product Innovation Management. 1994. 11: p. 201-212. Johnson, H.T. and R.S. Kaplan, Relevance Lost - the Rise and Fall of Management Accounting. 1987, Boston, MA: Harvard Business School Press. Neely, A., M. Gregory, and K. Platts, Performance measurement system design: A literature review and research agenda. International Journal of Production and Operations Management, 1995.15(4): p. 80-116. Meyer, M.W. and V. Gupta, The Performance Paradox. Research in Organisational Behaviour, 1994. 16: p. 309-369. Cusumano, M.A. and K. Nobeoka, Strategy, Structure, and Performance in Product Development: Observations from the Auto Industry, in Managing Product Development, T. Nishiguchi, Editor. 1996, Oxford University Press, Inc. p. 75-120. Balachandran, M., Knowledge Based Optimum Design, ed. C.A. Brebbia and J.J. Connor. 1993: Computational Mechanics Publications. O'Donnell, F.J., A Methodology for Performance Modelling and Analysis in Design Development, in Design Manufacture and Engineering Management. 2000, University of Strathclyde: Glasgow. O'Donnell, F.J. and A.H.B. Duffy. Design Activity Modelling: A Performance Viewpoint, in International Conference on Engineering Design (ICED 01). 2001. Glasgow.

Frank J O' Donnell E-business Group, Scottish Enterprise, 120 Bothwell St., Glasgow, G2 7JP, Scotland, Tel: +44 (0)141 228 2950, Fax: +44 (0)141 228 2882 , E-mail: [email protected] , URL http://www.scottish-enterprise.com/ebusiness © IMechE 2001

544

ICED 01 - C586/442

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

A METRICS METHODOLOGY DEVELOPED IN CO-OPERATION WITH INDUSTRY M W Lindley, M Muranami, and D G Ullman Keywords: Performance metrics, business process reengineering

1 Introduction Process performance metrics (in contrast to product performance metrics) are not routinely used in physical product generation industries. Process information is often viewed as paperwork burden, without inherent value-added. However, research papers on product development have proposed that the product development process (PDP) used by a company has direct impact on the resulting quality of the finished product [1]. In order to realize improvements to the process, the company must be able to compare their original PDP with the proposed changes. Therefore, a method to measure the PDP is needed. Measuring the process is not a trivial task [2], since the tools required to measure the process in various industries need to be customizable, scalable, and usable in real-time, during execution of the PDP. The goal of the research presented in this paper is to develop a general, cross-industry methodology for developing process performance metrics for the purpose of assessing a company's PDP. The aim of metrics is to monitor measurements that directly affect the PDP in terms of process cost, process time, and information quality. With metrics, engineering management is able to make better decisions to keep the PDP on track. The target audience for the methodology described includes any product generation company concerned with improving its mechanical design process. Efforts were taken to make the methodology flexible and to tailor the metrics to the PDP that the company employs, regardless of process formalization or organizational structure. For this research, data collection and methodology verification were conducted at three industry partners over a period of nine to twelve months: Company X is a small, for-profit, off-road equipment manufacturer with in-house mechanical design and manufacturing capabilities, producing approximately 20 units per month. Company Y is a global, for-profit electronic product generation firm with contract product development and manufacturing, with production volume of 100,000 units per month. Company Z is a product generation organization within a non-profit government research body, with in-house design and manufacturing, which produces one-off research instrument systems on an annual schedule. A paper further detailing the application of this methodology at the partner companies is available [3].

ICED 01 -C5 86/468

545

2 Description of the metrics methodology First, definitions for key terms used in the methodology are in order. A measure of a process is a quantified attribute of a process entity that characterizes the attribute. A measure has no inherent 'good' or 'poor' value. A metric for a process is a performance indicator relating a measure to a target value; a metric evaluates the process entity in that it indicates deviation of the process entity from its target value. An example of a measure is 'time to generate drawing', while an example of a metric is 'target time to generate drawing is 6 weeks'. The metrics methodology consists of four steps: Document the existing Product Development Process (PDP). Construct the Process Measurement Matrix (PMM). Identify the subprocesses with greatest impact on successful execution of the PDP. Create quantitative metrics by developing measurements of the critical subprocess attributes and relating the measurements to target values.

2.1 Step one: document the current design process At the industry partners, the researchers documented the product development process as practiced in the most recently completed program. Existing product development process documents, if available, were collected at the companies. Where no documentation existed, product development practices were first written down and organized. Finally, interviews with practicing engineers were conducted to capture a complete picture of the PDP as practiced. The PDP date was then formatted into a flow diagram arrangement, showing process steps with inputs and outputs [4]. The flow diagram provides a graphical representation of the relationships among the steps of the design process. While predominant steps are common to most industries, each company and every project exhibits differences. The flow diagram includes project specific steps and is expandable to provide finer details of the design process.

2.2 Step two: construct the process measurement matrix (PMM) The process measurement matrix (PMM) [5] is a PDP management tool, which relates process management to specific steps of the product development process. The PMM also provides relative weightings of how resources are utilized during a PDP. The PMM resembles a quality function deployment (QFD) House of Quality in structure [6]. It organizes process numerical measurements instead of the QFD product numerical engineering requirements. Constructing the PMM begins with modeling the resources and requirements as inputs, and the deliverables as outputs. These inputs and outputs serve as the framework for the PMM. A simplified PMM is shown in Figure 1, with matrix entries labeled Field A through Field I.

546

ICED 01 - C586/468

Figure 1. Process Measurement Matrix (PMM) [4]

Field A: Name of the target process within the PDP. This is the process for which the PMM is constructed. Example: 'mechanical design creation process'. Field B: Names of internal subprocesses of the target process. The names of all the subprocesses necessary to complete the target process are listed in columns. Example: 'drawing creation'. Field C: Numerical ranking of the internal subprocesses in Field B in order of most constrained to least constrained - highlights the most critical internal subprocesses. Example: 'drawing creation: rank 1'. Field D: Numerical measures for internal subprocess attributes and their actual values. Process metrics are created from these measures. Example: 'assembly drawing creation: 6 weeks'. Field E: Requirements, resources, and deliverables names. The names of all the inputs and outputs for the target process are listed in rows. Example: 'draftsman: 20 manweeks'. Field F: Benchmark target numerical values for requirements, resources, and deliverables. Example: 'target draftsman: 18 man-weeks'. Field G: Target numerical values for internal subprocess attributes. Example: 'assembly drawing creation: 4 weeks'. Field H: Indication of degree of dependency among internal subprocesses of the target process. Example: 'dependency between assembly drawing creation and production operator training: high'.

ICED 01 -C586/468

547

Field I: Indication of degree of dependency among requirements, resources, and deliverables of the target process. Example: dependency between draftsman man-hours and production operator man-hours: medium'. A key decision required prior to PMM construction is selection of the level or granularity for the PMM. The highest level PMM is constructed for the whole PDP, with the entire product generation enterprise as resource, product financial objectives as requirements, and sale of the finished product as the deliverable. Numerous internal subprocesses are required to accomplish this top process. A PMM can be constructed for every one of these subprocesses, with finer granularity requirements, resources, and deliverables. Each of the subprocesses in turn consists of smaller internal subprocesses with finer granularity inputs and outputs. The PMM, created in Step Two allows visualization of relations among subprocesses and their inputs and outputs. By filling in entries along a row, the matrix format clearly reveals the significance of an input (a requirement, a resource, or a deliverable) to each of the internal subprocesses. Likewise, by filling in entries down a column, the matrix format highlights essential inputs to a subprocess. Since the entries are numerical measures, the PMM drives the conversion of qualitative attributes into numerical quantities, allowing visibility of control at the engineering level. Another contribution of the PMM is that it makes visible non-obvious relationships among PDP portions, especially chronologically separated subprocess steps. Interviews with engineers during Step One revealed dependencies between subprocesses and between PDP inputs that are entered in Field H and Field I. Recognition of these dependencies assists the next step of the methodology, in which PDP constraints are identified.

2.3 Step three: identify critical process areas that need improvement With the target process organized by the PMM into subprocesses, inputs, and outputs, critical components of the process now need to be highlighted. Various methods can be used to identify critical process portions. The interviews with engineers revealed areas of process constraints at each of the companies. The Theory of Constraints (TOC) [7] was used to augment the PDP flow diagram to identify constraints in the system. Targeting the constraining portions of the design process maximizes improvements to the system. The portions of constraint identified in the target process are now entered into the PMM. The subprocesses in Field B of the PMM are ranked from most critical to least critical using a general ranking process (such as [8]). Alternatively, this ranking is accomplished through prioritization methods unique to each company's business (see [10] for an example). The numerical rank for each subprocess is entered in Field C of the PMM, and gives ready visibility to constrained portions of the PDP. The subprocess that most constrains the target process is the best candidate for assessment using metrics. This highest-ranking subprocess is called the critical subprocess, and is used for metrics creation in the next step of the methodology. The PMM facilitates visualization and organization of inputs, outputs, dependencies, and targets for this critical subprocess. The first three steps identify where to develop process metrics. The last step - Step Four generates what the metrics are.

548

ICED 01 - C586/468

2.4 Step four: create metrics for each critical subprocess The purpose of the process metrics developed in this methodology is to compare the actual (measured) value of numerical attributes of the PDP to the desirable target (benchmark) numerical value. Using the metrics, engineering management then makes decisions that move measured values closer to benchmark values. PDP metrics measure attributes specific to design process steps and compare them to benchmark information about the steps. A metric is the numerical relationship of the measure of the consumption of resources and the completion of deliverables versus the benchmark usage developed from the PMM. In this methodology, six tasks are required for metrics creation. Task 1: List the internal subprocesses of the critical subprocess as PMM column entries. These internal subprocesses are monitored using appropriate measures, which are used in generating further measures and metrics for this critical subprocess. Task 2: List all the numerical measures and target values for attributes of requirements, resources, and deliverables that flow into and out of the critical subprocess. These attributes were specified in the row entries of the PMM. Note that during actual execution of the overall PDP, these target values may need to be adjusted before execution of the target process portion begins. Given these target values, the PDP team members responsible for this PMM target process formulate internal targets for each of the internal subprocesses (Field G). One of these internal subprocesses is the critical subprocess. Using these target values, a metric for the critical subprocess is constructed. Task 3: Find the relationships among measures for monitoring through metrics. Develop formulae that capture the deviation or delta between target value and actual value for the numerical attributes of requirements, resources, and deliverables. The target value, is obtained from the PMM, while the actual value will be captured when the subprocess is actually executed during the PDP. Task 4: Create a metric by combining these delta values in formulae that show how the subprocess is actually consuming inputs and delivering outputs, compared to target values for inputs and outputs. Once this methodology is applied repeatedly at the same company, requirements, resources, and deliverables from previous programs become known, and allocations that resulted in successful program execution serve as benchmarks for future program metrics development. These new benchmarks are then applied to Tasks 3 and 4. Task 5: Again, for the critical subprocess, repeat Tasks 2 through 4 for the next measure for which a metric is desirable. A significant critical subprocess with multiple deliverables requires additional metrics for complete monitoring. Task 6: Repeat Tasks 1 through 5 for the second most critical subprocess, as identified by the PMM for the target process. Repeat for subprocesses further down in importance until a thorough but manageable list of metrics is generated. With these six tasks under Step Four of the methodology, the company is guided to construct the most critical metrics that indicate success of the PDP. By developing these metrics before starting a product generation project, engineering management becomes focused on measuring subprocesses attributes that have the most influence on successful outcome. The Tasks 1 through 6 described above outline the most thorough and rigorous application of this process metrics methodology. An advantage of this methodology is its scalability, depending on the organizational and operational characteristics of the enterprise. As noted in the introduction, the three industry partner companies with diverse endeavors serve as good

ICED 01 -C586/468

549

examples of this scalability of the metrics methodology. Case study highlights from the three companies are presented next to illustrate the above tasks.

3 Verification of the metrics methodology at the industry partners The methodology was verified by application at companies that differ in industry type, size, and PDP maturity level. The researchers selected projects at the respective companies and conducted the four step metrics methodology. Details of implementation of the methodology at companies X, Y, and Z, and descriptions of the actual metrics developed can be found in references [9], [10], and [11] respectively. In addition to process metrics generation, the case studies show a cross-industry benefit from application of this metrics methodology: the rigor required in documenting the PDP in preparation for PMM construction led to new techniques of process analysis. In Company X, process information sheets, which rigorously gave the purpose, inputs, and outputs for each PDP stage were created. In Company Y, dependencies among subprocesses were discovered through process defect tracking, which is a new method of analyzing the process flow diagram. In Company Z, minimum PDP requirements were documented for creating meaningful process metrics at companies that employ an informal process. In all three instances, the industry partners gained tangible process tools and techniques usable by engineers and managers, independent of PMM and metrics construction. Highlights of process metrics benefits realized at each of the partner companies are summarized. Company X: The top level PMM generated for the company PDP showed that the time and funds spent in executing the critical subprocesses had the greatest impact on successful fulfillment of top-level requirements. Due to the fairly small company size, management and the researcher agreed that long-term payoff from application of this metrics methodology will result from focusing only on these critical subprocesses. Company Y: The results from PDP analysis revealed weak engineering input during early program phases. This lack of engineering input resulted in most process defects being generated in these early phases. Frequently, in past product generation programs, these defects would manifest symptoms much later in the PDP in the form of schedule slips from unplanned tooling modifications, product material cost increases, increased field service costs, and reduced customer utility derived from the released product. The process flow diagram and PMM derived metrics generated through application of the methodology presented in this paper forced engineering based scrutiny of tasks and deliverables within these early program phases. The Company gained the insight required to 'pay early' by allowing engineers to take the time and resources to improve the quality of early PDP deliverables. This initial consumption of resources reduces the risk of having to 'pay later' in schedule delays, cost increases, and product quality reduction. The metrics quantified and helped company management visualize the tradeoffs required for overall process improvement Company Z: The metrics for time and cost revealed how the resources were being affected by time constraints. The metrics for deliverables showed the degree of completion along each step of the design process. By comparing the resource usage against the completion of each project step, decisions were made to ensure project progress. By comparing the resources required for completion of one step to resources required for completion of

550

ICED 01 - C586/468

another concurrent engineering step, the methodology guided appropriate resource balancing.

4 Conclusion The metrics methodology created by the authors and generated the following benefits at the industry partners: Rigorous documentation of the product development process. Creation and utilization of the Process Measurement Matrix to organize and prioritize target process requirements, resources, and deliverables. Identification of constraints in the PDP that lead to deficiencies during execution. The constrained portions are critical subprocesses. Creation of measures and metrics for the most critical subprocesses. Verification of usefulness of the metrics methodology through application to current product generation programs. The methodology developed here was shown to work in three companies with diversity in industry, size, and PDP maturity. The methodology is scalable to adjust to specific needs of individual companies.

5 Acknowledgement This research is sponsored by the National Science Foundation under Grant DMI-9634768. References [1]

Hauser, J. R., "Research, Development, and Engineering Metrics", working paper, International Center for Research on the Management of Technology, MIT Sloan School of Management, 1996.

[2]

Smith, D., The Measurement Nightmare. The St. Lucie Press, 2000.

[3]

Lindley, M.W., Muranami, M., & Ullman, D. G., "A Metrics Methodology Developed in Cooperation with Industry: Method and Case Study", submitted to Research in Engineering Design. 2001.

[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-Class Concurrent Engineering. ASME Press, 1994.

[7]

Dettmer, H. W., Breaking the Constraints to World-Class Performance. ASQ Quality Press, 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 Engineering Theory for Use in Small Manufacturing Companies", thesis, Department of Mechanical Engineering. Oregon State University, 2000.

[10] Muranami, M., "A Metrics Methodology developed for High Volume Product Generation Organizations", project, Department of Mechanical Engineering, Oregon State University, 2001. [11] Lindley, M.W., "A Metrics Methodology developed for Non-Profit Research Organizations", project, Department of Mechanical Engineering, Oregon State University, 2001. Prof. David G. Ullman Department of Mechanical Engineering, Oregon State University, Corvallis, Oregon 97331, USA, Tel: (541) 754-3609, E-mail: [email protected], URL: http://www.engr.orst.edu/~ullman/. © IMechE 2001

552

ICED 01 - C586/468

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

IMPROVEMENT OF ENGINEERING PROCESSES S Vajna, D Freisleben, and M Schabacker

Keywords: Knowledge-based Engineering Process Model, General Process Elements. Evaluating Engineering Processes

1

Introduction

Processes form the kernel of engineering (i.e. marketing, development, design, and production planning [1]). Process models can be used to improve engineering processes. A holistic engineering process model allows a comprehensive and general representation (i.e. description, formalisation, and structure) as well as the support of all activities in product development. A large range of different procedures and methods supports engineering processes. For their application, appropriate manual and/or computer-aided tools are required. Although most investments are made into these methods and tools including their handling, the resulting benefits occur mostly on the procedure and process level. In this paper a knowledge-based engineering process model (KBEPM) will be described.

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 do not limit the set of activities. A subprocess is a subset of a process and is also a set of activities or other subprocesses. A process element describes an activity respectively of one or several working steps. It is started by one or several events and ends in one or several events. The single process elements (activities) are self-contained in content, and they are in a logical context to each other [2J. Their description is based on a defined structure so that they are suitable also for the application in a computer-aided system. A working step is the smallest subset of an activity in product development. A process model is the sum of process elements together with the rules of relations between the process elements. A procedure is a certain sequence of activities (working steps) respectively processes which leads to the fulfilment of one or several aims of a process by the application of methods and/or tools.

ICED 01 - C586/663

553

A method is an organised collection of rules, which allows a methodical fulfilment of one or several aims of a process. Rules are of immaterial nature. A tool is a resource, which supports the achievement of one or several aims of a subprocess.

Figure 1. : Relations between process, subprocess, and process element

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 to know well, to monitor, and to control all processes and activities. Process models can be applied for formalisation, structuring, and description of any processes and objects treated in these activities. Main goal of the KBEPM presented here is the provision of proven activities or working steps (either in a sequence or in parallel), procedures, methods, tools, and application modules (all together with the appropriate knowledge) in form of a computer-based navigation tool. This tool assures that a user doesn't "forget" any of the necessary activities in the development of a product. The KBEPM is based on process elements. Process elements offer the possibility to define processes in a formalised way. They can adapt very flexibly to different requirements. Due to their coherent description they can also be represented graphically. One of the advantages of using process elements for the description of the design process in the KBEPM is the possibility to reuse a process element for similar processes.

554

ICED 01 - C586/663

Existing literature and references include a large number of proposals that describe how to pass through the phases of product development using a lot of different activities. For the definition of the general process elements of the KBEPM various models and procedures from the following authors were analysed and compared: The work of Pahl and Beitz [3] was used because their design process procedures are well known and because these procedures are taught in the majority of universities in Germanyoffering design education. The VDl-Guideline 2221 [4] was created as a broadly accepted guideline for companies (and normally should be well known there. Hansen [5] was one of the first authors who investigated methodical procedures for the design process. A lot of the later approaches are based on Hansen's work. Hubka [6] describes a general process model of design for the new design of technical systems, e.g. machines and installations. Dietrych and Rugenstein [7] take into consideration early in the process the aspect of production preparation. Eversheim [8] describes the activities of production preparation in much detail but without a link to the previous design process. Blessing [9] defines matrices that describe activities with an assignment to product components. This is a quintessence of many theories above all from the English speaking area. By using these models and procedures, about 50 process elements were designed to cover all activities from the first idea or the identification of needs (either of a customer or of the market) until the release to manufacturing. To get these general process elements, the content of every model from the list above was compared to each other: New process elements were added, if an activity was missing, e.g. for applying a new technology like rapid prototyping in the early phases of the design process. Process elements were cleared, if in another process element the same activity was alreadytreated or the same information was created. Extensive process elements were divided up if too many different working steps were included in one activity. Similar working steps were combined to one process element, if they created either equal output information and/or documents of the appropriate activities. To support the design process by the intensified use of methods and tools, more than 100 possible or necessary methods and tools applied in the design process were registered and formalised. Subsequently, a method base was set up in which every process element is associated to its potential/ possible methods, tools, and applications [1], By this way the KBEPM provides the user only those methods and tools which are the most appropriate to support the activity of a specific process element. The method base also is open for adding and modifying general and company specific methods and tools at any time.

ICED 01 - C586/663

555

Each process element operates like a module. By a variable combination of the general process elements and the special use of methods and tools the process model can be adapted easily to a lot of different requirements of company specific product development processes. The KBEPM is being implemented using standard software tools. This makes it possible to improve existing engineering processes, to navigate users along the product development process, to react dynamically to disturbances along the ongoing development of the product (e.g. when a customer changes the requirements of the product during order processing), to monitor processes and their improvement, and to capture the design intent.

4

Predicting and Measuring Costs and Benefits

Additionally, an evaluating tool based on [10] was included for predicting and measuring costs and benefits of process improvements. In a first step, this evaluating tool is intended to measure benefits of processes and tools (e.g. CAD, EDM), in a second step benefits of methods will be included. In business theory there are no suitable benefit evaluation procedures. Another problem is the missing process orientation as well as an inadmissible mix of quantifiable and qualitative benefits (if they are not be even neglected). Hence, the results are difficult to comprehend [11]. Because the benefits of processes and tools can be found in the whole product development, two views, the process view and the tool view, have to be regarded. The economic proof of the (optimised) processes can be measured rather easily using process throughput time, process costs, and process quality (the necessary formula and procedures are described in [10]). Compared to the process view, the economic proof of the application of tools is very difficult (and even worse for computer-aided tools). Hence, a method for benefits recording is necessary. There are two ways: the classical approach of costs, quality and time, and a Controlling approach. The drive to record benefits of tools is the classical requirements like less costs, quality improvement and reduced throughput time. However, these requirements have different meanings in context with processes, procedures, methods, and tools in product development, as well in co-operation with the customers. There are overlappings because e.g. time reduction can be transferred to cost reduction. Several interpretations are possible because e.g. quality can be product quality, service quality, or staff quality (to be achieved by qualification). Also it has to be regarded that companies are structured in projects for the implementations of temporary plans. Hence, six benefit categories were defined in [10]: staff environment, tool application, product quality, service quality, process performance, and project performance. Exemplary benefits were related equally to the single benefit categories. In the single benefit categories for benefit evaluation, the benefits that can be quantified completely by monetary means and benefits (where the quantification is possible but with difficulties). These benefits are classified in so-called benefit classes based on the VDI guideline 2216 [12]. The benefit class "synergy effects" extended the benefit classes, which covers company internal and external synergies. These five benefit classes can be arranged as a portfolio. This portfolio is called the Benefit Asset Pricing Model (BAPM) portfolio. It is shown in [10] that this portfolio is similar to a portfolio in the capital market containing shares, bonds, and zerobonds. Hence the portfolio theory of Markowitz [13] as well as methods and

556

ICED 01 -C586/663

procedures for yield and risk evaluation of capital market investments can be applied on the benefit evaluation. The result of these similarities is shown in figure 2.

Figure 2. : Similarities of benefit classes and capital market investments

An additional way to get the benefit categories was based on the resulting difficulties that appeared not only during benefit recording and evaluation but also mostly in classical Controlling [10]. Therefore, new controlling methods had to be found. One of these was the Balanced Scorecard [14], which was created originally for manufacturing. The Balanced Scorecard is able to give a financial value to product development, processes in the company, staff know how, staff motivation as well as staff flexibility, and customers loyalty, and new technologies, even then if these topics are not listed in a company balance. The Balanced Scorecard was the unique new controlling instrument that focusses on customers, staff, and processes. All other instruments focus only on one of these aspects like e.g. Total Quality Management on quality. Moreover, the Balanced Scorecard applied in product development, offers the same six benefit categories (figure 3) which can be derived by the interpretation of the original four Balanced Scorecard perspectives [14]: 1. learning and development perspective 2. staff perspective 3. process perspective 4. financial perspective. To summarise, the results of both approaches, the classical approach of the benefit categories costs, quality and time as well as the classical Balanced Scorecard approach, are shown in figure 3. The benefits in the different benefit categories of both approaches can be related to benefit classes. In KBEPM the tools which were applied during processes and activities and further information of costs and throughput time are available. In order to apply the BAPM in context with KBEPM the following procedure is recommended (figure 4): The information of applied methods and tools, the used time and costs altogether are transferred into the BAPM module. In BAPM benefits are classified in benefit categories and in benefit classes. To get the individual yield of each benefit class, each benefit in each class has to be evaluated. The application of the portfolio theory of Markowitz results in the respective yield-and-risk-portfolio of each benefit class. Applied for the sec-

ICED 01 - C586/663

557

ond time, the portfolio theory of Markowitz now delivers the yield-and-risk-portfolio of the whole benefit portfolio. The output of the benefit evaluation is placed in an Internet Browser window (details shown in figure 4).

Figure 3. : Derivation of the benefit categories in product development and Balanced Scoreeard

Figure 4. : Software approach of BAPM

558

ICED 01 - C586/663

Figure 5 shows the output of the results of benefit evaluation in a spreadsheet format.

Figure 5. : Monetary evaluation of benefit classes

5

Conclusion

Based both on the research work on engineering process improvement by using general process elements in a holistic engineering process model and on the evaluation of these improvements, this contribution should motivate the discussion with other groups dealing with similar approaches. The next step is the application of these research results in industry to get more experiences. References [1]

Vajna. S., Freisleben. D., Scheibler, M, "Knowledge Based Engineering Process Model". Proc. ICED '97. Tampere. 1997, pp. 181-184

[2]

VDl-Guideline 2219, "Datenverarbeitung in der Konstruktion, Einfuhrung und Wirtschaftlichkeit von EDM/PDM-Systemen", VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf l999

[3]

Pahl, G.; Beitz, W.: Konstruktionslehre: Methoden und Anwendung, Springer-Verlag, Berlin Heidelberg New York London Paris Tokyo Hong Kong Barcelona Budapest 1997

ICED 01 - C586/663

559

[4]

VDI: VDl-Richtlinie 2221 Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte. VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf 1993

[5]

Hansen, F.: Konstruktionswissenschaft: Grundlagen und Methoden, VEB Verlag der Technik, Berlin 1974

[6]

Hubka. V.: Allgemeines Vorgehensmodell des Konstruierens, Fachpresse Goldach. Zurich 1980

[7]

Dietrych. J.; Rugenstein, J.: Einfuhrung in die Konstruktionswissenschaft, Technische Hochschulc Otto von Gucricke Magdeburg, Politechnika Slaska im. W. Pstrowskiego Gliwice 1982

[8]

Eversheim, W.: Organisation in der Produktionstechnik, VDI-Verlag, Dusseldorf 1989

[9]

Blessing. L. T. M.: A Process-Based Approach to Computer-Supported Engineering Design, Black Bear Press Ltd, Cambridge 1994

[10] Schabacker, M.: "Benefit Asset Pricing Model - Ein Modell zur Nutzenbewertung neuer Technologien in der Produktentwicklung'", am 22.02.2001 verteidigte Dissertation an der Fakultat fur Maschinenbau der Otto-von-Guericke-Universitat Magdeburg [11] Bauer, F.: "ProzeBorientierte Wirtschaftlichkeitsbetrachtung von CA-Technologien", Europaische Hochschulschriften Reihe V Volks- und Betriebswirtschaft Vol. 1813, Europaischer Verlag der Wissenschaften. Frankfurt am Main, 1995 [12] VDI-Guideline 2216. "Datenverarbeitung in der Konstruktion: Einfuhrungsstrategien und Wirtschaftlichkeit von CAD-Systemen", VDI-Gesellschaft Entwicklung Konstruktion Vertrieb, Dusseldorf 1990 [13] Markowitz, H.M.: "Portfolio Selection", Journal of Finance. March 1952, pp.77 - 91 [14] Kaplan, R. S., Norton. D. P.: "Balanced Scorecard - Strategien erfolgreich umsetzen", Schaffer-Poeschcl Verlag Stuttgart, 1997 Prof. Dr.-Ing. S. Vajna Otto-von-Guericke-University of Magdeburg, Computer Applications in Mechanical Engineering, Universitatsplatz 2, D-39106 Magdeburg. Germany, Tel: +49-391-67-18794. Fax: +49-391-67-11167. E-mail: [email protected]. URL - http://imk.uni-magdeburg.de/LMI/lmi.html Dr.-Ing. D. Freisleben. Dr.-Ing. M. Schabacker EPI-K AG, Listemannstr.l0b. D-39104 Magdeburg, Germany, Tel: +49 -391-53558-0, E-mail: [email protected]. [email protected]. URL - http://www.epikag.de © IMechE 2001

560

ICED 01 -C586/663

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

PROCESS PERFORMANCE MEASUREMENT SUPPORT - A CRITICAL ANALYSIS M K D Haffey and A H B Duffy Keywords: Design Management, Performance Management, Performance Metrics.

1

Introduction

Design development processes, within engineering disciplines, lack the necessary mechanisms to identify the specific areas where improved design development performance may be obtained. In addition, they lack the means to consider and align the goals and respective performance levels of related development activities within the consideration of an organisation's overall goals and its required performance dimensions and levels. Current research in organisational performance behaviour, formalised through performance frameworks and methodologies, has attempted to identify and focus upon those critical factors which impinge upon a wealth creation system while attempting to, simultaneously, remain representative of organisational functions, processes, people, decisions and goals. Effective process improvements remain conditional upon: the ability to identify potential areas for improvement and to define the goals and subsequent measures which will support the realisation of such goals; the ability to measure the potential performance gains which may result from an improvement initiative; and, the ability to understand existing process dynamics and the subsequent impact of some change to a system/process. The objective of this paper is to discuss some of the management techniques, which are purported to support various process performance issues and perspectives, and identify the major factors that remain unsupported in identifying, measuring and understanding design process performance.

2

Process Performance

Engineering design development processes involve designers developing product designs that possess the potential to meet the requirements of both prospective customers, and the specific standards delineated through internal and external influences. In addition, designers must be guided and controlled by the needs and strategic intentions of an organisation placed in a local context through the directives and focus of middle management. Design development processes are responsible for producing an output or product design that has the potential to be delivered to the customer in the form of a product, through subsequent development stages by considering various internal and external perspectives and requirements. For example, the design development process, considering both the design activity and its management, must realise the potential to deliver a product to the market place: at an efficient cost when placed in the context of market price; at an optimum point of market entry to satisfy customers delivery requirements and ahead of market competition; at a level of quality that the customer is at least expectant of while superior to market competitors in the aspects that a market will base its decisions upon to purchase; and, that will support the long term survival of an

ICED 01 - C586/653

561

organisation and the financial health expected by shareholders [1]. Thus, designers and design development managers must acquire, modify and/or generate the information that enables them to manage design processes/activities and design products that: firstly, align with, and satisfy, the required dimensions of organisational performance and that are congruent with the goals and objectives of the associated product development process functions such as manufacturing; and secondly, that will perform in the market place from such dimensions as return on investment. Design development activities are therefore forced to consider not only their own output or deliverable, from within the alignment of both internal organisational perspectives - from strategic level objectives (macro) to general design development goals (micro) - and the objectives and standards associated with the external organisational environment, but must, in addition, produce a design deliverable that will remain congruent with the objectives and goals of subsequent, and indeed previous, development activities. The statement that an organisation's core competencies are the building blocks of competitive advantage [2] brings to the fore the second, high level, concern of performance measurement, namely, that of how organisational strategies may be developed based on the strengths and weaknesses of lower level functions and processes [3]. Thus, the formulation of a strategy necessitates the need to understand the many relationships and interactions that may exist internally and externally to an organisation's environment i.e. identifying where major strengths and weaknesses, and opportunities/threats, are likely to arise. From the discussion certain factors need to be addressed in order to support an organisation in determining the areas that it or its processes should be utilising or improving upon (bottom up) and in measuring the levels of performance required to develop and deploy organisational strategies (top down). The following points explicate the fundamental components that would support organisations in formulating strategies, based on performance levels obtained at a design development process level, and in guiding development activities by placing process specific goals in the context of realising high-level organisational strategies. Thus, the aspects presented refer to the means of getting high-level concerns and objectives down to a process level, and within their context, to feedback the information to an overall organisation level. Definition of Goals: Design Development processes are, for the most part, subject to product requirements in terms of functional and behavioural considerations but lack support in placing these specific requirements or goals in context with organisational strategies and goals. From an improvement point of view the development and definition of goals infers that gaps or suboptimal results have been identified. Thus, measurements relating to a process's level of performance are required to support in identifying what must be protected or improved upon to satisfy organisational objectives and customer expectations and requirements. High-level strategic goals or objectives need to be decomposed into process specific objectives, providing the ability to relate and align process specific performance measures with the needs and strategic direction or focus of the organisation, and in turn providing the ability to link company objectives to daily activities and decision making activities [4]. The following points outline why the setting of realistic and informed strategic objectives is required to succeed in satisfying those objectives, and to an organisation's overall level of performance. Alignment: Consideration must be given to how high-level organisational objectives will be viewed at the process level and how they will effect (i.e. contribute or constrain) upon the specific goals and objectives of development functions and visa versa [5]. Congruency. Objectives bring a focus to activities and processes and the sub-optimisation of activities, processes and products may occur as a result of project teams optimising solutions or process outputs to fit with their functionally specific objectives while being

562

ICED 01 - C586/653

counter-productive to the outputs of other departments [6]. Therefore, outlining the goals for one design development activity should be placed in a wider organisational context to assess its contribution or constraint on other functions achieving their goals. Constraints and Contributors to Success: The provision of objectives and the determination of how they may be realised aids in highlighting and distinguishing between obstacles that may restrain, or opportunities that may promote, the level of performance obtainable from within the focus of an objective [7] and provide the means to control the number of measures being required. It therefore remains pertinent to the success of outlining and satisfying goals that distinctions are made between constraints and contributors of the levels of performance and the specific dimensions of success. Learning'. Objectives may be detailed that are ambitious, while yet achievable, in terms of their satisfaction but such ambitious 'stretched' objectives force personnel to think and analyse the sequence and structure of the process and the way work is carried out. The setting of goals requires that, firstly, the ability to determine what state an organisation, process, etc. is in (i.e. an 'as is' understanding) from which goals can be derived and, secondly that the organisation recognises where it wants to go or what aspects it wants to improve upon (developing a 'to be' understanding). Consideration should be given, therefore, to ensure that goals outlined are ambitious but that remain within the realms of feasible in terms of process, technology and personnel capabilities. Composition of Metrics: In order to support the realisation of organisational goals, at various levels and considering the alignment, congruency, constraints and contributors of success, the identification and determination of the measures (metrics) that will help in checking the progress being made toward such goals and in determining whether such goals support higher organisational goals must be supported to determine how close you are to a target and how quickly you are moving toward a target [5]. The aim of controlling and defining the measures used at a process level, and maintaining the existence of a cascading effect is to promote a common direction, in terms of obtaining the best return on effort and work, toward common, higher level, objectives while considering the often functionally specific goals which may be beneficial to the function but not to the overall process performance level [8]. Current research within the area advocates the need to balance the mix of measures between highlevel organisational dimensions while the identification, and application of appropriate metrics within such balanced dimensions remains to be conducted erratically and intuitively. Overall and Sub-level Index: Providing management and process level personnel with an inter-related and flexible method to specialise and generalise measures throughout an organisation, while maintaining the congruency and alignment of measures, provides the ability to obtain an overall sense of improvement or detriment at various organisational levels and the means to specialise their focus to identify (sub) optimal performance. The ability to generalise from lower levels of an organisation to drive an overall performance index enables: the identification of contributors and retractors of performance; the ability to compare the performance of distinct departments, functions etc.; and, allows management to generalise and specialise their focus or concerns providing the means to control the range of measures in reflecting and supporting organisational strategic viewpoints. Relational structures: The preceding points have all discussed the need to enable the relations between goals, metrics, organisational functions to be identified, quantified and structured. There is thus a need to: firstly, understand how the satisfaction of one goal will impinge upon other organisational goals identifying any conflict between goals; secondly, detail the structure of metrics throughout relevant functions of the organisation to provide

ICED 01 - C586/653

563

focus and to identify the level of progress being made; and lastly, enable performance measurements to reflect the structure of an organisation and the hierarchy of goals within. In addition, any person involved in an organisation has a perspective on the organisational system and therefore their goals may be different, or refer to distinct but affected or affecting goals. Thus, an organisational wide performance measurement system should relate between measures/metrics, goals/objectives and perspectives/viewpoints. While the identification of the relationships between related entities enables more informative decisions to be made, the need to identify their effects, i.e. positive or negative, relative to the perspectives, and the density of interactions are also important in determining the stability of a process and how changes made to improve performance will be received by other organisational functions [9]. The existence today of a plethora of various performance measurement systems has indeed pushed our understanding of the constituent factors of organisational performance and given practitioners a multitude of issues and dimensions of performance to consider. However, at a fundamental level of performance, in determining organisational down to process levels of performance, we need to understand how do such performance measurement approaches, frameworks, formalisms and methodologies perform.

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 strategic directions taken by organisations but in addition provides the means to identify the improvement requirements and the drive behind improvement initiatives [10]. Based on the requirements raised in the preceding section a sample of performance measurement systems have been reviewed (as summarised in Table 1) to determine the depth of support that is provided to those involved in such multiple consideration processes as design development. For a more comprehensive analysis, including a detailed list of references, see Haffey [11]. Table 1. Performance Measurement Systems Evaluation Matrix

Requirements & Evaluation Criteria

Balanced Scorecard BEM (EFQM) Cambridge Model Integrated P.M. Performance Pyramid

Intuitive

Intuitive

Intuitive

-

Intuitive

-

Intuitive

Intuitive

Intuitive

-

Intuitive

Intuitive

Intuitive High level

Intuitive

Intuitive Intuitive

Related High level

The Balanced Scorecard is a framework that considers four organisational perspectives (Financial, Customer, Internal, and Innovation & Learning as shown in Figure 1) that are

564

ICED 01 - C586/653

purported to provide both a balanced representation of, and the perspectives upon which to analyse, an organisation. Within each perspective a list of objectives, and in turn metrics, are defined and clustered allowing an organisation to develop its own specific "Balanced Scorecard". The framework advocates a balance between financial and non-financial measures and it is purported that the analysis of the measures used will detail the strategy being deployed within an organisation. However, these measures and objectives are derived intuitively, and at user's discretion, and at such specific and complex levels of consideration concern as to the most appropriate mix or balance of measures being used to support strategic objectives must be expressed. Thus, it lacks the necessary means to determine the right things are considered with the rationale associated with the measures used, such as time based, or recognising when a measure becomes obsolete and is no longer required. Based on the requirements outlined previously in Section 2 the Balanced Scorecard provides no support in defining either organisation or process level goals and are therefore restrained in: maintaining the alignment and congruency of measures; identifying constraints to or contributors of success; and, providing the basis upon which to learn, identify and utilise competencies. The lack of support to identify applicable metrics in the context of organisational strategies provides no means of deriving process level sub indices from within its four perspectives. The Business Excellence Model (BEM), developed by the European Foundation for Quality Management (EFQM) provides practitioners with a framework that considers that the processes used to deliver people satisfaction, customer satisfaction and impact on society are attributable through leadership, controlling and defining organisational policies and strategies, managing people and allocating resources in order to produce excellence in its business results. Figure 2 shows the model, consisting of five enablers (what an organisation does i.e. Processes) and four results (what an organisation achieves i.e. Outputs or Goals), which is reported to provide the generic criteria that are deemed to assess an organisation's progress toward excellence. Again, the model provides a generic framework from which to intuitively derive the most appropriate goals and measures but lacks the depth to consider the alignment and congruency of goals and metrics and the potential to gain insights and learn from the constraints and contributors of success. The high level generic structure may provide overall indexes within results and enablers but relies on the intuitive extraction of measures to reflect operations at a process level and therefore provides no support in identifying what enablers are concerned with the achievement of results at lower more specific levels.

Figure 1. The Balanced Scorecard

Figure 2. Business Excellence Model

A process which supports organisations in developing a performance measurement system, the Cambridge Model as shown in Figure 3, comprises of two, five part, phases that provide the skeletal framework upon which high level measures and concerns are used to derive lower

ICED 01 - C586/653

565

level process measures. Phase one supports the identification, design and implementation of high level, strategy orientated, performance measures where organisational objectives and their associated or related measures are agreed upon, based on specific product strategies, and embedded into high level organisational decision making activities. Phase two aids in cascading high-level objectives and measures down to the process level based upon the key performance indicators and drivers. The model supports users in navigating through the process of developing and relating goals and measures but again relies on the intuitive extraction of goals and measures and the recognition of how they relate across and through an organisational structure. The model does acknowledge the need to support in identifying the interactions between measures, within isolated organisational levels, but relies upon a relational matrix to intuitively explicate their existence.

Figure 3. Performance Measurement System - Cambridge Model

A framework put forward by Nanni et al., Integrated Performance Measurement, emphasises the explication of relationships between an organisation's strategy, its actions and the utility of performance measures as shown in Figure 4. The framework refers to integrated as strategic-driven performance management through the congruency of actions across functional boundaries while in the context of strategic objectives. Their work argues the need for identifying process level goals and measures as derived from organisational strategies while they support the need to structure the goals and measures to align and be congruent within an organisational structure. However, the framework proposed falls short of supporting the identification of appropriate goals, measures and their inter-relationships. In addition, Nanni et al. recognise the need to identify the constraints and contributors to success and thus learn from the strengths and weaknesses of process capabilities yet the approach lacks the ability to explicate such information. The Performance Pyramid provides a means of deriving operational measures from organisational strategies. The approach outlines four levels within an organisation from the corporate vision, business units and business operating systems down to departments and identifies key, generic, dimensions within each level as outlined in Figure 5. The key objectives reflect key concerns at each level and are related and broken down to lower level, more specific, objectives with the recognition for the measures, related to objectives, to be aggregated back up through an organisation to support the recognition of effort being focused on working toward the satisfaction of objectives. While the approach identifies the key dimensions (high level and related low level), which should be addressed and measured at a process level, it provides little support on how to identify and integrate the relevant goals and measures. The approach does begin to address the need for the alignment of dimension goals/measures but lacks any depth in understanding their structure, interactions and cause and effect relationships and therefore restrains the potential opportunities to learn. In summary, system approaches and discussions on performance measurement have all concentrated on strategic objectives and the generic dimensions but lack the contribution in

566

ICED 01 - C586/653

supporting how such performance dimensions can be deployed to/from a process level while relegating the modelling of processes in terms of 'as is' to a secondary requirement.

Figure 4. Business Management Cycle

Figure 5. The Performance Pyramid

Even at such high level considerations the information required to manage the concentration or reduction in the degree of effort along the dimensions factored in strategic foci is not generated and in some cases equal weightings and considerations within relevant dimensions is prescribed. The utility of performance measurement approaches have been focused upon, at a general level, one of determining the dimensions of performance that will support the focus of effort in realising strategic objectives and in determining organisational health. However, none support, explicitly or based on factual feedback, the mapping of organisational goals which is needed to analyse and control processes in the context of organisational and process level objectives and thus lack the opportunities to stimulate learning, improve communication and affect behaviour. O'Donnell and Duffy provide a means to enable the alignment and congruency of objectives and measures in addition to providing the basis upon which to explore the relationships between the components of process performance [12, 13]. Through the ability to cascade process level performance measures throughout the corporation the existing reliance upon identifying the measures that support the satisfaction of performance goals through intuitive means may be overcome.

4

Conclusion

The ability of organisations to objectively set strategic goals, identifying the path along which such goals may be realised, requires a considerable degree of knowledge of the organisation, the environment within which it operates and the potential source from which major threats and opportunities are likely to arise. The complex nature of a design process requires consideration of the performance required from subsequent process activities in addition to its own and therefore requires prescriptive information on the levels of performance both required and attainable. This indeed contributes to the complexity of the design process and emphasises the need to provide prescriptive decision-making information. In order to provide such prescriptive information the need to support understanding and learning what has happened, by understanding goal and metric structures and their interactions, and predicting what is about to happen must be recognised. However, based on an evaluation of existing performance measurement approaches a substantial lack of support exists that brings organisational objectives down to a process level and that aids the identification of measures to support the focus of effort toward the satisfaction of such high-level objectives. Thus, the

ICED 01 - C586/653

567

opportunities to learn from past experiences and to map out and utilise the concept of causality is severely restricted. The authors are currently developing a methodology which will enable organisations to model and understand process performance behaviour. The research will focus upon overcoming the inherent weaknesses identified in existing approaches by providing a methodology to identify, structure and manipulate the key performance dimensions through machine learning techniques and performance modelling. References [1]

Griffin, A. and Page, A. L., "PDMA Success Measurement Project: Recommended Measures for Product Development Success and Failure", Journal of Product Innovation Management, Volume 13(6), 1996, 478-496.

[2]

Shay, J.P. and Rothaermel, F.T., "Dynamic Competitive Strategy: Towards a Multiperspective Conceptual Framework", Long Range Planning, Volume 32 (6), 1999.

[3]

Prichard, R.D., "Measuring and Improving Organizational Productivity: a Practical Guide, Praeger Publishers, New York, 1990.

[4]

Loch, C., Stein, L. and Terwiesch, C., "Measuring Development Performance in the Electronics Industry", Journal of Product Innovation Management, Volume 13, 1996.

[5]

Kerssens-van Drongelen, I.C. and Cook, A., "Design principles for the development of measurement systems for research and development processes", R&D Management, Volume 27(4), 1997, 345-357.

[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 to Manufacturing 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 Measurement System: Auditing and Prioritisation of Performance Measures", First Intl Conf on Performance Measurement, University of Cambridge, 14-17 July 1998. [11] Haffey, M.K.D., "Process Performance Measurement: Mapping the Requirements to the Support", Internal Report, CAD Centre, University of Strathclyde, February 2001. [12] O'Donnell, F.J. and Duffy, A.H.B., "Modelling product development performance", International Conference on Engineering Design, Germany, 24-26 August, 1999. [13] O'Donnell, F.J., "A Methodology for Performance Modelling and Analysis in Design Development", Doctoral Thesis, University of Strathclyde, March 2001. Mark K. D. Haffey: CAD Centre, DMEM, University of Strathclyde, 75 Montrose Street, Glasgow, Scotland, United Kingdom, Gl 1XJ. Tel: +44 (0) 141 548 2374, Fax: +44 (0) 141 552 0557, E-mail: [email protected], URL: http://www.cad.strath.ac.uk. © M K D Haffey 2001

568

ICED 01 - C586/653

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

THE METHODOLOGY FOR SYSTEM INTEGRITY IN DESIGN J K Raine, D Pons, and K Whybrew Keywords: Design process, knowledge-based systems, probabilistic design, system integrity

1 Introduction This paper introduces a methodology for designing for system integrity [1] in multicomponent systems and minimising risk from early in the conceptual phase, where uncertainty is high. The process involves probabilistic reasoning in propagating both qualitative and quantitative effects of changes, or uncertainty in component or sub-system specifications, through system models, and determining the integrity of the design from multiple viewpoints. The methodology is very versatile and the software that has been developed not only handles Design for System Integrity (DSI), but has also been demonstrated for a number of other tasks, such as evaluating system reliability, investment appraisal for engineering and other projects, and risk assessment in project management. The software has particular value in assisting the design manager to evaluate the robustness of design alternatives at the conceptual stage when there is a high level of uncertainty. The use of the software as an aid to design management is described in detail by Pons [1].

2 The Design Process and Knowledge-Based Systems in Design A systems approach to design involves the identification of a functional model for the engineering system and the creation of a number of sub-systems and components, between which there are defined interfaces and transfers of material, energy and information. As the design is refined, sub-system concepts, embodiments and details are altered to a more final state. At each level, the designer needs to understand how the relationships between subsystems or components affect the overall integration of the design, and ultimately the cost, performance, robustness, reliability and other important characteristics of the system. Research at the University of Canterbury into the management of design and new product development in New Zealand [2] indicates that few engineering designers in industry follow systematic design processes such as proposed, for example, by Pugh [3] and Pahl & Beitz [4]. This research [5] has also shown that communication is often lacking between product development team members working on different sub-systems. This results in recurring cycles of task clarification, conceptual, embodiment and detail design, often late in a project. Raine et al [6] have proposed diagrams to better represent concurrent activity between customer-focused design, manufacturing and marketing functions in the design process, and to illustrate the recursive process of exploring sub-system and component interrelationships. These relationships, which will be numerous in a multi-component system, are examined from various viewpoints, such as in Pugh's Elements of Design Specification [3]. The

1CED 01 - C586/024

569

objective of the research described in this paper was to develop a methodology and software to operate as an aid to design managers in determining the integrity of a design from multiple viewpoints, for example whole life cycle cost, performance, noise level, appearance, manufacturability, maintainability, or reliability. It was desired to be able to evaluate rapidly, using analytical or qualitative design rules, the effect of specification uncertainty or changes (design alternatives) in one component or sub-system on other components and on the whole system, from the different viewpoints, and, importantly, at the early conceptual design stage when there is a high level of uncertainty. Antonsson et al [for example, reference 7] have presented notable work on methods for incorporating imprecision in engineering design decision-making. Antonsson's Method of Imprecision allows for uncertainty at early design stages using fuzzy calculus but does not appear to propagate qualitative effects through the design model. Pons [1] has compared the features of Antonsson's method with the DSI methodology described below. The research of Pons [1] highlighted a need for design models or methodologies that can explore how the design behaves [8] handle non-numeric parameters and evaluation of tolerances evaluate a configuration without being forced to assign values to the attributes use a symbolic representation in preliminary design when embodiment and geometry may be uncertain [8] measure and quantify lifetime performance of designs. Knowledge-based software packages to assist the designer in exploring conceptual alternatives or in the analysis and optimisation of a given design are now common, for example in software models of complete motor vehicles. However, such methods have generally only been successful in specific domains, as they require relatively complete problem definition [9], which is often unavailable in early design where uncertainty is high. In this problem domain, artificial intelligence methods have generally only been successful in well-defined applications that have fixed design strategies [10]. Bartsch-Sporl and Bakhtari [11] set out the requirements of artificial intelligence implementations as: Completeness of knowledge in the domain model Consistent logic within the domain Closed domain, not vulnerable to outside effects Problems that can be decomposed and recomposed Solution spaces that can be formally defined. They point out that real life design domains seldom meet these requirements precisely, and their strategy has been to use artificial intelligence to assist the human designer rather than to solve design problems on its own. An example of a more successful implementation has been the "Schemebuilder" model of Bracewell et al [12], which helps the designer assess a design scheme from a functional viewpoint, principally by functional simulation. Rather than automating design using the expert system approach, this system provides decision support and allows the human designer to apply judgement and quickly evaluate alternative design solutions.

570

ICED 01 - C586/024

3

Design for System Integrity Methodology

The DSI methodology and software belongs to the family of knowledge-based systems that help the designer assess a design scheme from a functional viewpoint. The DSI methodology propagates (at concept, embodiment or detail design stage) both quantitative and qualitative knowledge about design parameters through a tree structure not dissimilar to a fault tree or decision tree. The process is outlined in the flow diagram of Figure 1.

Figure 1. Flow chart illustrating core process of the Design for System Integrity (DSI) method

Space does not permit a comprehensive explanation and illustration of the methodology, which has been fully described by Pons [1], and which will be published elsewhere in more detail. However a brief example is presented below.

1CED 01 - C586/024

571

The research used as a key example the design of automatic dishwashers. The designer identifies key devices in the model. In the case of the dishwasher the DSI process system is defined typically with physical devices, eg "wash pump", "sprayer", etc. Each of these is attributed properties that relate to one or more of the viewpoints from which system integrity is to be evaluated, such as "wash pump cost", "wash pump pressure". The designer then establishes the relationships between the devices. These relationships are different for each of the viewpoints under scrutiny, and can be either quantitative (numerical, e.g. fluid power = pressure x volume flow rate), or qualitative (textual). Wash performance of the dishwasher is modelled as 100% less the soil demerit points. The overall effectiveness of soil removal is represented by a substantial and complex DSI tree structure that has been fully described by Pons [1]. Space here only allows for brief examples of quantitative and qualitative DSI processes. Quantitative links give rise to numerical relationships, and are defined in terms of basic mathematical operators (addition, subtraction, multiplication, and division), or more complex mathematical functions (eg reliability functions such as the Weibull distribution) or even by logical functions (maximum, minimum). The elemental process in the DSI methodology involves taking two discretised input probability distributions, applying a quantitative operator (such as +, -, x, /, maximum, minimum) or qualitative map (using decision theory) to determine an output distribution. In the wash performance model one of the elemental quantitative combinations in the subsystem computation for soil particle demerits evaluates the water retained in the machine at the end of the wash cycle as the sum of the water retained in the sump and the water retained as a film on the wash cavity. The fragment of the DSI tree containing this operation is shown in Figure 2. The inputs in this case are represented respectively by normal and Weibull probability distributions. The addition of the two discretised probability distributions, represented as histograms, is illustrated in Figure 3. The process can be computationally demanding. In this example, if the two probability distributions were each approximated by 100 discrete values, there will be 10,000 calculations to form the combined distribution, and there may be many such combinations in the overall DSI analysis tree just for the wash

Figure 2. Fragment of DSI computation for soil particle demerits within wash performance DSI tree Figure 3. Sum of sump (normal) and cavity (Weibull) retained water probability distributions to give an output as the bold line. The horizontal axis is volume in litres and the vertical scale probability density.

performance. In the retained water computation each of the 10,000 additions has an associated joint probability being the product of the probabilities of the component water volumes. The overall joint probability for a specific value of retained water volume is the sum

572

ICED 01 - C586/024

of the various joint probabilities associated with the occurrences of that specific retained water volume as an outcome. Qualitative parameters are defined in textual terms. These could be pseudo-scalar values such as a temperature scale ("hot, warm, cool, cold"), or more abstract terms such as the type of soil present on dishware (e.g."sauce, mashed potato, breakfast cereal") and soil thermal treatment ("fresh, dried, reheated, baked, burned"), where no scale of precedence exists. A mapping process similar to that used in decision tables describes textual relationships and enables qualitative information to be propagated through the DSI tree. The expert defines this map at initial configuration of the system. For example, if wash performance (''bad, marginal, acceptable, good, excellent") of the dishwasher is dependent on soil thermal treatment and soil type, in a way which cannot be quantified, then the expert sets up a decision table which gives the resulting wash performance for every combination of the inputs soil thermal treatment and soil type. However, the expert does not give a single point deterministic estimate of the result, but gives the probability of each of the outputs. A fragment of a wash performance map relationship is shown in Figure 4, in which the map takes soil thermal treatment and soil type, and combines them to produce the output. A soil thermal treatment model is shown in Figure 5. It ranges from fresh to burned soil and, in the example shown, all the soil is taken as dried, which therefore has a probability of 1. A soil type profile is shown in Figure 6, where the proportions have been determined from the relative masses of the soils.

Figure 4. Representation of a map Relationship in the Design Integrity Software

Figure 5. The profile for soil thermal treatment.

Figure 6: Soil type shown as a histogram based on mass of various soils used in standard dishwasher performance tests.

1CED 01 - C586/024

573

In the example illustrated here, soil state is computed by applying a subjective map to soil type and soil thermal treatment. A fragment of this map is shown in Figure 7. For example, in Figure 7, in the case of fresh egg, the likelihood would be 50% as soluble film and 50% as sticky paste. The output of the map process is soil state as shown in Figure 8.

Figure 7.

Map to convert soil type and soil thermal treatment into soil state. Numbers are probabilities where any one column will sum to unity.

Figure 8.

Soil state is a combination of soil type and soil thermal Treatment. It describes the important wash characteristics of the soil.

Once the system has been defined by appropriate quantitative and qualitative relationships, the end user (who may be different from the expert designer) determines the input attributes. For example, the user might assert that water temperature is warm. This can then be propagated through the system to determine the resulting wash performance and other outputs. A more realistic assertion at early design stages might be to give a probability distribution e.g. 30% hot, 50% warm, 20% cool, 0% cold, to encompass the uncertainty that exists at this stage. That is, the designer is leaning towards using a hot-warm set point on the thermostat, but wants to include the smaller possibility of a cool running option. After distributions are specified for all the inputs, the system outputs are computed as probability distributions for each parameter. If necessary, alarms (acceptance limits) can be

574

ICED 01 -C586/024

defined by the user for any parameter, and these can be checked during computation. The end result is a set of distributions for each of the viewpoints defined. For each viewpoint from which the designer wishes to evaluate the integrity of the system, knowledge about all of the contributing parameters feeds in at the outer most branches of the tree and the DSI software then computes an outcome probability distribution for the viewpoint concerned, e.g. overall wash performance, product cost or product reliability. Effects from various viewpoints may also be studied concurrently. For example, in evaluating wash performance of the dishwasher, selection of a different circulation pump to reduce cost may alter water pressure and trigger responses from component properties relating to seal performance, system energy consumption, and water flow rates. The DSI software engine applies probabilistic computation in a combinatorial fashion and allows both numerical and textual relationships in the same model. This is a departure from established techniques, where the effect of variability in multiple parameters affecting an overall outcome, and the associated numerical relationships, have commonly been handled using Monte Carlo methods [13]. The DSI numerical method avoids Monte Carlo simulation altogether, although it has similar functionality and computational power. It also provides the functionality of decision theory. The ability of the DSI methodology to propagate the effects of a change in a design parameter means mat the "risk" in the result (e.g. total product cost) may be identified, quantifying how good or bad the outcome may be. Unlike expert system tools where the software seeks to make a decision using artificial intelligence method, the DSI method does not make decisions itself. The method is an analytical assessment tool that supports the human decision-making and design management process. The DSI software was developed in the Delphi programming language and contains approximately 40,000 lines of code. It is a comprehensive package that can handle both quantitative and qualitative system integrity computation from multiple viewpoints.

4

Conclusions

Designers can have difficulty grasping the multiple relationships between systems, subsystems and components. The Design for System Integrity (DSI) methodology has been developed as a software tool to assist in faster evaluation of system integrity from multiple viewpoints. It therefore offers a rapid means of comparing design alternatives. The methodology fuses quantitative and qualitative assessment, and incorporates probabilistic reasoning. The ability to propagate both qualitative and quantitative information, and process variability, through the system model means that: 1. The DSI methodology can be applied to a number of different domains, and in particular, may be used in the early conceptual design stages when data are typically sparse. 2. System integrity may be assessed in a way that is impossible using conventional deterministic methods. References [1]

Pons, D., "A methodology for system integrity in design", PhD thesis, University of Canterbury, Christchurch, NZ, March 2001.

1CED 01 - C586/024

575

[2]

Shaw A., Aitchison, D.R., Raine, J.K., Whybrew, K., "Summary of results of the survey 'Rapid Product Development for World Class Manufacturing'", Technical Report No. 58, Department of Mechanical Engineering, University of Canterbury, May 2000, 23pp.

[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, and Berlin/Heidelberg, Springer-Verlag, 1984.

[5]

Whybrew K., Raine J.K. and Dallas T.P., "The Application of Design Phase Diagrams in the Management of Design of Telecommunications Products", Proc. 12th International Conference on Engineering Design. Munich 24-26 August 1999, 3, pp1519-1524.

[6]

Raine, J.K., Pons, D., and Whybrew, K., "The design process and a methodology for system integrity", Short Communications in Manufacture and Design. Proc. IMechE PartB. 2001 (to appear)

[7]

Antonsson, E.K. & Otto, K.N., "Imprecision in Engineering Design", Journal of Mechanical Design. Transactions of the ASME. 117B, 1995, pp25-32.

[8]

Finger, S. and Dixon, J., "A review of research in mechanical engineering design". Part 2: Representations, analysis and design for the life cycle, Research in Engineering Design. 1.1989. pp121-137.

[9]

Candy, L., Edmonds, E. and Patrick, D., "Interactive knowledge support to conceptual design", in Sharpe J. (ed), "Artificial intelligence system support for concept design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp260-278.

[10] Tang M., "Development of an integrated AI system for conceptual design support", in Sharpe. J (ed), "Artificial intelligence system support for conceptual design", Proc. 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp153-169. [11] Bartsch-Sporl, B. and Bakhtari, S., "A support system for building design - experiences and convictions from the FABEL project", in Sharpe J (ed), "Artificial intelligence system support for conceptual design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, pp279-297. [12] Bracewell, R.H, Chaplin R.V., Langdon P.M., Li M., Oh V.K., Sharpe J.E.E., and Yan X.T., "Integrated platform for AI support of complex design (Part 2): Supporting the embodiment process", in Sharpe J. (ed), "Artificial intelligence system support for conceptual design", Proceedings of the 1995 Lancaster International Workshop on Engineering Design. Springer, 1996, ppl 89-207. [13] Kleijnen, J.P.C., "Verification and validation of simulation models", European Journal of Operational Research. Elsevier Science B.V. 82(1), 1995, pp145-162. Professor John K. Raine Department of Mechanical Engineering University of Canterbury Private Bag 4800 Christchurch New Zealand Telephone: +64 3-364-2571 Fax: +64 3-364-2078 E-mail: [email protected] ©IMechE 2001

576

ICED 01 -C586/024

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

CHANGE PREDICTION FOR PRODUCT REDESIGN P J Clarkson, C Simons, and C M Eckert

Keywords: change processes, design management, risk analysis and management

1

Introduction

Product redesign is common in many industry sectors, for example in automotive and aerospace, where 'new' products are derived from earlier designs as a means to maintaining product quality whilst reducing design and production lead time. However, the redesign of such complex products is seldom straightforward and can be effected by the propagation of changes - a small initial change can instigate numerous other changes, possibly having serious cost implications. Despite this risk, industry currently lacks a clear approach for predicting and representing change propagation [1] and is dependent on the past experience of product experts to minimise its effect. The aim of this research is to reduce unexpected change propagation in product design. The objectives of the work reported in this paper were to explore the scale of change propagation in aerospace design and to develop an approach for predicting the effects of change propagation in redesign. A computer tool has been developed to support this approach accompanied by an efficient format for representing such information.

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, civil and military markets. Within these markets customers have different requirements for equipment, radar, weapons and load-space. It is therefore particularly important that the impact of these differing requirements are fully understood before the contract for a new craft is signed. Hence, the model presented in this paper is intended for use during tendering and for assembling design teams in early conceptual design for customisation. The research began with an extensive series of interviews with chief designers and a manager responsible for producing tendering estimates for new projects within GKN to explore the nature of change in helicopter redesign. Several key points emerged from these interviews: designers frequently fail to realise how their design decisions will affect others; knock-on changes (change flows) occur, resulting in changes typically no more than 4 steps (components / systems) removed from the initial change; estimates of unexpected changes ranged from 5% to 50% of those actually encountered.

ICED 01 -C586/070

577

In addition, design changes resulting from a number of specific redesign requirements were identified, for example the introduction of two additional countermeasure dispenser pods.

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 further developed and incorporated into an executable method usable by industry. It is this development, along with some of the insights gained from the interviews, which are presented in this paper.

3.1 The change propagation model The Change Propagation Model is derived from a Product Model, itself the result of the decomposition of the product into a set of systems and sub-systems, and their related dependencies (Figure 1). These dependencies, obtained from an analysis of the product architecture, are defined in terms of the likelihood that the redesign of a component will force the redesign of another and the impact, or extent, of that redesign. A matrix entry represents the dependence of the component identified by the row on that identified by the column.

Figure 1. The Change Propagation Model

The Product Model is constructed in two stages. First, a number of product components are identified, which together represent the whole of the product. These define the row and column headings in the product model matrixes. Second, the direct likelihood and impact relationships between the components are determined. To date this latter activity has been undertaken by interviewing people with experience of designing the product in question and through workshops that are used to elicit a consensus view.

578

ICED 01 -C586/070

The characterisation of component relationships by their likelihood and impact allows changes to be considered in terms of risk, i.e. the product of likelihood and impact [4], throughout the analysis. Once the component dependencies have been captured, the possible paths of change propagation can be determined. The change propagation algorithms, based on probability and Venn diagram arguments, can then be used to identify the overall likelihood and impact of a change propagating to other components. The risk, or likely impact, can be expressed in a number of ways, but perhaps the most useful is as the likely cost of the changes predicted. This cost can then be measured directly, in monetary terms, or indirectly, as an expression of the time required for redesign. Further details of the algorithms used are to be found in another paper [3]. There are many issues regarding the appropriate choice and number of components, the definition and quantification of likelihood and impact, and the specification of the initiating change. These are the subject of ongoing research. However, a number of these issues, in particular the sensitivity of the change predictions to variations in the input data, will be discussed later in the paper.

3.2 A change prediction method The Change Propagation Model has been incorporated into a change prediction method, as illustrated in Figure 2. This comprises three stages: an initial analysis; a case by case analysis; and the actual redesign. The initial analysis stage involves the definition of the product model and computation of the change propagation model. This provides a summary of the change propagation characteristics for the whole product. The results of this analysis can be presented in a 'graphical' product risk matrix (Figure 2 and in more detail in Figure 3), where the size and shape of each element indicates the likelihood (width) and impact (height) of change between any two systems. This allows easy assessment of the potential for change propagation. Indeed systems which are susceptible to change, or initiate change are easily identified.

Figure 2. The Change Prediction Method

ICED 01 -C586/070

579

In order to assess the potential change resulting from a particular change request, an analysis of the specific case is required. The change request is first associated with the systems that it immediately effects. The product change propagation model can then be used to reveal other systems that may be affected. A case risk plot (Figure 2) represents the predicted likelihood and impact of these effects (a subset of the data shown in the product risk matrix). Points in the upper right corner of the plot are the most important, as they represent both the most probable and most expensive changes. When presented with a particular new product requirement, the case risk plot allows managers and designers to see and compare the risk of change to different components. This information enables better estimation during tendering and acts as a checklist during design. Finally, the last stage represents the actual redesign of the product, hopefully achieved in a more informed manner at a lower cost. The following case-study will serve to illustrate the construction of the Change Propagation Model and its use in the Change Prediction Method.

4

An example of change prediction

The change propagation model and prediction method have been tested using case studies from GKN Westland Helicopters, based on known changes made to variants of the EH 101 helicopter. In all three cases studied, the method predicted all the changes observed, including those not present in the original product model. In fact, in most cases, the changes observed were those representing the highest change risk and highest likelihood of occurrence.

4.1 TheEHlOl change propagation model A change propagation model was derived for the EH101 after individual discussions with four chief engineers and a team meeting. There was much debate regarding the 'appropriate' number of components to be identified, with estimates ranging from 19 to several hundred. There is a trade off between using a large number of components, making it easier to identify and cost particular dependencies, and a smaller number, requiring an averaged view of dependency with the advantage of reducing the scale of the model. Small matrixes for complex products are inherently ambiguous, because the components can be linked through many dependencies (see [5] for a discussion of the connectivity). Two solutions were pursued. The first addressed over 200 components, resulting in a sparsely populated matrix documenting specific historical changes, aimed at helping designer during redesign. The second, reported here, addressed 19 components (still over 350 dependencies), where each dependency represented the consensus view of the team present and related to the likely changes that could be expected to propagate. Likelihoods ranged from 0 (no change propagation) through 0.05 (very unlikely propagation) to 1 (certain propagation) and impacts ranged from 0.001 (minor change) to 1 (major change). In this particular case actual costs were not used to preserve confidentiality and the impacts are a measure of the degree of change predicted. The product risk matrix for the 19 components derived using a three-step propagation analysis is shown in Figure 3. The rows and columns of the matrix have been reordered to highlight those components most likely to initiate change (right-most columns) and those most susceptible to change (upper-most rows).

580

ICED 01 - C586/070

Therefore changes that would demand a change to the main rotor are not tolerated and must be reconsidered.

4.2 Change prediction for the EH101 A particular customer requirement involved the introduction of two additional countermeasure dispenser pods, a part of the weapons and defensive systems. This initial change resulted in local structural reinforcements (bare fuselage), addition of a deflector plate to protect the inflight refueling system (fuel and fuselage additional items), repositioning of the UHF antenna (fuselage additional items), nose cap adjustments (bare fuselage), forward looking infra-red radar system modifications (fuselage additional items), Cabling and Piping revisions, Avionics changes and flotation system adjustments (equipment and furnishings).

ICED 01 -C586/070

581

The case risk plot for an initiating change to the weapons and defensive systems is shown in Figure 4. This comprises all the data point from the weapons and defensive systems column of the product risk matrix. Note that the risk plot shows data normalised onto 0 to 1 log scales.

Figure 4. An EH101 case risk plot

A comparison with the changes known to have taken place revealed 6 out of a possible 18 changes were observed, where these represented 2/3 of all the predicted changes found in the upper third of the likelihood scale. In addition, half of the observed changes were not predicted by direct dependencies and only came to light following the application of the change prediction method. This latter point illustrates the power of the method in highlighting all areas of potential design change in response to new product requirements. Two further case studies showed similar results with many of the higher likelihood changes predicted being the same as those observed.

5

Discussion of the results

The preliminary results presented above suggest that the change prediction method has promise in identifying and rank ordering potential changes as a response to modified design requirements. However, further research is necessary to validate these claims. In particular: the prediction algorithm needs to be verified for its suitability for use with larger matrices; related to this, the most effective granularity of the model needs to be established; the sensitivity of the predictions to variations in input data needs to be investigated; and finally, the usefulness of the method needs to be tested with further case studies.

582

ICED 01 -C586/070

The first of these points is the subject of current research. In principle, there is no reason why the current algorithm, based on an investigation of all possible propagation routes [3], cannot be expanded to larger problems. In practice, however, the computational cost associated with such problems is likely to be unacceptable. As a result the use of Monte Carlo simulation, which uses a sample of the propagations to estimate potential change, is being investigated. The sensitivity of the change prediction method to variations in the input data is an important consideration. If the sensitivity is too low, the method will be unable to provide distinct solutions for varying versions of a product. If the model is too sensitive, slight inaccuracies in the initial data may result in misleading results. A preliminary investigation into the sensitivity of the method has been conducted. The effect of varying each likelihood and impact value by 20% of full-scale (i.e. 0.2) was calculated for the example case presented in the previous section. Variations causing maximum changes in the predictions were then noted. The order of the predicted changes, from highest to lowest risk, are compared in Figure 5 for the original and maximally changed data.

Figure 5. An investigation of change prediction sensitivity

Although the order of a number of components changes, the top five components do not move. In addition, the components that do just shuffle do so within small groups. Thus, although the data may be quite sensitive to changes, the rank ordering by risk of the predicted changes is largely insensitive to changes in the input data, at least for the case studied. Further case studies are also underway. These will look at the design of hydraulic valves, automotive powertrain systems, special purpose vehicles and lifting gear.

ICED 01 -C586/070

583

6

Conclusions

A method for predicting change propagation in product design has been developed along with an efficient format for representing the results. Initial case study evaluations have been promising, with good correlation between predicted and observed changes. The change prediction method suggests the possibility of a number of benefits to industry, including: better cost predictions in the tendering process; assistance in (human) resource management; support for less experienced designers; identification of potential for increasing product modularity. In summary, the change prediction method offers a potential tool for identifying and managing change in product redesign. Further work is in progress to develop and validate the method with other case studies from different industry sectors. Acknowledgements The authors are grateful to the UK Engineering and Physical Sciences Research Council (EPSRC) and GKN Westland Helicopters Ltd for their support of this project. References [1]

Lindemann, U and Reichwald, R (1998), Integriertes Anderungsmanagement. SpringerVerlag, Berlin.

[2]

Steward, D V (1981), "The Design Structure System: A method for managing the design of complex systems," IEEE Transactions on Engineering Management, 28(3), pp71-74.

[3]

Clarkson, P J, Simons, C S and Eckert, C M (2001), "Predicting Change Propagation in Complex Design," Proceedings of DETC: 13th International Conference on Design Theory and Methodology. Pittsburgh, Pennsylvania, 9-12 September.

[4]

Coppendale, J (1995), "Manage risk in product and process development and avoid unpleasant surprises," Engineering Management Journal. February 1995, pp35-38.

[5]

Eckert, C M, Zanker, W and Clarkson, P J (2001), "A better understanding of change in the development process", Proceedings of ICED 2001.

Dr P John Clarkson Engineering Design Centre University of Cambridge Trumpington Street Cambridge CB2 1PZ United Kingdom Phone: +44 (0)1223 332 742 Fax: +44 (0)1223 332 662 E-mail: [email protected] © Cambridge Engineering Design Centre 2001

584

ICED 01 -C586/070

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

SURVEY OF CURRENT UK PRACTICE IN MANAGING TECHNICAL DESIGN RISK R Crossland, C A McMahon, and J H Sims Williams Keywords: risk analysis and management, survey

1 Introduction Risk management is essential to the success of any engineering design project because design is, by its very nature, an activity that involves risk. The only way to eliminate the risk that a designed artefact will fail to meet its requirements would be to forgo the design process, and instead reuse an existing artefact of precisely known performance characteristics. With increasing product and project complexity the use of formal risk management processes during design, supported by suitable tools and techniques, has become more prevalent [1]. The importance of managing risk has led to the recent development of a number of risk management approaches [2][3], and to risk management becoming a contractual requirement for many projects in the public and private domains, in particular in military procurement [4]. Interest in risk is international: the US Project Management Institute has established a Risk Management Special Interest Group [5], as has the UK Risk Specific Interest Group of the Association for Project Management [6]. However, the importance of risk management varies significantly with industry, and the emphasis in risk management has been more strongly on project risk - the likelihood of a project failing to deliver on time and budget - rather than technical risk - the likelihood of a designed artefact performing as designed and to cost. As the emphasis on risk management has grown, a number of studies have been carried out to identify the extent to which risk management has penetrated industrial practice, and the nature of the techniques that have been most widely applied. Examples of these studies are Baker et al's survey [7] examining the dependency between industry sector and risk management practices (construction and oil & gas sectors are compared) and Raz and Michael's study [8] of the use of project risk management tools in software and high-tech industrial sectors in Israel. Raz and Michael found that simple easy-to-apply tools were the most successful, along with simulation, whereas Baker et al suggest that personal/corporate experience and engineering judgement are the most successful techniques, with expected monetary / net present value, sensitivity analysis and decision analysis as the principal quantitative techniques, and prevention (e.g. staff training) as the favoured risk reduction method. This present paper also reports some of the results of a study of current industrial practice [9] in managing risk aimed at exploring where future efforts to improve technical risk management practice should most productively be concentrated. In the case of the present work we have however emphasised in particular the different approaches taken by companies in the design process to project risk and technical risk. The study was carried out by a combination of questionnaire and case study.

ICED 01 -C586/435

585

2 Methodology 2.1 Questionnaire Development The questionnaire was initially developed by considering the tools and techniques that might be used at each stage in the risk management process, and by giving the respondents an opportunity to specify those used in their projects. Questions were then added which aimed to determine the nature of the risks faced, the barriers to effective risk management and the degree of integration between project and technical risk management. The questionnaire was divided into three sections; the first contained questions to determine the nature of the participating companies and the size and general nature of their design projects. The second and third sections contained questions about tools and techniques for project risk management and technical risk management respectively. The results reported here concern the first and last sections. Most of the questions were "multiple choice" and could be answered by ticking one or more boxes - sometimes with an optional opportunity to explicitly name another choice which had not been included. The structure of the questionnaire is shown in Figure 1 below, along with an indication of how the presentation of a selected subset of the results is organised within this paper: Figure 1. Organisation of presentation of results

2.2 Sample Construction In total 124 questionnaires were distributed of which 63 were returned. Respondents for the questionnaire were obtained by: letters to industrial contacts of the research team and secondary contacts from wider University work (23 responses); telephone calls to companies obtained from an engineering directory (18 responses); letters to the editors of professional

586

ICED 01 -C586/435

engineering and project publications (14 responses) and a presentation made to the Risk SIG of the APM (8 responses). It is clear that such a mechanism for obtaining the sample cannot lead to statistically valid conclusions about the population as a whole: the respondents must all be assumed to have had a strong interest in risk management (in order to spend the time required to complete the questionnaire) and many of them were personal contacts of the research team. It should be noted therefore that the respondents probably already had an above average level interest in risk management, and hence may have been employed by companies with a more sophisticated risk management approach than is typical. The sample was therefore certainly biased, the results can only be regarded as indicative, not statistically valid, and any conclusions drawn are necessarily subjective. The authors believe that this is a factor in much design research: unbiased survey samples are difficult to obtain since the population of most interest is that of commercially practising engineering companies and the design engineers who work within them, who often do not have time available to participate in research. As such engineering design research surveys (e.g. [8]) can only point towards necessarily subjective conclusions, rather than providing statistically valid proof of hypotheses, but nevertheless useful insights may be obtained.

3 Results Of the 63 questionnaires returned, three were omitted because they were not from UK design companies and a further three respondents (two construction companies and one software company) were omitted because they did not complete the section relating to technical risk.

3.1 Scope of Design Projects The industry sectors of the participant companies are shown in Table 1 below. Table 1. Questionnaire respondents identified by industry sector

Industry sector Construction Aerospace Oil/petrochemical Technology/engineering consultant Manufacturing Utility supply/generation Coastal/environmental engineering Software Risk/management consultants Process Automotive TOTAL

Number of respondents 18 11 8 5 4 4 3 3 3 2 2 63

A wide range of engineering disciplines was involved in the projects; respondents were asked to select the three main disciplines involved, and the most popular responses were mechanical (67%), civil (47%), electrical (43%), software (28%), electronic (23%) and aerospace engineering (13%). The sizes of the projects varied very widely; the average number of technical personnel for a project was 47, but responses varied from two to 500. Similarly, the average number of personnel was 29, but responses varied from 1 to 500.

ICED 01 -C586/435

587

All phases of the design process were represented in the responses: requirements (87% of respondents), cost/time budget setting (92%), conceptual design (92%), embodiment design (75%), and detail design (87%). All phases of the product lifecycle were also represented: pre-bid (65% of respondents), new product introduction (58%), manufacturing (53%), product maintenance (37%) and product disposal (18%). Respondents were asked to specify whether the main kind of design work involved in their projects was original, adaptive or variant design [9]. Fifty three percent of respondents specified that their main work was original design, 28% chose adaptive design and 18% specified variant design. However, previous research [8] in which this question was addressed to designers suggests that it is likely that many people would classify what is in fact adaptive design under the "original" category.

3.2 Problematic Risks To address the frequency with which risk arises in particular areas respondents were asked "How often does technical risk arise in each of the following areas?". The areas were defined as follows: Materials: uncertainty concerning the behaviour or properties of materials; Manufacturing processes', uncertainty introduced during the manufacturing process; Usage/loads/environment: uncertainty concerning how the designed product will be used, or concerning its environment or the loads which will be placed upon it; Bought-in sub-systems: uncertainty concerning the behaviour or properties of a component or sub-system purchased from a third-party; Sub-system interactions: uncertainty concerning how components or subsystems will interact with each other; Design error within sub-system: uncertainty concerning properties or behaviour of an in-house designed component or sub-system; Aggregate budget overruns: uncertainty which cannot be assigned to a single cause, but is due to an aggregation of many uncertain design variables which must not exceed a budgeted limit. An example would be the total weight budget for an automotive design, or total power-consumption for an electrical design. The results are shown in Table 2. Table 2. Percentage of respondents who stated that technical risk arose with a given frequency for each area

Often Almost always Materials 13% 40% Manufacturing processes 12% 33% Usage/loads/environment 28% 36% 14% 32% Bought-in sub-systems 23% Sub-system interactions Design error within sub-system 12% 26% Aggregate budget overruns 18% 36%

35%

Occasionally 36%

43%'. . 32% 40% 31%

52% 32%

Almost never 11% 12% 4% 14% 10% 10% 14%

Note that in the presentation of results in the tables the percentages of respondents shown for a given risk area are calculated as a percentage of those respondents who stated that the area applied to them - i.e. the percentage of those who ticked one of the four boxes "almost always", "often", "occasionally" or "almost never" for that area. In addressing the difficulty of dealing with risk in particular areas respondents were asked "How difficult is uncertainty (and hence risk) to deal with in each of the following areas?" The responses given are shown in Table 3.

588

ICED01-C586/435

Table 3. Percentage of respondents who stated that technical risk had a given level of difficulty in each area

Materials Manufacturing processes Usage/loads/environment Bought-in sub-systems Sub-system interactions Design error within sub-system Aggregate budget overruns

Extremely difficult Difficult Quite difficult Not difficult 29% 24% 8% 39% 29% 18% 4% 49% 15% 26% 17% 43% 23% 31% 4% 42% 16% 31% 18% 35% 4% 30% 49% 17% 11% 21% 34% 34%

3.3 Which Tools and Techniques are Currently Used? Company Procedures: Respondents were asked "Does your company have any formal operating procedures for your design projects or design guidelines which explicitly include risk or reliability assessments for the product/process?" and were asked to tick all applicable boxes. Of those that replied, 80% stated that design analysis procedures were specified, 46% stated that product/process reliability test procedures were specified and 54% stated that Factors of Safety were specified. For 39% of respondents formal risk/reliability assessment was mandatory because of legal requirements, and for 52% it was demanded by their clients. Identification of Technical Risks Respondents were asked to specify which techniques, in addition to those used for project risk identification, were used to identify risks that may affect technical risk factors. Brainstorming (79% of respondents), checklists (72%) and interviews (46%) were the most widely used techniques for identifying technical risks (along with personal experience (91%) and common sense (86%)). Risk response analysis (where the secondary risks which may arise from the planned or anticipated responses to those originally identified are analysed) was used by 25% of respondents and questionnaires were used by 23%. Of those who used checklists, 78% used lists developed within the company, 44% used lists developed personally and 15% used those developed within the industry. The most widely used tools to support these identification techniques were computer-based checklists (used by 44% of respondents). Fourteen percent of respondents stated that they used published material - examples given by respondents included Ministry of Defence material, the PRINCE checklist [12], case histories, technical journals, guides, manuals and research papers. Nine percent stated that they used a knowledge-based system to support risk identification. Other tools named by respondents included Failure Mode and Effect Analysis, Hazard and Operability studies, trained facilitators, spreadsheets and paper-based methods. Risk Impact and Probability Evaluation The most widely used models for the modelling of uncertainty when estimating the values of technical risk factors were qualitative representations (e.g. "major'V'minor"), which were used by 70% of respondents. This was followed by safety factors (54%), Failure Mode and Effect Analysis (48%), interval representations (38%) and then probability distributions (34%). Event trees were used by 14% of respondents, as were fault trees. Level 1, 2 or 3

ICED 01 -C586/435

589

reliability techniques were only used by 11% of respondents, and only nine percent of respondents used decision trees. Respondents were asked to specify which software tools they used to model uncertainty in technical risk factors and whether the tools were commercially available or were developed in-house. The most widely used tool was Monte Carlo simulation software, which was used by 37% of respondents, followed by reliability software (23%) and more specific simulation software (5%). Other software tools named by respondents included spreadsheets, HAZOP software, virtual reality software and dynamic models. Fifty one percent of respondents ticked "None", indicating that they did not use software tools at all in this context. Sixty nine percent of the reliability software in use had been developed in-house, as had 38% of the Monte Carlo software. When asked "How often do you use the following methods to obtain data on technical risk factors?" the respondents gave the results are shown in Table 4 below. The greyed areas of the table indicate the most popular techniques. Table 4.

Percentage of respondents using specified method to obtain data on technical risk factors

Experiment Service feedback Third-party documentation Design analysis Simulation Probabilistic models Fuzzy models Specialist reports

Always 6% 11% 4% 30% 9% 6% 0% 2%

Often

40%

42% 47%

45% 33% 12% 0% 42%

Occasionally 30% 42%

47%

17%

37% 41% 4%

Never 25% 6% 2% 8% 20%

41% 96%

46%

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 into the project risk identification process, 48% percent of respondents stated that the project risk identification process "very much" included identification of risks which affect the technical risk factors, 41% said that it did so only "to a limited extent" and 11% said that project time and cost considerations were separated from technical risks. Respondents were asked "During the design project, if it transpires that a technical risk factor may have an impact on project time-scales or costs, how is this information communicated to the project manager?" and were asked to tick all mechanisms which applied and to specify any other mechanisms used. Respondents overwhelmingly (98%) used verbal communication in project meetings, but formal paper-based procedures were also popular (46%), with software and other mechanisms being infrequently used.

3.4 Barriers to Effective Risk Management The perceived effectiveness of current technical risk management practice was explored by asking "When faced with technical design decisions under uncertainty do you feel that you have sufficient information available to you to make a rational decision?". In response to this question only 7% were able to answer "Always". Fifty five percent indicated that they often have the appropriate data, but 36% indicated that they only occasionally and 2% never have

590

ICED01-C586/435

the required data. Respondents were asked to expand on the reasons for difficulty in dealing with risk by indicating the main reason for difficulty. The options offered and results obtained are given in Table 5 below. Table 5. Main reason for difficulty in dealing with risk

Materials Manufacturing Processes Usage Bought-In Sub Systems Sub-System Interactions Design Error in Sub-System Aggregate Budget Overuns

Collecting data... In principle In practice 9% 54%

6% 15% 10% 14% 10% 7%

49% 49%

65% 44% 58%

50%

Modelling im pact of data. . . In principle In practice

13% 16% 11% 17% 26% 16% 13%

25% 28% 26% 9% 16% 16% 30%

4 Conclusions The results obtained concerned a wide spectrum of type and size of engineering design project, and can be considered representative of practice in "risk-aware" engineering design companies, though they do not provide a statistically unbiased sample. The survey suggests that technical risk management is not well integrated with design and project management processes. For nearly half the respondents, consideration of technical risk was not well incorporated into the project risk identification process - i.e. the process of identifying cost and timescale risks. Also, nearly half the respondents had no formal paperbased or software mechanism to communicate the impact of technical risks on project timescales and costs. The use of probabilistic modelling techniques was not found to be widespread, with qualitative techniques being more widely used. Software tools, when used, are often developed in-house or, if commercial, are low-level modelling tools (e.g. Monte Carlo add-ins for spreadsheets) rather than risk management packages. Over half the respondents did not use any software tools at all to model uncertainty in technical risk factors. Sixty nine percent of the reliability software in use had been developed in-house, as had 38% of the Monte Carlo software. This last figure is particularly surprising considering the relative complexity of such software, when compared for example with development of a simple custom database application. In contrast, only 18% of the Monte Carlo software used to model project risk was developed in-house; maybe reflecting the more domain-specific, or even problem-specific, nature of technical risk models compared with cost-risk and time-risk models. The areas where technical risk most often arose were usage (64% stated it "almost always" or "often" arose here), followed by sub-system interactions (58%), followed by aggregate budget overruns (54%). The areas where it was seen as most difficult to deal with were aggregate budget overruns (55% stated this was "extremely difficult" or "difficult"), followed by subsystem interactions (53%), followed by design errors in sub-systems (47%). Hence the two most problematic areas are aggregate budget overruns and sub-system interactions, which are both clearly related to product complexity. In every single area, the main reason given for difficulty in dealing with risk was difficulty in collecting data in practice.

ICED 01 -C586/435

591

Improvements in risk management practice are needed: 38% of respondents said they "occasionally" or "never" have sufficient information available to make rational technical design decisions. The findings of this survey suggest that efforts should be concentrated on developing systems to help manage complex risk data - for example computer systems to help collect the data needed to model aggregate budgets and sub-system interactions. Research is needed into methods which can be incorporated into such systems, to facilitate rapid development of complex risk models during design. References [I]

Cooper. D. F. and Chapman. C. B.. "Risk Analysis for Large Projects: Models. Methods and Cases". Chichester: John Wiley and Sons, 1987.

[2]

Chapman, C. B. and Ward S., "Project Risk Management: Processes. Techniques and Insights". Chichester: John Wiley & Sons Ltd., 1997.

[3]

Williams, T., "A Classified Bibliography of Recent Research Relating to Project Risk Management", European Journal of Operational Research, vol. 85, pp. 18-38, 1995.

[4]

MoD(PE)-DPP(PM) "Risk Management in Defence Procurement", reference D 1 DPP(PM) /2/1/12, available from Ministry of Defence Executive, Directorate of Policy (Project Management), Room 6302, Main Building, Whitehall, London., 1991.

[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 Risk Management Specific Interest Group, 2000

[7]

Baker, S., Ponniah, D., and Smith, S., "Survey of Risk Management in Major UK Companies", Journal of Professional Issues in Engineering Education and Practice, vol. 125, no. 3, pp. 94-102, July. 1999.

[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 Practice in 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 and Storage Amongst Engineering Designers". Bath: The University of Bath, ISBN 1 85790 004 9, 1993. [II] Pahl, G. and Beitz, W., "Engineering Design: A Systematic Approach". Second Edition. Berlin and Heidelberg: Springer-Verlag, 1996. [12] PRINCE is a project management method developed for IT projects, by the Central Computer and Telecommunications Agency, a UK government procurement agency. For further information contact the CCTA at Rosebery Court, St. Andrews Business Park, Norwich, NR7 OHS Chris McMahon University of Bristol, Department of Mechanical Engineering, University of Bristol, Queens' Building, University Walk, Bristol BS8 1TR, UK, Tel: +44 (0)117 9288100, Fax: 444 (0)117 9294423, E-mail: [email protected], http://www.dig.bris.ac.uk/staff/chris/chrisnew.html ©IMechE2001

592

ICED01-C586/435

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

DEVELOPMENT OF AN 'IDEA' FOR SAFETY D Vassalos, I Oestvik, and D Konovessis Keywords: Safety, competitiveness, product-life-cycles, risk analysis and management, probabilistic design.

1

Introduction

By all accounts, ship safety is in a transitional state reflecting the shift from design periphery to a core design factor and from a post-design consideration to a through-life design imperative. Conventional approaches are under scrutiny and potential new approaches come under the microscope as the shipping industry is forced into responding positively. The traditional inertia has been overcome by a new stronger resurgence of safety as a key issue that cannot be considered in isolation any longer nor fixed by add-ons, bringing home the long overdue realisation that lack of safety or ineffective approaches to safety can drive shippers out of business. On the other hand, current ship design practice is not an efficient process, mainly due to lacking of a framework capable of accommodating scientific advances and emerging computer technologies, and the consequent benefits derived therefrom. Attempts to improve the situation in the past were mainly related to enhanced versions of the ship design spiral, which was introduced prior to the computer age. In this respect, computers have done nothing more than increasing the speed of the design process and, in some cases, improving the quality of separate design tasks. Deriving from this, there is clear need for a formalised ship design framework that accommodates and provides for ship design tasks in a way that allows for interaction and iteration in an integrated design environment. To this end, the paper describes the development of an Integrated Design Environment Architecture ("IDEA") for Safety. Following the identification of requirements for the development, the specific elements of the integrated design environment are detailed, with particular emphasis given to the suitability of Blackboard Systems (BBS), the core of the development, to ship design.

2

Background

2.1 The ship design process Ship design is uniquely characterised by the fact that some of the most important decisions regarding the vessel are taken at the early stages of the process, allowing all later design actions, which are inevitably bound within the set frame prescribed by the early decisions, little possibility to positively affect cost and performance. Figure 1 illustrates this situation. As the design process proceeds, the knowledge about the design increases, while at the same time the freedom to make changes decreases due to the large costs associated with these

ICED 01 -C586/639

593

changes. There is evidently a need for knowledge feedback at the early stages of the design process where the assigned costs are lower and the freedom to make changes are greater.

Figure 1: Elements of the Design Process

Ship design is a complex engineering decision-making process involving the integration of many subsystems into a final solution. There are many ship design methods in existence, reflecting the ingenuity and experience of designers around the world. The basic constituent, which is of central importance to all methods, is the ship design spiral. This was introduced decades ago by Evans [1], with attempts in recent years focused on enhancements through the introduction of computer technology and modelling techniques [2, 3, 4, 5]. The ship design spiral advocates an iterative, step-wise solution procedure that is time-consuming and produces results, which may be acceptable but not necessarily optimal. It certainly does not take into account whole life cycle issues and is not capable of accommodating effectively and efficiently contemporary and future ship design tools and concepts. There are two major trends evident in ship design research and development today: •

the pursuit of a definite theory of ship design;

•

the development and application of computer-based tools in design.

Regarding the latter, a great deal of work has been undertaken by industry and academia world-wide resulting in quality software packages, advances in technology and scientific understanding, which combined have shortened considerably the time required during the ship design process. Regarding the former, ship design is still in need of a formalised framework to control and manage the design process in an efficient way with the potential to take advantage of new emerging computer technologies.

2.2 Design for safety Design for Safety constitutes an integrated approach that links safety performance prediction, risk assessment and design in a way that allows for interface, interaction and iteration. In this process, safety assessment is the "back-bone" that provides a two-way dynamic link between technological developments and design. On the one hand, it gathers and assimilates technical information, prioritises safety issues, identifies practical and cost-effective safety-enhancing solutions and sets the requirements and constraints for the design process. On the other hand, it provides feedback from the design process to the technologists to stimulate refinement and re-appraisal of the "tools", in the light of the experience gained from implementation and

594

ICED01-C586/639

practical applications. This dynamic interplay is demonstrated in Figure 2. This way, it would facilitate implementation of technological innovation and hence development of safe innovative designs to meet the demands of current and emerging markets. A thorough review of the Design for Safety philosophy is given in [6].

Figure 2: Safe Ship Design Iterative Process

A chief concern in integrating safety in the design process, particularly when claiming that this must be done in a way that safety "drives" design relates to the presumption that any investment on safety does not compromise returns. This concept is ill-based. Figure 3 illustrates the relationship between economic and technical issues in a safe ship design process. The outer boundary corresponds to a design solution that achieves a perfect balance among all safety and cost criteria and constraints, which is presently unattainable. Today's practice is represented by the inner boundary, whilst it is argued that a safety-effective and cost-effective solution could be achieved by adopting first-principles-based design. The enhanced awareness on safety-related issues and the improved appreciation of how safety and cost interrelate and interact is slowly beginning to drive home the simple fact that scientific approaches to dealing with safety are the key to increasing competitiveness.

Figure 3: Relationship between Safety, Costs, and Design Constraints

ICED 01 -C586/639

595

3

An "IDEA" for safety

An Integrated Design Environment Architecture ("IDEA") provides the designer with a means to assess the technical and analytical characteristics of the design using relevant tools. The "IDEA" must be formalised indicating that entities, attributes and relationships for the relevant issues are generic. This allows information to dynamically change, for altering design input and innovations can be readily implemented. The design information is stored in object-oriented knowledge bases, which are updated independently as required. A control and management function is needed to accommodate these issues. Blackboard Systems (BBS) have been identified to have such a potential and are being utilised as the platform to overcome the stated deficiencies. The development of a formalised ship design framework, particularly one addressing "Design for Safety", must adopt an integrated approach, accommodated in a providing environment, which links the ship design tasks and allows for interaction and iteration between them. In this process, a blackboard system supports a dynamic interface between tools and methodologies applied to the various design tasks and it stores/retrieves, as necessary, information about ship design in a knowledge base. An "IDEA" for Safety is illustrated in Figure 4, having a central blackboard to control and manage the overall ship design process applying the appropriate knowledge bases, tools and methodologies.

Figure 4: An "IDEA" for Safety

The integrated Design for Safety environment, illustrated in Figure 5, accommodates a methodological assessment of relationships between safety, cost, and design features adopting a top-down approach by assessing hazards and risks at the event level, e.g. for collision, grounding, impact, flooding, and fire/explosion. Furthermore, the IDEA for Safety accommodates the identification of risk prevention and mitigation measures, cost-benefit quantification of design features/safeguards, assessment of ship performance effects and provides decision support in order to design safe, cost-efficient ships fulfilling the operational themes in an iterative procedure. A holistic description of the various elements of the integrated environment has been reported in [7].

4

Blackboard systems

Blackboard systems (BBS) are regarded as a part of the Artificial Intelligence family and originated with the Hearsay project in the USA twenty years ago [8, 9]. BBS constitute a realisation of the fundamental philosophy of design co-ordination, a formalisation within

596

ICED01-C586/639

concurrent engineering. Design co-ordination advocates that tasks must not necessarily be carried out concurrently, but rather in such fashion as to achieve optimum performance. Design co-ordination is defined as a high level concept of the planning, scheduling, representation, decision-making and control of product development with respect to time, tasks, resource utilisation and design aspects [10].

Figure 5: An Integrated Design for Safety Environment

The philosophy of blackboard systems is to opportunistically piece together a solution on the blackboard by using external knowledge sources, which are working co-operatively and are activated by a control mechanism, be it human or software programs, applying the right knowledge at the right time [11]. In this respect, various sources of knowledge participate in forming and modifying the emerging solution by knowledge sources contributing opportunistically when called upon. Furthermore, as steps are taken toward the solution, the processing commitments are minimised since the solution is built incrementally and steps of forward chaining can be arbitrarily interleaved with steps of backward chaining. Blackboard systems are particularly effective for incremental solution generation, which is typical for the ship design process, where the knowledge sources contribute to the solution as appropriate outperforming a problem solver that uses the traditional ship design approach to generate a solution.

4.1 Blackboard system components A blackboard system consists of three components as illustrated in Figure 6 [11]: Knowledge sources: Independent modules that contain the knowledge needed to solve the problem and they have a formal structure to receive and send information in order to communicate with the blackboard. Knowledge sources are static repositories of knowledge, which are activated in a predetermined way by trigger functions, or instances, which are the active functions looking for a triggering command, or condition, on the blackboard. Knowledge sources can be referred to as agents in engineering applications where the technology supports the integration of fully autonomous software and human expertise. Knowledge sources can be added or deleted from the blackboard system as required without influencing the overall performance of the blackboard, they can have a wide diversity in ways

ICED01-C586/639

597

of representing information and problem solving techniques, but must operate based upon a common interaction language. With regard to ship design, lines development could be such a knowledge source, engine selection another, both performed in the ship design process based upon separate methods, tools, and information. The blackboard: A global structure that is available to all knowledge sources and serves as a storage medium of raw input data, partial and final solutions, and control information, as a communication medium and buffer, and as a knowledge source trigger mechanism. A control component: It directs the problem-solving process by allowing knowledge sources to respond opportunistically to changes on the blackboard database. The control triggers any knowledge source based upon a defined ranking, and it can change the focus of attention based on the state of the solution. Knowledge Sources Software specialists each providing expertise needed by the application. The Blackboard Shared repository of problems, partial solutions, suggestions, recommendations, and contributed information. Control Shell Controls the flow of problemsolving activity in the application.

Figure 6: Blackboard Systems Components

4.2 Application of BBS to ship design Blackboard systems offer a powerful problem-solving framework when satisfying the five arguments on the left side of Table 1 and their application to ship design is justified on the right hand side of the same table. Blackboard applications are not widely used despite their long history and documented advantages. The reason for this is "that blackboards are only worth pursuing for complex applications" and "while useful for prototyping an application, once developed and understood, the application can be re-implemented without the blackboard structure" [12]. The former statement indicates that for a ship designer a blackboard tool would be invaluable. The latter statement is valid for any type of developments since human experience is hard to beat in any case. The best example on this is ship designers who produce ship designs based on feeling and experience. Three situations are given in Table 2 when a blackboard system is not directly applicable to ship design. These arguments highlight research and development required for the introduction of blackboard systems in the ship design process.

598

ICED01-C586/639

Table 1 : Applicability of Blackboard Systems to Ship Design

Ship Design Blackboard Systems Many diverse, specialised knowledge There are few engineering activities that are representations are needed. more diversified and specialised than ship design. An integration framework is needed that A ship design evolves today by performing allows for heterogeneous problem-solving heterogeneous tasks in a sequential order. representation and expertise. A framework for control and management is needed. The development of an application involves Ship design activities involve numerous organisations, suppliers, consultants, etc. numerous developers. Uncertain knowledge or limited data inhibits Alternative solutions can be designed with little extra effort absorbing uncertainties. absolute determination of a solution. Multilevel reasoning or flexible, dynamic Ship design will profit immensely by control of problem-solving activities is enabling dynamic control between two or more applications such as stability and required in an application. resistance. Table 2: Inapplicability of Blackboard Systems to Ship Design

Blackboard Systems All knowledge could be easily represented in a framework with which a user is already familiar. The application does not need to make dynamic control decisions.

Ship Design This has yet to be achieved within ship design - the knowledge exists in various places and forms. When implemented this function leads to savings on time, effort, and fewer errors. Moreover, with the implementation of simulation in design this function is needed. The complete application will not be Ship design comprises numerous systems combined with other systems. a framework controlling and managing these systems is called for.

5

Conclusion

Ship design is in need of a formalised framework that allows for efficient interaction and integration among the ship design tasks and the adoption of an integrated approach accommodated in a providing environment. Blackboard systems have been utilised as the platform in such an environment, which provides a dynamic interface between the various design tools and methodologies. Experience so far suggests that blackboard systems provide the appropriate vehicle for accommodating the ship design process and new emerging computer technologies. It is expected that in the near future computer-based control and management tools, knowledge storage/retrieval, and visualisation tools will become fully integrated in the ship design process. Visualisation is a field that will make huge advances into ship design with the development of high performance PCs to model and simulate ship operations enabling large savings on ship model testing costs [13]. This will enable ship designers to test their designs

ICED01-C586/639

599

in the operating environment feeding valuable information back in the design process to produce better solutions through this dynamic interaction between operational and design phases. References [I]

Evans, J.H.: "Basic Design Concepts", Journal of the American Society of Naval Engineers (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 Naval Architects (RINA). Vol. 123, 1981, pp. 447-471.

[4]

Mistree, F., Smith, W.F., Bras, B.A., Allen, J.K., and Muster, D.: "Decision-Based Design: A Contemporary Paradigm Ship Design", Transactions of the Society of Naval Architects and Marine Engineers (SNAME). Vol. 98, 1990, pp. 565-597.

[5]

State of the Art Report on "Design Methods". The Sixth International Marine Design Conference (IMDC 97), Vol. 2: State of the Art Reports, 23-25 June 1997, University of Newcastle upon Tyne.

[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 and Application of a Formalised Methodology", Proceedings of the Seventh International Marine Design Conference (IMDC 2000X 21-24 May 2000, Kyongju, Korea, pp. 151165.

[8] Erman, L.D., Hayes-Roth, F., Lesser, V.R., and Reddy, D.R.: "The Hearsay II Speech Understanding System: Integrating Knowledge to Resolve Uncertainty", ACM Computing Surveys. Vol. 12, No. 2, 1980, pp. 213-253. [9]

Nii, H.P.: "Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures" (Part 1), "Blackboard Systems: Blackboard Application Systems, Blackboard Systems for a Knowledge Engineering Perspective" (Part 2), The AI Magazine, pp. 38-53 and 82-106, Summer 1986.

[10] Duffy, A.H.B., Duffy, S.M., Andreasen, M.M., and Rimmer, D.: "Team Engineering within the Context of Product Design Development", Strathclvde University CAD Centre Paper. CADC\P\95-13, 3 August 1995. [II] Corkill, D.D.: "Blackboard Systems", AI Expert. Vol. 6, No. 9, September 1991, pp. 4047. [12] Feigenbaum, E.A.: "Foreword to Blackboard Systems", edited by R. Engelmore and T. Morgan, Addison Wesley Publishing Company, 1988. [13] Polini, M.A., Wooley, D.J., Butler, J.D.: "Impact of Simulation Based Design on Today's Shipbuilding", Marine Technology. Vol. 34, No. 1, January 1997, pp. 1-9. Professor Dracos Vassalos Department of Ship and Marine Technology, University of Strathclyde, 100 Montrose Street, Glasgow G4 OLZ, United Kingdom, Tel.: +44 141 548 4092, Fax: +44 141 552 2879, E-mail: [email protected], URL: http://www.strath.ac.uk ©IMechE2001

600

ICED01-C586/639

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

HOW MUTUAL MISCONCEPTIONS BETWEEN DESIGNERS AND OPERATORS CAUSE ACCIDENTS IN HAZARDOUS INSTALLATIONS J S Busby, R E Hibberd, P W H Chung, B P Das, and E J Hughes

Keywords: Safety, human factors, risk analysis and management, man-machine interaction.

1 Introduction 1.1 Purpose Accidents in complex production systems have led in the past to disastrous losses in revenue and human life, and considerable damage to the natural environment. A central role is often played by the misconceptions that designers have about the intentions of operators or maintenance staff, and operators' misconceptions about the intentions of designers. The purpose of this study is to extract knowledge from investigative reports about how mutual misconceptions have occurred, and direct it at the primary decision making points in both the design and operating processes.

1.2 Background Various work in the recent past has prescribed specific processes or decision making methods to improve the attention paid to safety during design (for example Gauthier and Charron 1995; Stoop 1997). These methods help set limits on the designer's ability to make unsafe decisions, for example by requiring certain kinds of hazard analysis, and build into the design process the benefits of past experience. But any method that constrains the designer can also make the design process less responsive to the specific circumstances of particular cases, and reduce the extent to which the designer can imaginatively make designs inherently safe. A number of studies have instead concentrated on developing accident databases that provide designers with a resource rather than a constraint (for example Chung and Jefferson 1998, Bielecki et al 1995). However, these databases usually organise cases according to the design discipline and type of artefact involved, and often give the designer little insight into the systemic problems that in fact contributed to the accident. In particular, they often say little or nothing about the expectations that designers and users of the design, such as operators and maintenance staff, had about each other. Much is known about various parts of the problem: about the ways the design of an artefact influences error in its use (for example Norman 1992), about the characteristics that lead to omissions in maintenance tasks (Reason 1997), about the way that systems suffer from complex interactivity and tight coupling (Perrow 1984), and about the fallacy of the 'defencein-depth' design principle (Rasmussen 1990). Yet we still seem to know little about how

1CED01-C586/029

601

people who are remote from one another, like designer and operator, develop models of one another's intentions - and how these models can systematically be in error.

1.3 Context The study took place in the specific context of hazardous installations, and in particular both onshore and offshore process plant. Such plant presents a variety of hazards that could arise from designers and operators having a flawed understanding of each others' intentions - but their complexity, scale and high inventories of hydrocarbons present particular problems. This can make failure modes difficult to identify and forestall, it can make the transmission of a failure rapid and unpredictable, and it can pose considerable problems for the evacuation of staff and access by emergency services.

2 Method The basic research design involved four stages: the causal analysis of past accidents; the identification of causes which in some way involve designers' misconceptions about operators' intentions or operators' misconceptions about designers' intentions; the development of agenda-generating mechanisms that use the outcomes of the preceding stages in an attempt to influence key decision making points in the design process; the evaluation of these mechanisms. This paper reports on the results of the first two stages. The causal analysis involved representing accident investigators' reports as causal trees. This follows the procedure reported in an earlier study (Busby and Strutt 1999) and draws on the dataset used for that study (which concerned offshore installations), together with an additional dataset of accident reports in onshore installations. Fourteen of these were reported by Kletz (1998) - who is acting as consultant to this study - and six by Crowl and Louvar (1990). The technical failures implicated in these reports were wide ranging, and included brittle fracture, unexpected static electricity discharge, degraded hoses, ruptured pressure vessels and so on. All reports also cited human and organisational error and it is primarily these that there were the focus of attention in this study. It is important to point out, however, that in searching for mutual misconceptions between designers and operators we are looking for combined weaknesses in engineering knowledge and human psychology. The next step was to inspect all of the causal networks to look for sub-networks, within these causal analyses, that appeared to involve some kind of misconception between designer and operator. For each misconception a description was generated in the form of a short narrative, a summarising clause was developed, and the subject and object of the misconception were identified (that is, who did the misconceiving, and who the misconception concerned). There are several factors that complicated this analysis: The identification of subject and object is not always unambiguous. For example, if the designer had failed to anticipate that an operator would use a device in an unintended way, one could argue that the operator should have anticipated the designer's failure to

602

ICED 01 -C586/029

anticipate this. Product users, one could argue, should be used to product designs that do not meet their intentions. It is often unclear from the accident investigator's report what beliefs lay behind people's actions, and it is quite likely that an investigator would often not be able to determine these beliefs. In some cases, therefore, the analysis involved identifying possible, rather than certain, misconceptions. This does not, however, vitiate the purpose of the study since it is as important to draw designers attention to how things might have gone wrong as it is to draw their attention to how things did go wrong. An attempt has then been made to develop general models on the basis of these specific misconceptions. The purpose has been both to capture the nature of the misconceptions and to try to explain why they had not been undermined by experience. Organisational and individual experience among engineers, in principle, should weed out dangerous models. So where such dangerous models persist it is important to try to work out what is wrong with the way engineering organisations work, the way engineering knowledge accumulates, or the way individuals learn about the consequences of their work.

3 Results From the cases, about 120 distinct misconceptions have been identified. Rather than list all of them, we have described below some of the generalised modes of misconception together with some of the cases in which they arose. We have concentrated on the misconceptions which designers appear to hold about operators.

3.1 Holding mechanistic stereotypes of operators Several of the misconceptions involved designers making design decisions as though the human operators lacked exactly those characteristics that made them human. For example, operators would be required to sustain attention in a warm, comfortable environment for long periods, scanning for unusual conditions which occurred only rarely. These are typically conditions that are incompatible with attention and arousal (Warm 1984). Similarly, the failure of operators to follow written instructions in operation and maintenance was implicated: in eleven of the onshore accidents injury or death resulted following the neglect of instructions. Yet it is part of designers' folklore that users of artefact neglect instructions, and most models of people learning how to use objects emphasise the role of trial and error, physical interaction and sometimes social observation - not following instructions. If designers can predict that instructions will not be followed there is an argument they should not rely on instruction following for safe operation. If the objective of engineering is to serve human society, it seems unreasonable that engineers should not acknowledge human characteristics.

One explanation of why designers sometimes fail to acknowledge the limits of human attention is that the operator simply does not enter the designer's model of the system. But this cannot be true if the designer provides a device that requires human intervention. It must be the case that the designer's model of the human operator is based on a stereotype that lacks human characteristics. It seems absurd that designers could really use models of operators that lack what they know to characterise a human being, but it may be self-serving to do so if the expectation is that more realistic models will require more design effort. It is

1CED01-C586/029

603

also possible that the problem is an 'attribution' one - to do with a bias in the way people attribute characteristics to other people, which has been a strong theme in social psychology (Fiske and Taylor 1991).

3.2 Neglecting operators' willingness to gamble There were cases where operators seemed to gamble and lose. For example, a master of a vessel knowingly sailed into a storm even after sustaining early, minor damage. He was under time pressure, and apparently made a decision based on his assessment of probabilities and outcomes. But it is unlikely that his probability estimations were good ones. There is an argument that if designers predicted that operators would gamble with using equipment knowingly in hazardous modes then they could provide information to support them. It is not enough as a designer to say that product X is unlikely to function in condition Y: it is important to say that product X in condition Y has a probability p of failing. Again it is possible to speculate on why designers' models of operators do not seem to acknowledge that operators will gamble (and should either be helped to gamble informatively or possibly impeded to gamble entirely). It is plausible, for instance, that designers did not predict that operators would be under production pressure. Then there would be no reason to gamble since there would be nothing to gain from it - although, conceivably, operators might gamble if they were bored and expected excitement as a possible payoff. So, rather than designers' models of operators being poor reflections of the operators they might be poor reflections of circumstances that operators work in. The failure to predict gambling behaviour would then be a symptom of the failure to understand an environment.

3.3 Misconceiving operators' beliefs about boundary conditions Designers appear to be weak at inspecting boundary conditions and operators appear to acquire little experience in testing boundaries - so boundary infringement is a prime cause of accidents. For example, in one case operators had adopted a ballasting practice on a semisubmersible structure that made the structure vulnerable in severe weather. In another case, operators of a small craft kept an autopilot engaged while manoeuvring close to an installation. In such cases the operators did not acknowledge safe limits to operation of a particular device, and the designers had provided a system which allowed or encouraged the operators to exceed these safe limits. If designers better understood the conditions which lead operators to exceed limits, and if operators better understood the inherent limitations in a particular design, this kind of accident becomes less likely. The accident investigations, unsurprisingly, say nothing about the origins of these causes. But it seems likely that designers' weakness at inspecting boundary conditions arises from: analytical difficulty (it can be difficult to identify comprehensively what kind of operation in what kind of environment will compromise the design, and it takes effort to do so); the nature of experience (accidents are uncommon, and failure often does not lead to an accident, so designers may have little empirical knowledge about a design's operating boundaries); motivational considerations (designers probably are reluctant to defeat their creations so may find it hard to think systematically about their failure). It also seems likely that operators' inability to acquire experience in testing boundaries arises from: the nature of the task (it is usually unsafe to explore boundaries in the production system);

604

ICED 01 -C586/029

the effort involved (production pressures typically mean there is too little time to explore boundaries); system complexity (it may be infeasible to develop sufficiently realistic simulations). Since the boundaries of safe operation vary according to environmental conditions in combination with operator actions these difficulties are all amplified. Operators wanting to know what happens if they adopt a particular ballasting practice, for instance, would need to do so in a variety of weather conditions.

3.4 Assuming that operators' know when to replace degraded artefacts This is similar to the problem described in the previous sub-section in that a boundary is exceeded, but we have described it separately because the boundary is a temporal one and the process of reaching the boundary (time elapsing) is not one that operators control. A simple example of this was a case where a set of hoses that failed, partly because they had been used for too long. But their service life had not been specified by the designers so there was apparently no clear criterion for replacement for the maintenance and operating staff. Possibly the designers assumed a level of preventive maintenance that was unrealistic for the environment, and possibly they had assumed that degradation would be visually obvious. Presumably the culture of a particular industry will guide a designer as to what he or she can expect an operator to be capable of. This will include expectations about whether maintenance is preventive and whether there is enough knowledge to know when an artefact has become hazardous. When designers can reasonably expect operators to make highly competent decisions about when to replace degraded artefacts it may be the case that the operators will be in a better position to say when something should be replaced than a designer. Even then, however, it seems sensible that designers should provide guidance that can be used if competence turns out to fall short. This, in most cases, would include service life ratings.

3.5 Failing to anticipate operators' non-routine goals In certain cases the design of a piece of equipment confounded operators' intentions when they were trying to do something outside a routine or planned process. Tragically this included operators evacuating an offshore installation in unpredicted circumstances. The installation was a semi-submersible platform which had partially capsized. When operators tried to evacuate they found that the design of the lifeboat davits precluding launching in a partial capsize, and only allowed launching in a full capsize. Designers appear to identify a process which the design has to support, in this case evacuation following a capsize, but apparently sometimes do not reason about how the design can confound operators when there are differences to this process, in this case a capsize which does not fully develop (at least initially). What is required in cases like this is a systematic way of perturbing the conditions assumed by the designer, and testing whether the design is still satisfactory in the perturbed conditions. Routines like HAZOP do support this kind of reasoning. But its success depends on the designers' ability to identify all feasible perturbations, and then to identify all the consequences, and it is hard to see how to assure this.

ICED01-C586/029

605

3.6 Neglecting the possibility of operator lapses Several accidents arose when the operator experienced a lapse and left some equipment in a potentially hazardous state. For example, maintenance staff left open a hatch that should have been closed to prevent water ingress; an operator of a vessel left an autopilot engaged during close manoeuvring; a cleaner left an oven on after cleaning. In such cases, the operator had probably planned to change the state of the equipment but had failed to execute the plan after his or her attention had switched - perhaps following an interruption. Such lapses are predictable. Putting the equipment into the state that later became hazardous was something the operator had to do to accomplish an immediate goal, while changing the state into a benign condition was not necessary to accomplishing such a goal. It is obviously not feasible in all cases for the designer to do anything about possible lapses, but it probably is feasible for the designer to identify hazardous states and ask whether they could be reached by a lapse on the part of the operator. Sometimes it might be sufficient to improve the cues provided by the artefact: some artefacts naturally signal their current state to a user but others do not (Norman 1992).

4 Conclusion The mutual misconceptions that designers and operators of complex systems have about each other's intentions appear to be fundamental causes of breakdowns, and sometimes accidents, in these systems. On the basis of early results, these misconceptions seem to be generated by inappropriate belief systems - such as the expectation among designers that operators will seek differentiating information when in reality they seek resemblances. The promise is that, once designers develop an awareness of how these belief systems can be wrong, they will be able to avoid the hazardous situations that arise from misconceptions. And, because the belief systems are so general, they should be able to avoid specific hazards that (through chance) they have not had any experience or knowledge of at a concrete level. Probably most of the misconceptions described in the last section are better described as 'missing conceptions'. It seems likely that the problem arose because, for instance, a designer had not considered the possibility of an event - not that he or she held a wrong belief about that event. This in turn suggests that the designer's model of the design being operated was incomplete in such cases. In some respects, missing conceptions are worse than misconceptions: one is probably more likely to notice a wrong belief than a missing belief. But in other respects they are better: misconceptions have to be positively undermined, whereas a missing conception suggests an open mind. The distinction could be an important one when thinking about how to remedy problems of this kind. It is important, however, to acknowledge the limitations of this study - which are both contextual and methodological. The contextual limitation is that the domain that was studied is quite specialised, and involves the design of highly complex systems which are used by professional operators. Misconceptions between designers and users of, say, consumer products might be quite different. The main methodological limitation in this study has to do with the dependence on accidents and accidents investigations in particular to reveal mutual misconceptions. This means that:

606

ICED01-C586/029

1. Misconceptions that happened not to lead to accidents, but near misses for instance, were not considered. 2. Much of the causation involved in the accident would not be known to the investigator, especially the state of mind of the designer who might have designed any equipment that was implicated in the accident. 3. We know very little if anything of the designer's circumstances - whether he or she was experienced, for example. The upshot is that we can draw plausible conclusions about the misconceptions that can develop between designers and operators, and suggest what kind of misconception to avoid in the future, but cannot be sure about the diagnosis of specific cases. References Bielecki Z, Osinski Z and Wrobel J (1995). Databases for design for safety of all-terrain cranes. Proceedings International Conference on Engineering Design ICED95, Prague, August 22-24, pp 1108-1109. Busby JS and Strutt JE (1999). Design antecedents of accidents and the implications for design for safety. Proceedings of the International Conference on Engineering Design ICED99, Munich, 24-26 August, 1489-1494. Chung PW and Jefferson M (1998). The integration of accident databases with computer tools in the chemical industry. Computers and Chemical Engineering, 22, S729-S732. Crowl DA and Louvar JF (1990). Chemical Process Safety Fundamentals with Applications. Prentice Hall (Englewood Cliffs NJ). Fiske ST and Taylor SE (1991) Social Cognition (2nd Ed.), Mc-Graw-Hill (New York). Gauthier F and Charron F (1995). Design for health and safety: a simultaneous engineering approach. Proceedings International Conference on Engineering Design ICED95, Prague, August 22-24, pp 891-896. Kletz T (1998). What Went Wrong? Case Histories of Process Plant Disasters. 4th Ed. Gulf Publishing (Houston). Norman DA (1992). Design principles for cognitive artifacts. Research in Engineering Design, 4, 43-50. Perrow C (1984). Normal Accidents, Basic Books (New York). Rasmussen J (1990). The role of error in organizing behaviour. Ergonomics, 33, 1185-1200. Reason J (1997). Managing the Risks of Organizational Accidents. Ashgate (Aldershot), p. 97. Stoop JA (1997). Design for safety, a new trend? Proceedings International Conference on Engineering Design ICED97, Tampere, August 19-21, pp 609-614. Warm JS (ed.), Sustained Attention in Human Performance, John Wiley (New York). Corresponding author J S Busby Dept. of Mechanical Eng. University of Bath Bath BA2 7AY UK Tel. +44 1225-826588 Fax. +44 1225-826928 Email [email protected] ©IMechE2001

1CED01-C586/029

607

This page intentionally left blank

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

A PROJECT VIEW OF THE HANDLING OF UNCERTAINTIES IN COMPLEX PRODUCT DEVELOPMENT ORGANIZATIONS R Olsson

Keywords: Risk and opportunity management, uncertainty management, integrated product development.

1

Introduction

The situation in today's complex product development project is growing more and more towards a total involvement of most functions within the organization. The case of a group of few and, within their own area, highly competent engineers performing most of the tasks in fulfilling an idea to a produced product is obsolete. Instead, an interaction across functional departments and within functions is required for a cost-effective success of the outcome of the project. As product development schedules shrink, it becomes more and more crucial that cooperation, communication and management of product development, function in a shorter span of time [1]. Though refinements have been and are made for processes, tools and methods, still the problems lie at the more mental state of mind within a product development organization. Combining technology and organization and transforming it into a symbiotic relation is a difficult task to manage [2]. New, unproved technologies are inherently risky in the early stages of product development. The risks usually include a combination of technological, manufacturing, financial and business factors [3]. Whilst not fully being able to integrate all aspects of product development, uncertainties arise within the product development project and the organization. Uncertainties that will influence the outcome of project time and cost issues, organizational revenues and the customer's view of inadequacy of the organization. To be able to function better both within a product development project and in the assisting and interactive functions within the organization one must be able to handle such uncertainties.

1.1 Objectives This paper will focus on factors that illustrate the need for and a possible, but yet pragmatic, approach to a better handling of risks and opportunities within large complex product development organizations. Techniques of identifying and analyzing uncertainties along with the action planning are quite well known and will not be discussed and therefore not included in the objectives. Instead the organizational and managerial aspects are of interest and therefore form the basis for this paper.

1CED01-C586/141

609

The following objectives will be covered: To suggest theoretical bases for handling of uncertainties within complex product development organizations. To study the case of handling uncertainties within an organization, to study factors for success, needs and concerns within such an organization. To propose suggestions for future research directions that will contribute in the area of Uncertainty Management. The paper is based on findings from a case study conducted within Adtranz, a global provider of railway services, rolling stock and systems. Also empirical findings from previous corporate initiatives and action research findings from a pilot project form the base for this paper. It is outlined according to the three objectives mentioned above. The first section describes a base for theoretical references suggested for an adequate handling of uncertainties, the second section describes the case of handling uncertainties within Adtranz, and the third section proposes the direction for future research. The first two sections are described in more detail in the following chapters, whereas the third section is included in the conclusions.

1.2 Research methods Structured interviews in combination with open-ended questions have been conducted with 25 persons within Adtranz. Managers, engineers and other functions within the project or line organization were interviewed. An interview guide/combined survey has been prepared by the researcher and used during the interviews. The guide was sent to all interviewees in advance. In most cases the interviews took place over the phone. The guide was sent to 38 persons within Adtranz. The rate of response was 66%. Due to time constraints all interviewees could not be included. The survey consists of 35 questions where 15 of them were open (that is, no answering alternatives were given).

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 focuses on the planned change of human systems and contributes to organization science through the knowledge gained from its study of complex change dynamics. When describing organizational settings and relations, a separation between the organization's internal and the organization's external settings and relations is made to view distinctive prerequisites. Internal relations and settings could be described in factors constituting the organizational work setting [2]. The factors are divided into four basic categories, organizing arrangements, social factors, physical settings and technology. Although they have been dealt with separately, these categories are inevitably interconnected. Transorganizational systems are comprised of organizations that have joined together for a common purpose [4]. A common purpose of co-operating internationally within the organization, in consortia's, with subsidiaries and with subcontractors delivering solutions to the concept. For an organization, it is crucial to understand not only the organizational settings but also interrelation settings within this common purpose.

610

ICED01-C586/141

Risk is a characteristic of decisions that is defined as the extent to which there is uncertainty about whether potentially significant and/or disappointing outcomes of decisions will be realized [5], This definition of risk consists of three dimensions, Outcome uncertainty, Outcome expectations and Outcome potential. Uncertainty is described as an outcome, which could result in a positive or negative impact. Uncertainty could either be an opportunity or a risk. The perception of uncertainty often leads to the, quite common but narrow, interpretation of being risks. Though it is much easier to identify negative outcomes from uncertainties, it is of great benefit also to identify potential outcomes as opportunities. The product development process can be seen as the process from the creation of a wide set of alternative concepts, the consequent narrowing of alternatives to a reliable and repeatable product produced in production [6]. The development of new products is a classic example of the use of project management. From a risk management perspective however, this type of project is unique: the risks are high due to the uncertainty as a prerequisite for any product development project launch, the very nature of the project therefore is to reduce risk. The discipline of project risk management has developed over the past few decades as an important part of project management. Risk Management usually consists of four basic steps: Identification, assessment, response planning/action and monitoring and control but sometimes also the preceding step of risk management planning [7]. However, methods of managing risks are of great importance, the focus being on the execution of a series of actions in order to achieve a stable and well-known risk list with plans for mitigation and monitoring. Various techniques for addressing and performing the above four steps in risk management are frequently presented in previous research [e.g. 1, 8]. However, research focusing on the interaction between project- and functional organization and corporate management seems to be rare. Furthermore, the focus has been on a single project basis and mostly on the execution phases of a project. As risks arise within product development projects, not all of them can be managed within the project boundaries. Instead the responsibility for the management of risks organizationally lies either in another functional department, at sub-suppliers, at the customers or within the management of the organization. Research of today seems not to focus on the positive side of uncertainties as much as the negative. As long as an uncertain issue is not assessed to whether it is considered a risk or an opportunity, uncertainties cannot be properly handled neither within the project nor within the organization. Traditional project risk management can portray negative aspects deriving from uncertainties, omitting large positive outcomes i.e. opportunities [9]. Kahkonen therefore emphasizes project risk and opportunity management, as a means to vindicate a focus on opportunities as well as risks.

3

The industrial situation - Adtranz

Adtranz is a global provider of railway services, rolling stock and systems. They supply mass transit and main line vehicles, plus the related components, train control and communication systems. Adtranz has 22,000 employees in 40 countries, mainly in Western Europe, but also in India, the USA and Australia. The development of products is built on a global transfer of know-how organized centrally per product type and according to the modular concept.

ICED01-C586/141

611

The following prerequisites describe the situation within Adtranz. Prerequisites that are obstructing the organization to take use of existing techniques and methods within the area of Risk Management to the fullest extent: Highly complex product Low series development The uniqueness of every customer delivery order High cost of product Multinational product development teams The situation differs from that of most other industries and the consequence of above prerequisites has lead to actions towards a more effective handling of uncertainties. Williams [10] concludes that in general, beyond a certain size, the risks of projects increase exponentially and this can either be appreciated at the beginning or discovered at the end. Furthermore, as the need for risk management has been widely recognized, this is particularly so in the case of major projects.

3.1 Adtranz Business Process Within the Adtranz group, a common process model called Business Process (BP) is applied in all product units as the basis for deployment, further development and application of processes and procedures. Also a methodology called Quality Gates (QG) is applied for monitoring of progress at different pre-determined gates. As the BP and QG methodology itself is a process model developed for the enhancement of a globally structured process, it still handles uncertainties and is therefore considered as an approach for an overall handling of uncertainties.

Figure 1. The figure shows the top level Adtranz Business Process Model and Quality Gate methodology [11].

The BP consists of the large sub-processes needed when developing a product. It is divided into a platform development process and a tender/order execution process. The activities range from product strategy and the first marketing activity to the complete take-over, support and service at the customer. The QG methodology consists of lists of issues to be checked at the end of every sub process as a gate check of completion and quality of work. Though the BP and QG methodology is not the product development model itself, it gives a framework

612

ICED01-C586/141

and guidance for developing a product. In more detail, this model consists of a work breakdown structure (WBS) specifically designed for each Product Unit. Such WBS describes development work to be fulfilled in every step of the project, functional interaction and objectives for each and every activity description. Though the BP and QG methodology itself is a means for identifying, assessing, planning and monitoring of uncertainties known in advance it is not sufficient for the needs of the organization. In parallel, as a separate process, a project risk and opportunity management (PROM) method is used. Although it is not an add-in within the BP and QG methodology, it serves as the means for capturing and handling uncertainties throughout the nroduct develooment nroiect.

Figure 2. The figure shows the observed relation between uncertainties included in QG checklists and the total amount of uncertainties within a product development project.

3.2 Organizational view on the existing Business Process and Quality Gate methodology It is common knowledge that a model for product development must be a part of any organization developing complex products. The application of such an approach as the BP and the QG methodology is considered a well-structured approach, providing a common "language" within the organization. The results also indicate that this model ensures a standardized way of working with enhanced ability to monitor and control a product development project worldwide. The findings also indicate that the purpose of the BP and the QG methodology must be clearly defined and communicated throughout the organization. To further explain the need of the "knowledge of purpose", a common understanding and a feeling of participation amongst employees and proved benefit of use has to be facilitated. It is quite clear that the BP and the QG methodology is not considered sufficient for an adequate handling of uncertainties.

3.3 The Project's view on the handling of uncertainties The handling of uncertainties is divided into two, quite separate, approaches namely the use of the QG methodology and the Project Risk and Opportunity Management process (PROM). The QG methodology handles uncertainties known in advance. Such uncertain issues are gathered from post-project feedback, the integrated work within the entire project and the creation of project tailored checklists. These checklists are grouped into deliverables and key deliverables in areas agreed upon within the project. Since all issues causing uncertainties to a product development project cannot be included, this method leaves large areas of uncertainties to be dealt with within the management of the project. As seen in figure 3, it indicates a view of the unsatisfactory ability to handle uncertainties within the BP and QG methodology.

ICED01-C586/141

613

Figure 3. The figure shows the interviewees perception of how well the handling of uncertainties is considered within the Business Process and Quality Gate methodology.

When looking outside of the project boundaries, 80% of the interviewees consider the BP and QG methodology not to handle risks and opportunities within the line organization to a satisfactory extent. This supports the continuous focus on the interaction between the project organization and the line organization. In organizations such as Adtranz it is important to hold the ability to manage cross-functional interaction as well as to manage common causes of uncertainties within an international environment. As this methodology relies on the active management of the development project and the reactive attitude towards uncertainties, it is important that checklists to follow up in Quality Gates will produce wanted results. Figure 4 shows the perception of what will happen to issues not included as a deliverable in such a checklist. The major opinion is that they will not get the proper focus, be de-prioritized and only become visible later in the project progress when a proper handling it is probably too late. Also the opinion is that issues not included will mean a risk of them being forgotten about or actually being ignored.

Figure 4. The figure shows the interviewees perception of what will happen to uncertainties not included in checklists.

The PROM approach is a methodology for handling uncertainties from the single project perspective. The methodology defines the strategy of creating a project based uncertainty management process, the sources for identification of uncertain events, the method of

614

ICED01-C586/141

assessing uncertainties, the response planning and the method of follow-up and control. A computerized program supports this methodology. The emphasis is on both risks and opportunities. Though this methodology is well known and is used, to a various extent, within different projects there are some findings regarding the execution of this approach: Uncertainties are mostly identified but not always managed perfectly. There must be a clear link between active work of handling uncertainties and the management of it. It is hard to know the benefits of the process until afterwards. The tendency for large projects is that facilitation is needed for success. The process itself cannot be an "add-on" approach to ordinary development work. If a process for handling uncertainties becomes an administrative workload it will not be used.

4

Conclusions and future challenges

Organizations developing large complex products face a great amount of uncertainties. Such uncertainties are inevitable in any kind of project due to the very nature of innovation projects. For organizations facing a low series development, highly costly and complex product, the approach of having a BP and QG methodology alone seems to be insufficient. Even the parallel process of project risk and opportunity management is not seen sufficient enough. Considering an international project organization, it is not enough only to focus on the tools and methods used for handling uncertainties. The findings also show the delicate conflict between the administrative workload and the lack of predictable benefits of a process for handling uncertainties. It is quite clear that a process of handing uncertainties must have the ability to show the benefits to motivate an initially increased administrative workload. The approach with checklists has a positive effect on the handling of uncertainties, but they cannot be extended to cover all possible uncertainties. Therefore, checklists can only be seen as a complimentary check of uncertainties. In the start up of a project, as an active method of identifying uncertainties and during the project execution as a reactive check of completion. The findings are validated for the case of Adtranz. Taking into account own experiences, discussions with other researchers, literature and from the company viewpoint there is not anything that contradicts to the validity of these findings considering the case of other companies. This paper also suggests that theories on risk management should be extended to cover also organizational theories, general management theories and the management of major complex projects. In a more holistic view, this will provide a perspective on how to manage large, lowseries, complex, and multinational product development projects.

ICED01-C586/141

615

The organizational structure is believed to influence the outcome of handling uncertainties, by that including the business-oriented perspective of uncertainty management and the viewpoint of a project portfolio. Risks and opportunities will still, despite all techniques and methods, be an organizational and managerial issue and therefore the interaction and the enabling of handling uncertainties within the whole of the product development organization will be crucial. The Author would like to acknowledge Adtranz for their sponsorship, the ENDREA research school and other researchers in the field of Risk Management for their support. References [I]

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, Practice and Research". In: Dunette M.D and Hough L.M (eds.) Handbook of Industrial and Organizational Psychology 2:nd Ed, Vol. 3. Consulting Psychologist press, Palo Alto, CA, USA.

[3]

Hartmann George C and Lakatos Andras I (1998), "Assessing technology risk - a case study", Research Technology Management, Vol. 41, pp. 32-38.

[4]

Cummings Thomas G, "Tranzorganisational Development" (1984). In: Staw B.M and Cummings L.L (eds.) Research in organizational behavior, Vol. 6, pp. 367-422. JAI Press Inc. Greenwich, CT, USA.

[5]

Sitkin S.B and Pablo A.L (1992), "Reconceptualizing the determinants of risk behavior", Academy of Management Journal, Vol. 17, pp. 9-38.

[6]

Ulrich K.T. and Eppinger S.D (1995), Product Design and Development, MacGrawHill: New York, NY, USA.

[7]

PMBOK 2000. A guide to the project management body of knowledge, Project management Institute PMI, Newton Square, PA, USA.

[8]

Ward S.C (1999), "Assessing and managing important risks", International Journal of Project Management, Vol. 17, pp. 331-336.

[9]

Kahkonen K (2000), "Balancing Project Risks and Opportunities", Project Management Institute Annual Seminars & Symposium, Houston, Texas, USA, proceedings.

[10] Williams T. M (1995), "A classified bibliography of recent research relating to project risk management", European Journal of Operational Research Vol. 85, pp. 18-38. [II] Adtranz (1999), Business Process model. Internal document, Adtranz, Berlin, Germany.

RolfOlsson Department of Machine Design, Royal Institute of Technology, 10044 Stockholm, Sweden Phone: +46 8 790 97 73, +46 70 663 87 75, E-mail: [email protected] ©With Author 2001

616

ICED01-C586/141

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

DECISION-MAKING - HOW TO AVOID DYSFUNCTIONS? HOW TO ANALYSE DYSFUNCTIONS? HOW TO IMPROVE AN ORGANIZATION BY ITS DYSFUNCTIONS? J Stal-le Cardinal, M Mekhilcf, and J-C Bocquet

Keywords: Decision making process, process modelling, human resources, risk analysis and management

1

Introduction

In connection with the industrial objectives that concerns the optimisation of quality, cost and delay, we present a dysfunctions study for the decision making processes. Our approach in this work is to establish a generic representation which considers any company as a network of actors who can make decisions to reach an objective. A functional analysis of process modelling has led us to four characteristics of such a model: the development process is a decision making process in which questions are conceived, accepted, and answered, time appears as an evolution parameter, the human presence is taken into account in the processes, there are interactions between resources (human or inanimate, concrete or conceptual). To focus the modelling approach further, we have chosen a 'dysfunctions' analysis of the decision making process. With this approach in mind we have constructed a pragmatic tool, SACADO, to analyse existing problems of quality, cost, and delay in terms of dysfunctions and to predict likely dysfunctions given a particular set of resources, interactions, humans, and decision making procedures. The study of dysfunctions within the decision making process is pursued with a particular focus on the choice of actor and with a presentation of tools developed to improve that particular kind of decisions. These tools are gathered under the name SACADO (Choice of Actor and Organisation Decisions Aiding System). In SACADO, a target process is proposed to minimise risks of dysfunctions. This method also provides tools to analyse a given dysfunction in order to find causes and recommendations. Finally, SACADO can help in improving an organisation by analysing its dysfunctions.

ICED 01 -C586/187

617

2

Some definitions

In a company, projects are the translation of the strategic trends into actions. So as to accomplish a project, people have to be chosen as responsible for some actions. At the strategic level of a company, decision-makers have to choose people to be project managers and then, a project manager has to build his project team. On such choices depends the global success of a project. The "choice of actor" is a decision made by a decision-maker that consists in selecting, evaluating and choosing a person to accomplish a action. As we said before, such a choice can be made either at a very high or low level of the company. An example is the choice of contractors during the procurement phase (PMI [9]). Before going any further, it is necessary to define what we call an actor, a decision and a dysfunction.

2.1 Actor An actor is a human being among company means. Material resources, software, hardware, people are part of the means in a company. What distinguishes an actor from the other means is that an actor: has competencies quantified by a level, can make decisions, is able to characterise the impact of his action in advance, can perform tasks in order to reach a goal, works with other actors.

2.2 Decision According to Sfez [5], "a decision is not isolated nor broken into pieces, it refers to all other decisions and it is difficult to find the beginning or the end." Mezher [6] describes another aspect of the decision by considering decision as "a process which generates and evaluates alternatives and which makes choices among them." We propose a very simple definition of decision in order to be as generic as possible. Therefore, we define a decision as a process which leads an actor to answer a question.

2.3 Dysfunction We propose here an analogy with the maintenance area [3] where "a failure is the stochastic cessation of an entity's capacity to accomplish a required function. " Boucly [7], According to Villemeur [8], "after a failure identification, the entity is considered out of order. A breakdown is always due to a failure." By analogy, we consider an actor in a company as an entity whose function is to decide. If the decision-maker is not able to make his decision, then there is a dysfunction.

618

ICED 01 - C586/187

We, therefore, propose the following definition of a dysfunction in a decision process : a dysfunction is a stochastic cessation of an actor's capacity to make a decision, to accomplish an action. If the action expected to be accomplished has not been realised, then there is a dysfunction. The gap between the effective result and the negotiated objective to be reached is called the dysfunction value.

3

Two models

Current modelling systems used in a business environment may be characterised as having a static kernel, and mono-actor, that is, a single user/decision-maker. The quantity of information required for more realistic models involving changing kernels and multiple actors is large. Nevertheless, such extensions of models are being considered, in particular to manage product development including social, psychological, customer and software perspectives [4]. From another point of view, a great number of product development approaches represent the firm as a set of components (environment, products, processes and resources) to be coordinated. We propose here two models that we consider to lay the foundations of our approach : the DTL (Decision Time Line), as a decision model, and the target process as a core process that helps people making decision.

3.1 Decision Time Line A key construct is what we call the Decision Time Line (DTL). Figure 1 brings out the six most important steps in any decision process.

Figure 1. Decision Time Line

ICED 01 -C586/187

619

The DTL includes the decision process from the request to the answer. This dynamic representation of a decision making process is constructed in concert with the conceptual architecture for identifying potential dysfunctions. Among the six decision process steps (figure 1), the time line includes four main phases: The first step includes the primary actor/decision-maker in the subprocess of considering a request for a decision, followed by a negotiation phase which represents the interaction of the primary actor and other actors to establish the request environment (i.e. ground rules in terms of time, resources, and type of decision required). If this initial negotiation leads to the request being considered by the primary actor, then the request is identified. The identification includes decomposition of the request into subrequests, when necessary, and the identification of the competencies needed to accomplish each component. The synthesis phase deals with problem resolution/decision-making, if the request is handled directly by the actor, or co-ordination/synthesis if the request has been handled (at least in part) by others. When ready, the decision/answer and its request environment are documented (capitalized) in a database, and the results returned to the request actor. Dysfunctions are decomposed in elementary dysfunctions and represented along the DTL. Elementary dysfunctions have been established during industrial projects follow up. Each elementary dysfunction are related to a DTL step, independent from each others and cannot be studied as a combination of dysfunctions. The gap due to a dysfunction is then evaluated. Using our model, it is possible to give a temporal characterisation of dysfunctions as well as a functional characterisation that allows classification of various dysfunction types.

3.2 Target process The target process, as illustrated in figure 2, is a process to follow for a specific type of decision, choice of actor, and which helps to avoid dysfunctions. But even if the different steps are properly followed, risks of dysfunctions still exist, nothing can completly erase them. This target process can be used to evaluate the risks and be aware of them. It is a more precise decomposition of the identification and synthesis phases of the DTL, applied to the choice of actor. The identification phase consists indeed in listing all the steps and in realizing the first one (Tasks to perform quantification), whereas the synthesis phase consists in realizing the five others.

620

ICED 01 -C586/187

Figure 2. The target process as a core process for a decision-maker

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 managers have been asked to fulfil a decision card (which has been designed upon the DTL and the target process) for dysfunctions that appear in their project. An example of such a card is shown in figure 3. Different kinds of dysfunctions have been studied: past dysfunctions in projects at completion, and past dysfunctions or potential risk of dysfunction in projects in hand.

ICED 01 -C586/187

621

Context Tasks to perform (Quality, Cost, Delay)

Context and quantification oftaskstoperfom

Required competencies

Potential actor

Chosen actor and Why

Steps 2 to 6 of the target process

Risk evaluation and Action plan

Dysfunction and Gap (Quality, Cost, Delay)

Recommendation

Result analysis, recommendation and capitalization

Figure 3. An assistant in the decision for the choice of actor

Once such a card is completed, we are able to analyse the reasons of the dysfunctions. With a consequent number of cards, it is possible then to study the general trend for a given company to cope with dysfunctions.

4.2 How to analyse dysfunctions? The competencies model is used to analyse the reasons of a dysfunction [2]. As shown in figure 4, a dysfunction in a project may have reasons from different natures either linked to behavior, or techniques, or knowledge.

622

ICED 01 -C586/187

Figure 4. A classification of dysfunctions based on competencies [1]

For instance, a dysfunction can be due to the fact that one of our peers has not been recognized competent for a given action (problem of knowing who). When choosing a project manager, a decision-maker can search for competencies such as directing, coaching, supporting, and delegating. The lack of one of these required competencies could be a source of dysfunction in the decision process. This is a problem of attitude.

4.3 Predictions and capitalization The capitalization database provides a means for dysfunction prediction, by capturing the firm's experience from prior decision-making tasks. Software accessing the capitalization database and the decision-making model can give an early warning to a decision-maker when an action or decision-making strategy is likely to lead to a known dysfunction and consequently a problem in quality, cost, or delay. The capitalization database can also be used to conduct a statistical study of dysfunctions within the firm: What are the risky steps in the decision-making process? What are the main sources of dysfunctions? What are the main effects?

ICED 01 -C586/187

623

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, only priority dysfunctions can be taken into account so as to look for their causes and then give recommendations. It is important to notice that recommendations are context dependent. Even if it is always possible to give a list of actions to avoid a dysfunction, the pertinence lies in the capacity to elaborate a strategy of actions more than in the recommendations themselves. We have so far considered individual decisions and competencies. Neither collective decisions nor collective competencies have been taken into account in our approach. It would now be interesting to see how generic our methodology is and if it can be applied to decision and competencies as far as a group is concerned. An industrial experience has taken place at VALLOUREC and testified that SACADO could be an answer to a real industrial need. References [1]

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 oriented model for design action capitalization.. Third Biennal World Conference on Integrated Design 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 decision problems 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 sciences politiques, Paris, 1992.

[6]

Mezher, T., Abdul-Malak, M.A., & Maarouf, B., Embedding Critics in DecisionMaking 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, facteurs humains, informatisation. Paris, 1988.

[9]

Project Management Institute Standards Committee. A Guide to the Project Management Body of Knowledge. Upper Darby, Pa. : Project Management Institute, 1996.

Julie Stal - Le Cardinal Ecole Centrale Paris, Laboratoire Productique Logistique, Grande voie des vignes, 92295 Chatenay Malabry Cedex, France, Tel: (33) 1 41 13 15 69, Fax: (33) 1 41 13 12 72, E-mail: stalj @pl.ecp.fr ©IMechE2001

624

ICED 01 -C586/187

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

PRELIMINARY DESIGN OF A RISK MANAGEMENT DECISION TOOL J M Feland KEYWORDS: design-for-X, design information management, risk analysis and management, barriers to implementation, expert systems, and knowledge management

1

Abstract

Given the challenge by NASA Administrator Daniel Goldin to develop and embrace Design For Safety practices, tools and methodologies, this paper details an approach to be taken by researchers at Stanford's Center for Design Research and the Learning Lab in meeting this challenge. The recent disappointments of the Mars Climate Orbiter and the Mars Polar Lander have given rise to this challenge along with NASA's continued focus on mission safety and effectiveness. One of the issues highlighted by Administrator Goldin at the 15th Annual NASA Continual Improvement and Reinvention Conference this year were problems with proper knowledge transfer between designers, operators, and risk managers. Within current mission development practices, risk managers, operators, and designers come together during rare program reviews. As a result of these integrated meetings, several action items are taken by all stakeholders that require additional efforts with impacts on cost, schedule, and performance while mitigating risk and ensuring safety. The figure below depicts the activities of stakeholders during a mission development under the current environment of limited knowledge exchange. In the following, a brief overview of NASA's Design for Safety Initiative will be given. Additionally a survey of NASA's current practice of Continuous Risk Management (CRM) will be made. Once NASA's development environment and practices have been defined, problem areas in NASA's current methods will be outlined. Finally the proposed design for a risk management decision aid will be detailed that will assist in reducing the program risk signature. A program's risk signature is an indication of the level of risk in cost, schedule, and performance.

Figure 1. The graph above qualitatively depicts the normal communication interactions under NASA's current practice of Continuous Risk Management (CRM). System level risk identification and mitigation activity only occurs at monthly Integrated Project Team (IPT) meetings and at major program milestone reviews.

ICED 01 -C586/470

625

2

Design for Safety Initiative

Recent catastrophic failures of some highly visible NASA missions spurred NASA to perform a top-down review of all system development practices. In each mission area three problem areas kept surfacing. To address these significant issues, NASA started the Design For Safety Initiative. Three emerging technology areas have been focused on as sources for potential solutions. Problem Areas Solution Areas Poor knowledge management Poor System Risk and Multiobjective Trade-off Analysis Intelligent System Risk Rigid and nonadaptive systems Management Technologies for resilient systems Knowledge Engineering Table 1. NASA has identified three problem areas that contribute significantly to recent mission failures. As part of the Design For Safety Initiative, three technology areas have been identified as potential solutions to these issues. [1]

The NASA requirement to be addressed by the Risk Management Decision Aid falls within the domain of the first two problems and their corresponding recommended solutions. Improving Knowledge transfer between designers, operators, and risk managers will rely heavily on knowledge engineering practices to capture contextual information on each stakeholder's efforts. Additionally, the use of Intelligent System Risk Management will make use of this contextual database to support rapid and superior risk assessment and risk mitigation.

2.1 Barriers to the DPS initiative and other Risk Management process Members of the European Space Agency identify several barriers to effective implementation of Risk Management. The most common barriers are listed as follows: Technical arrogance and individualism of the engineering staff, information ownership linked to personal power, lack of proper understanding of the advantages of Risk Management, Shoot the messenger Program Manager approach, and the inclination of Program Managers to believe that they have always been doing Risk Management. [3] The Design For Safety Initiative will have to contend with all these barriers to implementation. Based on the various risk management programs already in place at NASA, the last barrier seems to be the largest one to overcome. The Risk Management Decision Aid will have to be implemented to consider and overcome all of these barriers to risk management implementation.

3

Current Risk Management Techniques at NASA

NASA Program Guidance 7120.5A, "NASA Program and Progress Management Processes and Requirements" states "The program or project manager shall apply risk management principles."[8] To that end, NASA called upon their Software Assurance Technology Centre (SATC) to develop a system level risk management course, the Continuous Risk Management (CRM) process, with assistance from the Software Engineering Institute. CRM has five steps: Identify, Analyse, Plan, Track, and Control, while the need to Communicate and Document connects all steps. [11] This process comes directly from the Software Engineering Institute's risk management process. CRM defines risk management as the responsibility of every

626

ICED 01 -C586/470

person involved with mission development and execution. Identifying the risk involves developing a risk statement and the context/rationale in which it exists. Analysing the risk calls for the stakeholder to determine the impact to the program, the probability of this occurring, the timeframe in which the risk is required to be mitigated, a classification of the risk, and a prioritisation of the risk. SATC provides guidelines to assess the probability, impact, and timeframe of the risk. The planning phase calls for the development of a risk mitigation plan focused on eliminating the risk before it occurs rather than increasing system robustness to survive the risk occurrence. In the next step those responsible track the risk status in case the perceived risk situation arise. The final step determines how to mitigate the risk, usually implementing the existing pre-defined risk mitigation plan. Key to all these steps is effective communication and documentation of risks. Gerosa of the Alenia Aerospazio Space Division describes the typical risk factors that exist in space programs as: Technology; Requirements; Manufacturing; Verification, integration, and test; Development status; Team experience and availability; Planning; Subcontractor/Supplier; Customer/Contractual/Legal; and Financial. [5] CRM relies on the vigilance of the Program Manager to ensure these risk factors are addressed during mission development and execution. As part of their system level risk management training in CRM, the SATC has published a sample risk management plan for a fictional project meant to be the example of how to accomplish risk management within a project. This "Project Zeus" risk management plan applies the five-step CRM process as well as details the risk management responsibilities of all development stakeholders. [2] The plan describes several personnel intensive methods of risk identification ranging from formalised questioning designed to expose risk and design team brainstorming. Members of the Integrate Product Teams (IPT), the IPT lead, and the Systems Assurance Manager complete risk analysis. All three groups vote on impact of risk, probability of occurrence, and the timeframe the risk must be acted upon. It then becomes the team lead or Project Manager's responsibility to either develop the risk mitigation plan or pass the responsibility to another organisation. Tracking of the risk status is done by the owner of the risk and communicated to the Project Manager (PM) during weekly or monthly meetings. Decisions are made by the PM to control the risks during weekly and monthly meetings. "Project Zeus" relies on weekly project, IPT, and monthly project meetings to communicate risks and their status. Formalised project documentation is used to document risk information. "Project Zeus" and other real NASA missions suffer from the lack of continuous interaction illustrated in Figure one. Project stakeholders continuously make decisions that affect the risk signature of the development program. Weekly and monthly risk updates place the stakeholders in a constant state of reacting to risk information instead of proactively addressing potential risk situations as they evolve. The entire risk management process creates significant additional responsibilities for all the project stakeholders. The increase in formal program documentation, specifically for risk along with the normal document authoring, approval, and publishing cycles, not only contributes to the growth in the workload of project personnel, but also increases the delay in important program risk communication. Additionally the entire plan relies on a serial risk management process with discrete steps to be taken at various time intervals. The additional duties placed on project personnel move risk management activities from the desired state of an attribute to be considered like cost, schedule, and performance, to a cumbersome tasking that increases the cognitive overhead of all program stakeholders. Key to the success of any NASA mission are the efforts of the operators. Unfortunately the only time operators as asked to consider the risks are during Integrated Product Team meetings. The operational community typically has the greatest insight to the impact and probability of various risk events occurring.

ICED 01 -C586/470

627

Automated Requirements Measurement Tool (ARM) is a software development management tool developed by SATC for providing NASA project managers metrics regarding requirement specification documents. [7] ARM searches documents for various significant phrases, developing metrics for lines of text, imperative phrases, continuances, weakly worded phrases, directive phrases, options, unique subjects, and readability statistics. By analysing these metrics, requirements with the greater risk potential are highlighted for further review. While valid for software specifications, the tool has not yet been expanded to cover the domains required for a system level implementation. In five Israeli companies known as leaders in risk management, an assessment of the validity of risk management tools was performed. [10] The study categorised the tools into five groups based on the SEI risk management process with and an additional category for tools that provide background information in support of a stable risk management environment. The background group of tools received the highest usage rates. The tools in this category support various portions of the entire risk management process. This result indicates that risk management practices are highly coupled with other management practices. Top five risk management tools used by these companies were Simulation (Background), Responsibility assignment (Planning), Risk impact assessment (Analysis), Configuration control (Background), and Subcontractor management (Background). Responsibility assignment and Subcontractor management both focus on identifying an owner of the risk. Risk impact assessment is obviously a critical step to understanding and coping with risk events. Simulation provides insight for all five steps of risk management by acting as a predictive tool. Configuration-control functions as a risk mitigator by controlling the program baseline and managing changes to critical system components. The most used risk management tools were the tools that assisted in all phases of risk management and even relevance to other management practices associated with the execution of a successful project.

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 improve NASA's in-process risk identification and communication challenges.

Figure 2. The above graph represents how risk Management Decision Tool would not only drastically improve in process communication between stakeholders, but also reduce the amount risk mitigation redesign activity and risk assessment activity, thereby leading to safer and more efficient execution of the program.

628

ICED 01 -C586/470

4.1 System Architecture The Risk Management Decision Aid will consist of six components. These include Knowledge Acquisition System (KAS), the Risk Assessment and Analysis Knowledge-Base (RAAKB), the Design Communication Database (DCD), the Project Structure Database (PSD), the Risk Identification Expert System (RIES), and the Risk Evaluation Expert System (REES) as shown in the figure below.

Figure 3. Risk Management Decision Aid system architecture illustrating which system components require interface to others. Each will be implemented to make maximum use of legacy software and knowledge-base while minimising the cognitive overhead to the Design For Safety stakeholders, designers, risk managers, and operators.

4.2 Knowledge Acquisition System The Knowledge Acquisition System (KAS) will be made up of three components. These are RECALL-derived program knowledge capture systems dispersed through the stakeholders' activity areas, programmatic email archives, and databases of formal programmatic documentation. RECALL is a design-knowledge capture tool developed by researchers at Stanford University to assist in the capture and reuse of design efforts. [12] The system makes use of video, audio, and sketch data to record the efforts of design teams. This data is then parsed and organised according to sketch activity. Traditional design capture tools capture only audio and video. These legacy systems required tremendous amounts of post processing to make the data useful for reuse. RECALL indexes the design context information with thumbnails of the sketch activity. As the sketches are easily recognised for their efforts, this allows users of this data to quickly locate which contextual data is needed for review. To meet the needs of the DFS initiative, modified RECALL systems will be peppered throughout stakeholder common team areas. These systems will be located where project personnel normally congregate to discuss the project and make decisions that affect the program risk signature. To integrate the use of the system into the program's normal work habits, the cognitive overhead required to make use of these RECALL stations will be minimal. Each system will be connected to the Design Communication database for archival and processing purposes. The Programmatic Email Archives are simple storage databases of project related email communication. The emails contain not only important design and decision history communication, but also contain real-time information of actions impacting program risk. It is envisioned that both the Risk Identification Expert System and the Risk Evaluation Expert System will use this information. Formal Programmatic Documentation such as requirements

ICED 01 -C586/470

629

documents, design specifications, and operating instructions, contain valuable information regarding the program baseline. These documents will be stored in the Design Communication database for further use by the RIES and the REES.

4.3 RMDA Databases The RMDA makes extensive use of three knowledge-bases. They are the Design Communication Knowledge-Base, the Project Structure Database, the Risk Assessment and Analysis Knowledge-Base. The Design Communication Knowledge-Base is the main repository of project specific knowledge. Captured via the Knowledge Acquisition System, this database contains real-time information about decisions and discourse regarding the program, a time-history evolution of programmatic information, and current program baseline with respect to both the design and the risk. The Project Structure Database contains information regarding the organisation of the program. This includes information such as program organisation chart, IPT members, and contact information. One of the critical pieces of information in this database is a risk profile for each of the program personnel. This risk profile contains information regarding which program elements the author is involved with and a catalogue of past risk related experience. This risk profiling is essential for the Risk Identification Expert System to be able to perform its tasks of integrating several disparate pieces of information in order to assist in identifying potential risk events. The Risk Assessment and Analysis Knowledge-Base contains both the current state of the system risk and the information required to assist the expert systems in aiding stakeholders in their efforts to identify and evaluate risk. Based on lessons-learned and other institutional risk information, this database will build risk cases to assist in evaluating risk.

4.4 Decision Support Systems (DSS) The RDMA contains two decision support systems that interface with stakeholders to reduce the system risk. The two systems are the Risk Identification Expert System and the Risk Evaluation Expert System. Traditionally Decision Support Systems and Expert Systems have focused on assisting individuals in their decision-making processes. Druzdzel comments that experts, though capable of better decisions than novices, are still susceptible to the same judgmental biases as novices. He gives an example where the ability of psychiatrists to diagnose future violent behaviour in patients was compared to the ability of a simple linear DSS based on past incidents of violent behaviour. The doctors proved inferior to the model. [4] Hamer advocates the development of Group Decision Support Systems to support asynchronous decision support among several group members. [6] The RDMA will have elements of a Group Decision Support System due to the complexity of NASA programs, the many risk factors to be considered, and the number of stakeholders involved. According to Druzdzel and Flynn, Descriptive systems are based on human intuitive reasoning and Normative systems have their foundations in decision theory, probability theory, and decision analysis. [4] It is critical that the RMDA be based on normative methods to avoid the biases of human reasoning, specifically as it relates to NASA missions. This assists in overcoming some of the barriers to effective risk management such as technical arrogance and the propensity of program managers to rely only on past risk abatement experience. Pal and Palmer advocate a hybrid case-based / rules-based DSS structure to take advantage of the benefits of both DSS development methods. [9] Case-based systems involve making use of past experiences to determine the recommended course of action. Rules-based systems represent domain knowledge in the IF - THEN format. The use of Case-based systems allow for exceptions to the more rigidly structured Rules-based architecture. The flexibility to consider many sources of information and models of system behaviour is a requirement of the

630

ICED 01 -C586/470

RMDA as in each NASA mission there are valuable similarities as well as critical differences. For example, the methods and means of achieving a Martian orbit can be used repeatedly to send probes to Mars, while specific experiments rely on domain specific knowledge of limited usefulness beyond the mission timeline. The Risk Identification Expert System (RIES) assists stakeholders in identifying potential risk events. By making use of the Design Communication Knowledge-Base, the Risk Assessment and Analysis Knowledge-Base, and the Project Structure Database, the RIES determines potential risk events and notifies the stakeholders with responsibility for that risk area. The data captured from the RECALL-based program information capture systems is sifted for risk identifiers, similar to the operation of the ARM tool. The archive of programmatic emails is utilised in a similar matter. The RAAKB is used to assess the current risk signature and perform a preliminary assessment of impact, probability, and timeframe for initial delivery to the program stakeholders with interest and responsibility based on the information in the PSD. This allows for the continuous communication of developing risk events to the program personnel involved, rather than waiting for weekly, monthly, or quarterly meetings to surface these potential risk events. Additionally, the RIES will allow for shared notification of potential risk events found independently by stakeholders without the assistance of the RIES. The Risk Evaluation Expert System (REES) goes the next step in assisting stakeholders to evaluate the risk event, suggest potential risk mitigation activities or concepts for increasing system robustness, and update the current risk status of the program. Through the use of a normative, hybrid case-based/rule-based group DSS, each stakeholder makes their assessment and evaluation of the risk events alerted by the RIES and other means. As the REES is a Group DSS, tools will be in place to assist the various stakeholders to come to a consensus on the risk impact, probability, timeframe, and priority. Additionally the REES will be the interface by which stakeholders view the current program wide risk status as maintained by the Risk Assessment and Analysis Knowledge-Base.

4.5 Implementation Impacts and Benefits As with the use of any new methodology, there are impacts to the organization's normal workings as these new capabilities are brought on-line. During the initial set-up of RMDA there will be some significant resource impacts with respect to infrastructure changes and training on the system. Once up and running, the impacts to organization and individual efforts would be minimized. The RMDA is designed to mesh into the normal working habits of program stakeholders. The only significant impact to day-to-day efforts is the increased awareness of potential risk events and the corresponding response to that knowledge. This extra effort is well worth it as the end result is overall risk reduction, increased mission safety, and more assured mission performance. Applications of RMDA would reduce risk signatures on NASA programs over $10 million. In smaller programs the cost of implementation would outweigh the programmatic benefits gained from RMDA. For NASA the cost of RMDA is much less than the economical and political losses associated with a $70 million mission failure. Beyond NASA's Risk Management needs, the RMDA could reduce the risk signature of projects in several other domains. There are benefits to the development of Defense Systems, specifically with respect reducing both development risk and operational risk. As automobiles become more complex, a tool like RMDA would assist the Automobile industry in flagging risk adverse activity during development. Consumer Product Development, typically at a smaller scale than NASA programs, would also benefit from RMDA, especially if the development stakeholders are distributed geographically. Many industries would benefit from the risk signature reduction afforded through the adoption and use of RMDA.

ICED 01 -C586/470

631

5

Conclusion

The Risk Management Decision Aid consists of capture tools, knowledge-bases, and decision support systems designed to support NASA. NASA's current risk management programs do not involve all stakeholders, and allow for only sporadic risk communication. Additionally they are hampered by a focus on subsystem risk management rather than a system level approach. Current practices do not significantly reduce the risk signature of NASA missions enough to avoid catastrophic failures. The RDMA will improve the risk signature through the use of the knowledge capture technology; knowledge-base engineering; and Normative, Group Decision Support Systems. By decreasing the time between risk information communication and assisting in rapidly assessing the risk, stakeholders can either mitigate the risk or increase system robustness. The RDMA will ultimately provide NASA the means to accomplish more economical, safe, and effective missions for space exploration. References [1]

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." European Space Agency 1st Risk Management Workshop. 1998.

[4]

Druzdzel, M. and Flynn, R. "Decision Support Systems," Encyclopaedia of Library and Information 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 and Symposium. Philadelphia, Pennsylvania, USA, October 1999.

[6]

Hafner, A. "Group Decision Support Systems, Executive Team-Management Tools for the Military." Program Manager, January - February 1994.

[7]

Hammer, T. et al, "Requirement Metrics for Risk Identification," Dec 96, last accessed 23 Jan 01 from http://satc.gsfc.nasa.gov/support/SEW_DEC96/sel.html

[8]

NASA Program Guidance 7120.5A, "NASA Program and Progress Management Processes and Requirements", April 1998.

[9]

Pal, K. Palmer, O., "A decision-support system for business acquisitions," Journal of Decision 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 and Symposium. Philadelphia, Pennsylvania, USA, October 1999. II1] Rosenberg, L. et al, "Continuous Risk Management at NASA," Proceedings of Applied Software Measurement / Software Management Conference, Feb 1999, San Jose, California, USA. [12] Yen, S., Fruchter, R., Leifer, L., "Facilitating Tacit Knowledge Capture and Reuse in Conceptual Design Activities," ASME DTM Conference, Sep 1999. Capt John M. Feland III HQUSAFA/DFEM, Suite 6H2, 2354 Fairchild Drive, Colorado Springs, CO 80840, USA Tel: 719-964-8058, Fax: 719-333-2944, Email: [email protected] ©IMechE2001

632

ICED 01 -C586/470

Authors' Index A Agogino, AM Ahmed, S Aldanondo, M Andrade, R Aoussat, A

19-26 75-82 131-138 299-304 361-368

Dong, A Duffy, A H B

19-26 123-130, 155-162, 163-170, 195-202, 227-234 393^100, 537-544, 561-568

E

Eckert, C M

B Badke-Schaub, P Barr, G Basson, A H Bell, D G Bender, B Bender, B Bermell-Garcia, P Bjarnemo, R Blanco, E Blessing, LTM Bocquet, J-C Borg, J Bramklev, C Brannstrom, O Brookes, N J Buijs, J Burgess, S C Burvill, C Busby, J S Butter, D

251-258, 457^164 497-504 385-392 243-250 313-320 313-320 99-106 377-384 11-18 313-320 269-276, 617-624 219-226 377-384 305-312 433^40 353-360 497-504 277-284 601-608 99-106

C Caillaud, E Carrillo, A G Carrizosa, K Chakrabarti, A Chung, PWH Clarkson, P J Coates, G Grassland, R Culley, S J

F

Fagerstrom, B Fan, I-S Farrell, J Feland, J M Feldmann, D G Frank, C Frankenberger, E Freisleben, D Fuxin, F

329-336 99-106 123-130 625-632 59-66 285-292 115-122 553-560 369-376

G Gardoni, M Girard, P Grante, C Gullander, S Gwyn, B

11-18, 285-292 67-74 513-520 401–08 123-130

H 131-138 481^88 465^72 3-10 601-608 43-50, 321-328, 345-352, 497-504,577-584 393-00 585-592 83-90, 179-186

Hadj Hamou, K Haffey, M K D Hansen, P K Hibberd, R E Hills, W Howell, L L Hughes, E J Hughes, P Hughes, R

131-138 561-568 171-178 601-608 393-00 521-528 601-608 277-284 277-284

I

D Darlington, M J Das, B P de Medina, HV de Pennington, A Deasley, P J Donaldson, KM

Elstrom, B-O Eris, 0

43-50, 321-328, 441–48, 473–80,577-584 305-312 171-178

83-90 601-608 449-156 409-416 417-24 505-512

Ivashkov, M Y

139-146

J

Johannesson, H Jonson, G

329-336 377-384

633

o

K Kennel, T Konovessis, D Krus, P Kunz, A M

425–32 593-600 513-520 425–32

O'Donnell, FJ Oestvik, 1 Ohrvall-Ronnback, A Olsson, R

L

P

Lamothe, J 131-138 Langdon, P M 3-10, 107-114 Larsen, J B 521-528 Lauche, K 187-194, 425-432 Lee, B S 163-170 Lehtonen, T A 293-298 Leifer, LJ 243-250 Leifer, L 171-178, 211-218, 465-72 Lattice, F 433-440 Lewis, W 147-154 Li, G 99-106 Liang, T 243-250 Lim, S 163-170 Lindley, M W 545-552 Link, P 529-536 Lloyd, T 211-218 Lockledge, J C 27-34 Lowe, A 179-186

Palmberg, J-O Payne, K H Pilemalm, J Pons, D Porter, R Potter, S

M Mabogunje, A Magleby, S P Malvisalo, J M Marie, F Matthews, PC Mbiti, K McDonald,: McKay, A McMahon, C A Mekhilef, M Melo, A F Menand, S Merlo, C Millet, D Miiller, S Murakami,T Muranami, M

171-178, 465-172 521-528 293-298 269-276 107-114 425-32 123-130 409^16 179-186, 585-592 617-624 321-328, 345-352 35^2 67-74 361-368 425^132 51-58 545-552

513-520 417-424 261-268, 401-408 569-576 99-106 83-90

R Raine, J K Rehman, F Riitahuhta, A O Rodgers, P A

569-576 219-226 293-298 203-210

S Salustri, FA 27-34 Samuel, A 147-154 Schabacker, M 553-560 Schmidt,J 59-66 Schueller, A 385-392 Schwankl, L 235-242 Shah, T 179-186 Sheppard, S D 505-512 Sheppard, S 465-472 Shimamura, J 51-58 Simons, C 577-584 Sims Williams, J H 497-504, 585-592 Smart, P 433-440 Smith, J S 195-202, 227-234 Song, S 19-26 Spiroudis, S 529-536 Stacey, M K 43-50, 441-448, 473-480 Stal-le Cardinal, J 617-624 Stempfle, J 251-258, 457-464 Stoeltzlen, N 361-368 Strachan, S 123-130 Suistoranta, S 337-344 T

N Nakajima, N Naveiro, R M Norling, P

537-544 593-600 401-408 609-616

51-58 449-56 401-408

Thoben, K-D Thompson, G Thomson, G A Tollenaere, M

91-98 305-312 489-496 35-42

u Ullman, D G

545-552

V Vajna, S Valkenburg, R van Overveld, C W A M Vassalos,D Verbeck, A

553-560 353-360 139-146 593-600 187-194

75-82, 107-114 251-258 91-98

147-154 123-130 393-400 569-576 513-520 19-26 155-162 91-98

Y Yan, X-T

W Wallace, KM Wallmeier, S Weber, F

Weir, J West, G Whitfield, R 1 Whybrew, K Williander, M Wu, J-L Wu, Z Wunram, M

219-226

Z Zika-Viktorsson, A

261-268